Três revisores de código passaram por este bug. Nenhum viu.
O pull request tinha 200 linhas. Testes passando. Code review aprovado.
Mas escondido na linha 47, um simples == em vez de === estava desabilitando uma feature inteira de pagamento.
O JavaScript, com sua tipagem dinâmica, tratou o valor 0 como false.
E o que deveria ser uma verificação de status virou um gate que bloqueava todo o fluxo de checkout.
O time de suporte começou a receber tickets de "pagamento não processa".
A equipe de pagamentos revisou o gateway. Tudo normal.
O backend revisou a API. Tudo normal.
O frontend revisou o formulário. Tudo normal.
A solução levou 5 minutos. O debug levou 3 dias.
E o pior? Isso poderia ter sido evitado com uma configuração no ESLint:
"eqeqeq": ["error", "always"]
Uma linha no .eslintrc. Uma regra que impede exatamente esse tipo de bug.
Mas a equipe não tinha o lint configurado no CI. O commit passava sem verificação de qualidade.
Adicionamos:
- Regra
eqeqeqno ESLint,==vira erro, não warning. - Pre-commit hook com
huskyimpede o commit se o lint falhar. - CI pipeline que rejeita PR com lint errors, nenhum merge sem qualidade.
A lição?
Bugs não são sobre código complexo. São sobre código simples que ninguém prestou atenção.
== e === parecem iguais. Mas um aceita 0 == false como true.
O outro te protege.
Qual foi o bug mais "besta" que você já encontrou em produção? Compartilha aí.
Feito!
