E quando o código fonte fica velho?

Todo desenvolvedor de software que já fez alguma manutenção em seu próprio código fonte tempos depois já se perguntou o porquê de ter feito daquela forma o código anterior. Certamente olhando o mesmo código durante a manutenção você já está com novas idéias que podem simplificar a implementação e muitas das vezes tornar o processamento até mais rápido baseando-se em outras experiências que evoluiu pelo caminho.

Experimente conversar com outras pessoas da área e certamente vai ter a mesma percepção de todos. Na prática não é o código que ficou velho e sim você que ficou mais experiente em implementar aquele tipo de situação ou parou num momento de mais tranquilidade que lhe permitiu analisar o problema de outra ótica e enxergar mais soluções. É similar ao que acontecer muitas das vezes que vai dormir e acorda com o desenrolar de um problema que passou o dia para resolver.

Todo desenvolvimento de software é empírico e emergente. É o principio básico que todos devemos ter em mente quando mergulharmos em qualquer projeto de desenvolvimento. As ideias sempre vão evoluir e até mudar de rumo durante a codificação. Portanto você deve se preocupar sim com a padronização e fazer da melhor forma, mas nunca se prender a isso por que o mais importante é atingir o valor de negócio. Não adianta você se focar no melhor projeto do mundo com as melhores boas práticas se não tem entrega ou se só você desenvolve nele.

Para garantir a fidelidade ao valor de negócio nada melhor que implementar Unit Test que elevando o seu projeto e o código a um segundo estágio de maturidade permitindo uma independência da sua presença para que qualquer outra pessoa possa refatorar o código fonte velho ajustando e mantendo a fidelidade com o valor de negócio por meio dos testes unitários sem comprometer o projeto. Uma vez que você inicia o desenvolvimento já usando Test Driven Development (TDD) o seu projeto já sai preparado para futuras manutenções.

A grande ideia no TDD é justamente criar primeiro os testes e depois ir implementando as regras de negócio para atender aquela expectativa. Na prática os testes unitários vão falhar no inicio e sua missão é ir justamente corrigindo e implementando melhorias nas regras de negócio até que o seu código já seja aprovado pelos testes. Estáticas comprovam a grande eficiência e aumento de produtividade no uso de TDD uma vez que reduz até seu tempo depurando uma aplicação.

Ao longo do tempo quando for necessário realizar uma manutenção ou refatoração para melhor o código você vai rodar todos os testes associados e garantir que não está introduzindo um novo bug no projeto. Desenvolver software hoje sem usar testes unitários é igual a pular em um mar congelado sem boia. A fata de garantias quando muda uma regra de negócio hoje em um ERP pode resultar em enormes prejuízos seja financeiro ou emocional em todo o time. As tecnologias evoluíram e junto com elas novas técnicas como essa que estamos conversando que propiciam uma nova experiência no desenvolvimento de software.

Para saber mais:
Code refactoring
Test-driven development

[],
Ramon Durães
MVP, Visual Studio ALM
PSD, Professional Scrum Master
PSD, Professional Scrum Developer

Para consultoria e treinamentos em TDD entre em contato com a 2PC!!