Mergulhando no Caos

Tenho uma confissão a fazer. Hoje eu apaguei umas 20 linhas do código de um sistema.

Afinal quem seria desumano a ponto de apagar um trecho de código em que investiu tempo e esforço para escrever? Quem em sã consciência cogitaria esta possibilidade?

Mas eu tive minhas razões. O trecho que eu apaguei é o que eu chamaria de solidificação mineral de código indevida. Sabe aqueles trechos de código que estão ali mas você não sabe para que diabos escreveu aquilo? Você passa um bom tempo imaginando qual a utilidade daquilo e não consegue se lembrar nem elaborar uma hipótese plausível. O trecho de código é quase um apêndice do seu sistema. Está lá. Funciona. Mas ninguém usa para nada.

Este anti-padrão foi identificado por William Brown, Raphael Malveau, Hays “Skip” McCormick e Thomas Mowbray no livro AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis e observado por milhares de programadores em uma quantidade astronômica de projetos. Os autores do AntiPatterns chamam isso, sugestivamente, de bloco de lava. O nome é uma alusão à erupção de um vulcão. Depois que passa a fúria da lava, ficam alguns blocos solidificados que não servem para muita coisa.

O código que eu apaguei hoje não era exercitado por nenhum teste do projeto (não estou usando nenhuma ferramenta para monitorar a cobertura de código, mas executei os testes após a exclusão do código e tudo continuou tão verde quanto antes). Além disso, eu não consegui pensar em nenhuma utilidade para aquele código mesmo tentando bastante. Então eu respirei fundo, apaguei o código e enviei a modificação para o repositório central. Até agora ninguém reclamou. E se reclamar vou pedir que escreva um teste que demonstre a utilidade do código. Isso vai impedir que o próximo programador desavisado apague tudo novamente.

Cada linha de código de um sistema em evolução (o que engloba a maior parte deles) aumenta o custo de manutenção. É mais uma linha que vai precisar ser lida, compreendida e testada. É como se o projeto fosse uma mala e as linhas de código as peças de roupa. Cada peça de roupa colocada na mala é um peso a mais que precisa ser carregado. Uma camisa ou um par de meias sozinhos não pesam muito, é quando eles se juntam que a mala fica pesada. Ao apagar o código, eu optei por carregar menos bagagem.

Talvez eu não esteja tão louco quanto pensei.

A frase acima foi inspirada em uma de Galileu Galilei: “Torne mensurável o que não puder medir”. Na Itália do século XVII, ele estava falando da necessidade de medidas precisas para o saber científico. O bom cientista deve sempre conseguir um meio de quantificar o que estava estudando, mesmo que a medida não seja ainda padronizada. A partir disto ele pode comparar resultados, tem mais embasamento para suas hipóteses e pode se comunicar melhor com seus pares. A medição é indispensável para um bom estudo científico.

Do mesmo modo, os testes são indispensáveis para uma boa peça de software. Código testável permite que testes sejam escritos facilmente, sem necessidade de grandes trechos de código de configuração de ambiente. Para alcançar isso é necessária uma boa dose de modularização e desacoplamento, que são sem dúvida boas coisas.

Uma ótima prática para escrever código testável é escrever os testes antes do código de produção. Com isso, o código de teste tende a ficar pequeno, o que significa que o código de produção tem uma interface enxuta e bem definida (o que, não preciso dizer, também é uma boa coisa). Os testes deixam de tentar se adaptar ao código e o código é que passa a se adaptar aos testes. De um certo modo, o código é modelado pelos testes.