A Melhor Correção é Aquela Que Você Não Faz

A melhor correção é sempre aquela onde você altera o mínimo de coisas.

Parece óbvio, mas na prática a gente vê o oposto acontecendo toda hora. Alguém encontra um bug, abre o código, e começa a "melhorar" coisas. Refatora uma função aqui, ajusta uma nomenclatura ali, reorganiza uns imports. Quando vê, aquele fix de 2 linhas virou um diff de 300 linhas.

E aí, sabe o que acontece? O comportamento muda. Às vezes de forma sutil. Às vezes de forma catastrófica.

O Impacto das Mudanças é Subestimado

Muitas vezes na engenharia de software as pessoas negligenciam o impacto de mudanças. É uma falha cognitiva clássica: a gente superestima o que entende e subestima o que não vê.

Não é à toa que existem processos e protocolos a serem seguidos sempre que uma mudança é implementada. Code review, testes automatizados, feature flags, deploy gradual. O que parece burocracia na verdade é processo — e o processo é importante.

Mas por quê?

Turing e a Imprevisibilidade Matemática

Em 1936, Alan Turing publicou um dos papers mais importantes da computação. Nele, ele provou matematicamente o Halting Problem: é impossível criar um algoritmo que determine, para qualquer programa, se ele vai terminar ou rodar pra sempre.

O que isso significa na prática?

Que o comportamento de um programa de computador é essencialmente imprevisível. Matematicamente imprevisível.

Você pode ler o código linha por linha. Pode ter 100% de cobertura de testes. Pode ter toda a documentação do mundo. Mas ainda assim, você não consegue prever com certeza absoluta todos os comportamentos possíveis — especialmente em sistemas complexos e distribuídos.

Cada mudança pode abrir um número exponencial de efeitos.

Processos São Necessários, Mas Não São Suficientes

Então nós precisamos de mecanismos que diminuam a quantidade de alterações ou mudanças. Ou que pelo menos diminuam o risco de mudar um software.

Os processos ajudam. Muito. Mas eu acredito que além dos processos tem que ter também um guard rail anterior: a mentalidade de quem mexe com o software.

Dos engenheiros, programadores, arquitetos. De saber que cada mudança pode abrir um número exponencial de efeitos. Principalmente em sistemas complexos e sistemas distribuídos.

O Guardrail Mental

Esse guardrail mental é uma postura, uma disciplina:

Pensem antes de mudar.

Parece simples, mas é profundo:

• Essa mudança é realmente necessária?
• Qual é o menor diff possível que resolve o problema?
• Quais sistemas podem ser afetados?
• O que pode quebrar de forma não óbvia?
• Preciso mesmo refatorar agora, ou posso deixar pra outro momento?

Não é medo de mexer no código. É respeito pela complexidade.

Na Prática

Trabalhando com sistemas distribuídos que atendem milhões de usuários, eu vejo isso todo dia. Uma mudança "pequena" num serviço pode cascatear de formas imprevisíveis.

Então a gente desenvolve essa mentalidade:

• Mínimo viável: qual é a menor mudança que resolve?
• Isolamento: posso limitar o escopo de impacto?
• Reversibilidade: consigo voltar atrás rapidamente se algo der errado?
• Observabilidade: vou saber se algo quebrou?

Processos ajudam a executar isso. Mas a disciplina começa antes — na hora que você decide abrir aquele arquivo.

A Correção Que Não Se Faz

Às vezes, a melhor correção é aquela que você decide não fazer.

Você olha pro código, identifica o problema, e em vez de sair alterando, você pergunta:

• Posso viver com esse comportamento?
• Vale a pena o risco de mudar?
• Existe uma solução no nível de configuração ou feature flag?
• Posso resolver isso de outra forma, sem tocar no core?

Engenharia de software não é só sobre escrever código. É sobre gerenciar risco e complexidade.

E a melhor forma de gerenciar complexidade é, sempre que possível, não adicionar mais dela.

---

Pensem antes de mudar. É o que eu sempre digo.