Ao corrigir bugs em um código existente, é fácil cair no hábito de encontrar o “erro” no código e ajustá-lo para evitar o erro. Mas se a causa raiz do problema foi um erro de design ou um problema com o algoritmo, então apenas adicionar outro sinalizador ou instrução goto no código é a abordagem errada. Você não apenas deixou a causa raiz intacta, mas agora tornou o código mais difícil de entender para o próximo engenheiro de software que tiver que descobrir o que está acontecendo.
Treine-se para perguntar “como eu teria resolvido esse problema se fosse o programador original?” Em seguida, observe a diferença entre a abordagem da “folha de papel em branco” e a que está realmente diante de você. Mas seja pragmático. Certamente não estou sugerindo que você deve reimplementar uma função porque você e o autor têm uma abordagem diferente. Considere essa etapa como um experimento mental. Você tem um caso de teste que falha. O autor não percebeu esse caso. O que o levou a não perceber esse caso? Se o autor soubesse desse caso, como sua abordagem teria sido diferente? Esse tipo de pergunta é inestimável ao analisar um código que basicamente funciona, mas ainda tem alguns bugs.
No nosso caso, em vez de adicionar outro parâmetro a uma função interna e adicionar outra variável automática que precisava ser inicializada corretamente em três pontos de entrada diferentes para o procedimento principal, além de adicionar código para testar essa nova variável em um ponto crítico, percebi que poderíamos reparar o algoritmo alterando a ordem em que as subetapas eram executadas. Depois de fazer isso, a necessidade de variáveis adicionais e casos especiais desapareceu. O código final é, na verdade, muito mais fácil de entender do que o código original, sem falar na primeira tentativa de reparo. Isso me dá confiança de que estamos no caminho certo. O caso de teste que reproduz o problema provou que tanto a correção original (excessivamente complexa) quanto a correção revisada (simplificada) resolvem o problema. Agora só precisamos ter certeza de que não quebramos nada mais.
Como essa correção será lançada em campo (ou seja, já está instalada nas instalações dos clientes), também realizaremos três tipos de testes de regressão intensivos. Dois deles verificarão a conformidade contínua com o padrão POSIX (a correção do bug está no código que implementa uma função POSIX), e o terceiro tipo de teste é um teste de regressão geral em nível de sistema.
Primeiro, corrija o algoritmo. Quando o algoritmo estiver correto, lide com o código.