“Se funciona, não mexa” — o que é, essência do princípio e riscos

O que é o princípio “se funciona, não mexa”?

“Se funciona, não mexa” — é uma regra empírica que adverte os desenvolvedores contra fazer alterações no código que funciona sem motivos suficientes. O princípio baseia-se em estatísticas simples: a grande maioria dos defeitos é introduzida durante a modificação do código existente.

O princípio não é um dogma — é antes uma heurística que ajuda a tomar decisões em condições de incerteza. Quanto mais complexa e emaranhada for a base de código, maior a probabilidade de que uma alteração “inocente” quebre algo que ninguém esperava quebrar.

De acordo com um estudo da Microsoft Corporation (2024), cerca de 60% de todos os incidentes críticos em produção estão relacionados a alterações recentes no código que foram feitas com boas intenções, mas não foram suficientemente testadas em condições reais de carga.

História e origem do princípio

O idioma “Se não está quebrado, não conserte” remonta à cultura de engenharia americana de meados do século XX. O uso documentado mais antigo é atribuído a Bert Lance (1977), que trabalhava no Comitê de Finanças do Senado dos EUA e se opunha à regulamentação excessiva.

Na programação, o princípio veio da engenharia de hardware, onde substituir um chip funcional por um novo podia levar a consequências imprevisíveis. No contexto do software, este princípio ganhou especial força com a crescente complexidade dos sistemas de software e o surgimento do código legado.

Curiosamente, na programação, o princípio tem um lado inverso — “funciona, mas é melhor não mexer” torna-se frequentemente uma desculpa para evitar a refatoração, o que a longo prazo leva a um acúmulo crítico de dívida técnica. Segundo a consultoria Thoughtworks (2023), cerca de 40% dos projetos enfrentam problemas graves devido ao conservadorismo excessivo em relação a mudanças.

Quando aplicar o princípio

O princípio “se funciona, não mexa” é especialmente relevante em situações onde o custo de um erro supera o benefício potencial das mudanças.

Projetos legados sem testes

Em código legado que não é coberto por testes, qualquer mudança é uma roleta-russa. Se um desenvolvedor não pode verificar que a mudança não quebrou módulos adjacentes, a melhor estratégia é não mexer no código que funciona. A exceção são apenas bugs críticos ou requisitos de segurança.

Sistemas críticos

Em sistemas onde o tempo de inatividade é inaceitável ou o custo de um erro é enorme — software médico, aviônica, transações financeiras — o princípio “se funciona, não mexa” é o padrão de fato. Qualquer mudança passa por aprovação e testes em várias etapas.

Prazos apertados

Se o lançamento é amanhã e o código funciona — não tente melhorar sua arquitetura. Altere apenas o que afeta diretamente a funcionalidade do lançamento. Adie a refatoração para a próxima sprint (mas não se esqueça dela).

Riscos de seguir o princípio

Seguir cegamente o princípio “se funciona, não mexa” traz riscos não menores do que a refatoração interminável. Vamos examinar os principais perigos.

Acúmulo de dívida técnica

Se cada desenvolvedor seguir este princípio, a base de código rapidamente se transforma em um “bolo de camadas” de soluções obsoletas, gambiarras e algoritmos subótimos. Mais cedo ou mais tarde, a dívida técnica torna-se insustentável — qualquer mudança requer semanas de análise.

Otimização perdida

Às vezes, uma mudança que parece arriscada na verdade melhora significativamente o desempenho ou a segurança. O princípio “se funciona, não mexa” não deve bloquear mudanças que tragam benefícios mensuráveis — reduzir custos de servidor, acelerar o carregamento de páginas, melhorar a segurança.

Perda de competências

Quando uma equipe não mexe em certas partes do código por anos, ela perde a compreensão de como funcionam. O desenvolvedor-chave sai — e o código torna-se legado sem possibilidade de suporte. O princípio deve ser aplicado considerando a manutenibilidade de longo prazo do projeto.

O meio-termo: refatoração sem fanatismo

A estratégia ótima é não seguir o princípio cegamente, mas aplicá-lo conscientemente, levando em conta o contexto. A refatoração é necessária, mas deve ser segura.

A regra do escoteiro

A regra do escoteiro na programação: “Deixe o código mais limpo do que o encontrou.” Se um desenvolvedor está fazendo uma alteração em um módulo, ele deve melhorar sua estrutura, mas dentro de limites razoáveis. Não reescrever tudo do zero, mas pelo menos renomear variáveis ilegíveis e adicionar comentários.

Refatoração sob proteção de testes

Testes são a única maneira de aplicar com segurança o princípio “se funciona, não mexa”. Se o código está coberto por testes, qualquer refatoração torna-se previsível: o desenvolvedor altera o código, executa os testes e vê se algo quebrou. Sem testes — não mexa. Com testes — refatore com confiança.

// Exemplo: refatoração segura com cobertura de testes
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // Código antigo mas funcional
        return basePrice - (basePrice * discount / 100.0)
    }
}

// Teste que protege contra regressão
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

Este exemplo demonstra a abordagem correta: primeiro o teste, depois a refatoração. Se o teste passa, a mudança é segura. O princípio “se funciona, não mexa” transforma-se em “se funciona sob testes, refatore com confiança.”

Exemplos reais da prática

Vamos examinar cenários reais onde o princípio “se funciona, não mexa” se mostrou tanto salvador quanto destrutivo.

Caso salvador: problema semelhante ao Y2K

Um desenvolvedor descobriu que o código de processamento de datas usava o formato DD/MM/AA em vez de AAAA. O código funcionava corretamente de 2000 a 2025. Apesar do desejo de “corrigir”, ele deixou o código como estava, limitando-se a um comentário. Em 2026, a empresa atualizou o sistema, e a nova solução lidava corretamente com os séculos. Uma mudança prematura teria quebrado a lógica funcional.

Caso destrutivo: perda de dados devido a “melhoria”

Um engenheiro decidiu “melhorar” o código antigo mas funcional de importação de dados, substituindo-o por uma biblioteca moderna. Ele não considerou que a biblioteca antiga lidava com um caso extremo específico que não estava documentado. Após o lançamento — perda massiva de dados. O princípio “se funciona, não mexa” foi violado, e o custo do erro foi de duas semanas de trabalho da equipe para recuperação.