Certa vez, passei por uma situação que acredito que você já passou um dia na sua vida profissional. Tive que implementar uma funcionalidade nova num projeto e precisava alterar diversas partes do código desse projeto para implementar essa funcionalidade. Infelizmente esse projeto não tem uma boa cobertura de testes automatizados. Existem até alguns testes, mas não o suficiente.

Dentro do “possível”, adicionei testes no projeto para melhorar o nível de confiança nas alterações e conseguir trabalhar um pouco mais sossegado quanto a qualidade do que estava sendo desenvolvido. Aproveitei a oportunidade para estimular meus colegas no uso de testes automatizados. Eu poderia simplesmente ignorar os testes e manter o “padrão” atual do projeto, mas como bem disse uma vez o Guilherme Chapiewski num excelente post sobre inclusão de testes num projeto, no momento em que comecei a modificar o código desse projeto foi o momento em que comecei a colocar testes nele.

Nessa experiência, enumerei 3 sintomas que podem ser um indício de que seu código está virando o Código do Pânico. São eles:

  1. Classes/Metodos/Atributos que aparentemente não são mais usados não são removidos, pois não existe certeza de que a remoção deles não vai causar problema.
  2. Existe um medo enorme em modificar um método. Geralmente cria-se outro que faz “quase a mesma coisa” e com um nome parecido, pois estragar aquele método pode gerar até uma demissão.
  3. Desenvolvedores adicionam gambiarras (ou bacalhau pra quem prefere) sem a menor pena, afinal de contas, o código já está cheio delas mesmo.

A maioria dos problemas que tornam o código do seu projeto um Código do Pânico se resolvem com praticas como TDD, mantendo uma boa suite de testes e também retirando as gambiarras do seu código, que quando não removidas, estimulam outros desenvolvedores a adicionar mais um pouco sempre que a pressa pede.

O quanto você tem medo de alterar o código do seu projeto?