Coisas que Você Nunca Deve Fazer, Parte I (2000)
Reescrever um grande sistema de software do zero muitas vezes é visto como uma fuga tentadora do código legado confuso, mas os comentaristas argumentam que isso geralmente subestima o valor embutido no sistema existente e o tempo necessário para alcançar paridade de funcionalidades. Muitos enfatizam refatoração incremental, testes fortes e documentação como caminhos mais seguros, ao mesmo tempo em que reconhecem casos raros em que o código está tão quebrado, os requisitos ou a tecnologia mudaram tanto, ou as restrições de desempenho são tão severas, que uma reescrita completa pode ser justificada. A conversa destaca o apelo psicológico de projetos greenfield, os riscos de negócio de reescritas que ficam paradas e a necessidade de distinguir codebases pequenas e reescrevíveis de sistemas críticos com milhões de linhas de código.
Sentimento geral em relação a reescritas completas
- Muitos comentaristas ainda concordam que reescritas totais geralmente são arriscadas e muitas vezes movidas mais por psicologia do que por necessidade.
- Outros argumentam que, em sistemas menores (de dezenas de milhares de LOC) ou em codebases realmente patológicos, começar do zero pode ser a escolha mais pragmática.
- Há críticas a tratar “nunca reescreva” como uma regra universal; contexto e escala importam.
Por que reescritas são tão tentadoras
- Trabalho greenfield é mais divertido; você evita restrições de legado, dores de operação e história confusa.
- Desenvolvedores ხშირად acreditam que podem “fazer direito desta vez”, armados com requisitos conhecidos e retrospectiva.
- É mais fácil ler o seu próprio estilo do que o dos outros, então o código existente parece pior do que talvez seja.
- Reescritas podem restaurar uma sensação de autonomia e controle, às vezes de forma inconsciente.
Argumentos a favor de refatoração e mudança incremental
- A refatoração incremental preserva um sistema funcionando, permite entregar continuamente e reduz o risco.
- Remover código morto, isolar áreas ruins e melhorar gradualmente a arquitetura são vistos como abordagens mais sustentáveis.
- Testes abrangentes e documentação confiável reduzem significativamente a vontade de reescrever, tornando a mudança mais segura.
- Alguns comparam refatoração vs. reescrita a reforma vs. revolução: revoluções geralmente terminam mal, mas a recusa em reformar também leva a explosões.
Quando reescritas podem ser justificadas
- Quando o sistema existente é um “monolito/obelisco zangado” em que mudanças quebram produção de forma imprevisível e a velocidade de entrega colapsou.
- Quando muita da funcionalidade existente não é mais necessária, de modo que o novo sistema é substancialmente mais simples.
- Quando a linguagem/framework/arquitetura original bloqueia fundamentalmente o desempenho ou a evolução necessários.
- Quando a qualidade do código é “ruim tipo dois”: nenhuma estrutura, nenhum controle de versão, arquivos únicos enormes, caos de copiar e colar.
- Vários relatam reescritas bem-sucedidas de 50–100K LOC feitas por equipes experientes, profundamente familiarizadas com o domínio.
Falhas, escala e fatores organizacionais
- Reescritas grandes, de vários anos, frequentemente emperram: equipes acabam mantendo tanto o sistema antigo quanto o novo em produção.
- São dados exemplos de reescritas em grandes empresas que ficam arrastadas, superprojeto de segundo sistema e equipes que simplesmente não conseguem executar uma substituição greenfield complexa.
- Alguns observam que reescrever pode ser uma mudança de carreira discreta: inicia-se a reescrita, aproveita-se a programação greenfield, e sai-se antes que surjam o suporte e os compromissos difíceis.
Outros temas
- Debate sobre se o código é mais difícil de ler ou de escrever; a maioria concorda que o entendimento profundo é a parte difícil.
- Frameworks são discutidos como uma forma de padronizar idioms e facilitar a integração; outros contrapõem que frameworks também podem ser ruins e não são uma solução universal.