Reengenharia e Refactoring – nosso destino

“Things alter for the worse spontaneously, if they be not altered for the better designedly”
Francis Bacon

Refactoring é uma necessidade para a TI, nossos softwares e, diria o filósofo, para a vida.

Vale uma lida no blog da Susan Cramm (https://blogs.harvardbusiness.org/cramm/2009/04/why-it-solutions-are-never-sim.html ).

Como ela diz, os sistemas nascem enxutos e arrumados, mas com o tempo deterioram.

O mesmo acontece com softwares grandes como ERP’s ou Sistemas Operacionais. De tempos em tempos precisamos de uma reengenharia para diminuir o número e a complexidade de interfaces ou a redundância exagerada de software. Por isto o investimento é constante.

Mesmo no desenvolvimento de um primeiro software esta tendência já está à espreita. Com uma equipe grande, a má-comunicação e a falta de sincronismo garantem uma complexidade exagerada e/ou um provável retardo na entrega do software.

Existem várias boas práticas para tentar evitar o caos: comunicação eficiente, separação clara dos módulos e interfaces, divisão clara de papéis na equipe, revisões freqüentes de projeto e código, o famoso “build diário”, etc.

Mas e quanto ao que já está em produção?

Trabalhei numa empresa em que implantamos um sistema que mapeava as reclamações feitas ao suporte pelos clientes contra o módulo/função do código fonte relativo à falha. Com os histogramas decorrentes, em pouco tempo pudemos perceber que havia picos de erros em algumas poucas funções. Nossa medida foi simples: redesenhar e reescrever o que provocava os muitos erros. O sucesso foi imediato - em poucos meses tínhamos um sistema muito melhor que o inicial.

Na hora de um grande refactoring é essencial conseguir um grafo de dependência entre módulos, classes, variáveis e funções. Assim vocês podem imaginar o prazer que tive logo após instalar o Beta 1 do Visual Studio (ver aqui). Uma das novas funcionalidades é exatamente a de criar grafos de dependência com a possibilidade de queries (com o Architecture Explorer) sobre um código já existente. Bom para a engenharia reversa (quem não teve que dar manutenção a um código desconhecido?) e para o refactoring . Vale a pena uma olhada.

Para quem não quiser baixar antes de saber mais, sugiro uma olhada na documentação em https://msdn.microsoft.com/en-us/library/dd409365(VS.100).aspx.

Para dar um gostino, na figura abaixo você pode ver um grafo de dependência de um código meu de teste. Na parte de baixo da figura, está o “Architecture Explorer” para fazer queries.

Abraços