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.".
Top comments (0)