Comentário: Não há limite para o quão ruim o código pode chegar
(Em resposta a um comentário sobre queimar tudo para começar do zero quando a dívida técnica se tornar insuportável)
Na minha experiência é tão raro para que isso funcione.
Você anuncia que o velho está irrecuperavelmente se afogando em dívidas de tecnologia. Você forma uma equipe para reescrevê-lo do zero. O trabalho começa.
Entretanto, a coisa antiga continua a ser um alvo móvel: está a gerir o negócio principal, pelo que as mudanças ainda são necessárias. Os desenvolvedores que trabalham nele sabem que em breve ele se tornará obsoleto com a novidade, então eles não têm nenhum incentivo para ir além do menor esforço possível para adicionar os novos recursos. A dívida técnica continua a aumentar.
Enquanto isso, a equipe que trabalha na novidade é ambiciosa e provavelmente um pouco ingênua. Eles começam em um ótimo ritmo – afinal, é um campo novo – mas com o passar do tempo torna-se aparente que ninguém entende completamente o comportamento e o escopo daquilo que estão substituindo. Se fosse bem documentado e testado, não funcionaria precisar afinal, será substituído…
Depois de meses (ou mesmo anos) sem entregar valor, a pressão aumenta para “enviá-lo”, então o novo sistema é lançado para lidar com um subconjunto do que o sistema antigo lidava – ou muitas vezes para algum novo recurso que era muito difícil de construir com o sistema antigo, agora praticamente sem manutenção.
… então agora você tem DOIS sistemas em produção – o sistema antigo e desajeitado que ninguém quer mexer e um novo sistema que lida com apenas alguns recursos de produção e é 80% de código inativo que pretende substituir o sistema antigo, eventualmente.
Se você estiver muita sorte a empresa não terá perdido a paciência com o novo sistema e permitirá que esse trabalho continue. Quanto mais tempo tudo isso levar, e quanto mais tempo o sistema antigo permanecer em produção e teimosamente continuar a funcionar, maior será o risco de que “as prioridades tenham mudado” e o trabalho de substituição total do novo sistema seja abandonado, deixando você com dois sistemas onde você costumava ter um.
O melhor artigo que li sobre como concluir esse processo com responsabilidade é Migrações: a única solução escalonável para dívidas de tecnologia, de Will Larson.
Se eu me deparar com uma situação como essa no futuro, minha forte recomendação será reforçar o sistema antigo com o máximo possível de testes automatizados e, em seguida, verificar se os refatoradores direcionados podem levá-lo ao formato desejado. Meu palpite é que, em muitos casos, isso terá uma chance muito maior de sucesso do que o toque de sereia de uma substituição nova.
