Software saudável

Publicado por Vinicius Manhães Teles há aproximadamente 1 ano.

Ontem, após ler o artigo sobre janelas quebradas, o Rafael MVC, do grupo rails-br fez uma ótima pergunta: "100% de cobertura não é muito caro? Muitas vezes é desnecessário ter 100% de cobertura. O que você acha?"

Acredito que pode ser caro, ou barato, dependendo da forma como a questão é encarada e da tecnologia empregada. Na parte tecnológica, é mais fácil manter 100% de cobertura em Ruby que em Java, por exemplo. Seja como for, acho que o ponto fundamental é a forma como encaramos desenvolvimento de software.

Conheço algumas pessoas que estão sempre em forma. Não têm barriga, não têm problemas de saúde, e quase não se vê gordura pelo corpo. Ainda assim, elas fazem exercícios freqüentemente e comem pouco. Por que fazem isso, se não precisam? Porque se não mantiverem bons hábitos alimentares e se exercitarem freqüentemente, deixarão de ter um bom preparo físico e começarão a acumular gordura. Chamo isso de "paradoxo do atleta".

Em software acontece o mesmo, se você não exercitá-lo constantemente, através de uma bateria de testes automatizados, ele terá baixo condicionamento e não será tão saudável quanto o software "malhado" que está sempre sendo exercitado.

Qual o problema disso? Pense em uma pessoa obesa, como a da foto acima. Por ter baixo condicionamento, sua pressão sobe e seu batimento cardíaco se acelera quando passa por qualquer tipo de estresse. Já um atleta, se comporta de forma diferente. Diante de um estresse, sua pressão e seus batimentos cardíacos quase não se alteram.

Software é um organismo que enfrente os mais diversos tipos de estresses permanentemente. Ele se manifesta na forma de mudanças. Quando uma mudança é introduzida em um sistema, seu "batimento cardíado" e sua "pressão" podem variar abruptamente, ou permanecer estáveis dependendo de seu condicionamento. Sistemas bem testados, com elevada cobertura de testes, são como atletas muito bem preparados. Mudanças podem ocorrer, mas raramente irão comprometer o bom funcionamento e a boa saúde do software.

Trabalhando com TDD há alguns anos, comecei a notar o que chamaria de "paradoxo dos testes". Os testes automatizados que crio raramente detectam bugs! Não porque eles sejam ruins, ou pouco abrangentes. Simplesmente é raro introduzir um bug quando se trabalha com TDD. A forma de pensar se altera e leva você a criar código sem erros a maior parte do tempo.

O exercício de criar os testes é o que leva à baixa incidência de bugs. Então, se os testes raramente detectam erros, eu poderia deixar de produzi-los, certo? Aí é que está o paradoxo. Se eu não os escrever, começarei a introduzir mais bugs, porque o segredo está no exercício. É a mesma coisa com o corpo humano. Uma pessoa que esteja em forma aparentemente não precisaria se exercitar. Mas, se ela parar de se exercitar, começará a precisar!

Outra questão crítica na saúde de um software é a forma como ele é alimentado.

Você é o que você come. Portanto, se você só come porcaria, sua saúde tende a ser precária. Por outro lado, se você mantém uma dieta saudável, seu corpo tende a se manter em forma. Com nossos sistemas é a mesma coisa. Alimentá-los com gambiarras, código duplicado, métodos ilegíveis e outras coisas pavorosas é o que leva, gradualmente, à criação de um aplicativo moribundo, incapaz de ser alterado facilmente e propenso aos mais diversos tipos de defeitos. Portanto, alimente seu sistema com código saudável e bem testado.

Para fechar, relembrando um outro artigo fique atendo ao que acontece gradualmente com seu código, pois mudanças graduais são mais difíceis de serem notadas. Quando engordamos, fazemos isso um pouquinho a cada dia. Cada pequena extravagância diária leva o ponteiro da balança para o alto. Algumas gramas diárias à mais, se tornam muitos quilos depois de algumas semanas, ou alguns meses. Com o código é igual. Não é uma gambiarra que irá matá-lo. É a sucessão de pequenas gambiarras que vamos introduzindo a cada dia que condena nosso software ao caos e nos condena a dias estressantes tentando contê-lo.

Tags agile, java, qualidade, ruby, teste | nenhum comentário