Regra 2: Bugs são contagiosos
Tags: programming, learning, cleancode, testing
Published: 2024-07-16 15:16:58

Série de artigos sobre o livro **As Regras da programação** de Chris Zimmerman. O livro trata de 21 regras que ajudam programadores a criarem códigos melhores. Falarei um pouco sobre cada regra do meu ponto de vista trazendo alguns exemplos e opiniões sobre o livro, com o objetivo principal de consolidar e compartilhar o conhecimento.

---
Segundo o dicionário de _Oxford_, esta é a definição de bug: **defeito, falha ou erro no código de um programa que provoca seu mau funcionamento**. Fica claro por essa definição que o bug é algo que atrapalha o funcionamento de um software levando a consequências como um sistema inutilizável, a perda de credibilidade com usuários e até mesmo a perda de dinheiro em situações mais graves.

Por que os bugs são contagiosos? A partir do momento que existe um bug acabamos (sem querer ou sem saber) escrevendo código dependente dele e então criamos um emaranhado de problemas. **A melhor maneira de interromper esse contágio é eliminando os bugs o mais cedo possível, antes que sua influência maligna possa se alastrar.**

O livro traz algumas sugestões de como podemos evitar esses problemas. Primeiramente ele relata como **não podemos depender dos usuários do sistema para identificar os bugs**, pois nem sempre eles percebem os problemas e quando percebem podem pensar é aquilo é uma resposta natural do sistema. Logo uma das maneiras mais adequadas como "primeira defesa" contra os bugs são os **testes automatizados contínuos**.

Sobre os testes o autor diz: "De modo geral, a ideia é a de que o sistema (ou melhor, o projeto inteiro) tenha um conjunto de testes que você possa executar de maneira rápida e conveniente para colocá-lo totalmente em funcionamento e detectar problemas.". Através dessa estratégia qualquer bug encontrado poderá ser rapidamente corrigido.

Escrever testes pode custar caro e demandar tanto tempo quanto escrever o próprio código, mas o custo de resolver possíveis problemas no sistema completo do futuro é muito maior.

Porém nem todo sistema é totalmente testável, muitas vezes existem varias dependências ou casos em que não sabemos como medir o sucesso daquele código. Pra esses momentos o conselho é "Teste o que puder, controle o que puder e lembre-se de que não está testando tudo.", ou seja, **qualquer parte do código que não for coberta por seus testes automatizados terá quer ser testada manualmente. Planeje isso!**

Outra boa sugestão do livro é estruturar o código para torná-lo mais fácil de testar. Uma estratégia importante é a **redução da quantidade de informações de estado no código**. Esse tipo de código (_stateless_) além de ser mais fácil de testar é também mais fácil de criar. Sempre que possível utilize **funções puras** (uma função que só depende de suas entradas diretas, não tem efeitos colaterais e tem resultados previsíveis)

**Se não puder eliminar estados, audite seus dados.**

Pra finalizar nas palavras do autor "Um código mais fácil de testar - ou, melhor ainda, que teste a si mesmo continuamente - permanece íntegro por mais tempo. Isso significa menos problemas para corrigir e correções mais fáceis de fazer quando forem necessárias.".