Há algum tempo, mudei a forma como vejo a qualidade do código.

Antes eu via o código como uma ferramenta bem compreendida que precisa ser testada para eliminar possíveis inconsistências. Pequenos quarks em implementação, principalmente irrelevantes, devem ser mais compactados em prol da perfeição estética.

Mas depois de repetidos momentos de pura confusão, como o código sobre o qual eu tinha 110% de certeza acabou causando paralisações na produção, ocorreu uma mudança sutil, mas importante, na percepção.

Comecei a vê-lo mais como uma “máquina demoníaca do inferno”, cuja única propriedade terrível consiste em sua capacidade de quebrar no ponto exato que não foi testado.

René Descartes surgiu com um conceito semelhante, imaginando que um Demônio Maligno de “maior poder e astúcia empregou todas as suas energias para enganá -lo”. O daemon enganaria todos os seus sentidos e julgamentos e construiria uma falsa realidade em torno do observador. A questão que Descartes estava tentando responder era “o que pode ser considerado verdade objetiva”.

O que tento responder é “este código funciona corretamente”?

Você também pode pensar nisso como uma espécie de sistema quântico de bugs, que desaparece quando testado.

Ou algum tipo de lei de Murphy para engenheiros de software: “ Tudo o que não for testado irá quebrar. ”

Eu acho que você entendeu…

A ideia básica é que não se pode confiar em seu próprio código sob nenhuma circunstância.

Então... o que?

Resigne-se a uma vida de noites sem dormir, pois temo que a produção possa cair a qualquer momento.

A solução pode parecer bastante simples: basta adicionar mais testes!

Problema resolvido. Tarefa concluída. Muito obrigado.

……….

A única coisa pequena, pequena, minúscula e insignificante que resta é o fato de que, bem…

COMO POSSO SABER SE O CÓDIGO ESTÁ BEM TESTADO?

Eu poderia começar tentando testar todas as entradas possíveis e garantir que elas resultem na saída esperada. Mas mesmo que a função seja pura, e mesmo que tenha parâmetros simples (portanto, nenhuma matriz de objetos profundamente aninhados), torna-se rapidamente impossível definir o que significam “todas as entradas possíveis”.

• Para uma string, você não pode testar com todas as combinações possíveis de caracteres, em qualquer comprimento.
• Para uma data, você não pode testar nenhuma fração de milissegundos.

Testar apenas um subconjunto relevante das entradas requer um entendimento completo do código e seus pontos de inflexão, e as lacunas que existem no entendimento do código também existirão em seus testes.

De volta à mesma vala…

Uma solução alternativa e uma compensação aceitável?

Vamos tentar fazer isso de uma maneira diferente.

Quando você constrói uma ponte, precisa ser extremamente cuidadoso com as estruturas que projeta e com a maneira como testa essas estruturas. Um erro pode significar não apenas custos massivos na reconstrução, mas também vidas perdidas, caso algo dê errado.

Quando você constrói um produto físico (um micro-ondas), você acerta desde o início, caso contrário, os produtos já vendidos podem precisar ser recolhidos e reembolsados ​​(10% do total), ou a empresa pode ser processada pelos consumidores. Mas os designs podem mudar e a linha de produtos é reiniciada. O custo dos bugs é muito menor.

Quando você envia software em disquetes, precisa obter o software correto, caso contrário os clientes reclamarão e você precisará enviá-lo com conserto adicional, o que implica perda de confiança do cliente e custos extras. O custo dos bugs é ordens de magnitude menores novamente.

Mas o que acontece quando o custo da alteração é mínimo, quando as atualizações são instantâneas e obrigatórias, como em um site? Ainda há um impacto sobre o número de clientes perdidos e possíveis críticas ruins do Google, mas pode haver algo a dizer sobre o papel da correção em um mundo onde o custo da mudança é tão pequeno.

Porque a correção tem um custo.

Mais importante, o custo da correção não deve ser maior do que o custo dos bugs que ela evita.

Às vezes, pode ser mais barato mover-se rapidamente, enviar código e corrigi-lo na produção. (Blasfêmia!)

Outras vezes, se o objetivo é aumentar a qualidade do sistema, pode haver outras estratégias além de aumentar a correção:

Minimizando o custo de um bug:

• Tráfego ponderado
• Monitoramento / Alertas
• Engenheiros de plantão

• Documentação
• Depuração rápida
• Implantações rápidas

É apenas uma maneira de pensar sobre as suposições por trás de nosso trabalho diário e verificar, pelo menos de tempos em tempos, se as condições nas quais essas suposições se baseiam ainda são válidas.