Mais um pedido de Socorro! Refatorar ou Refazer?

É muito difícil responder isso. Não é tão simples, envolve questões políticas também. Pode precisar de muito mais informações, mas pode ser que apenas uma dê para decidir.

Vou dar um exemplo de um sistema que peguei em um emprego novo que tive que tinha 120 mil linhas de códigos, e quando liguei o warning pela primeira vez na vida dele deu 600 mil, ou seja, 5 por linha de código. Tecnicamente não tinha dúvidas, justifiquei mais do que isso e pedi para começar do zero. O diretor não aceitou, pronto, estava decidido.

Se você tem certeza que dá consideravelmente mais trabalho e ninguém te impede, então não tem porque decidir diferente. O problema é que as pessoas costumam errar no trabalho que dará refazer. Precisa ter muita experiência para perceber se realmente dá menos trabalho, e geralmente só se vai mudar completamente a filosofia, se já tem uma base boa para começar outro. Tem que ter certeza que terá muito benefício. Eu sou favorável a refazer coisa ruim, mas sei que a maioria tomará essa decisão de forma equivocada.

• 5 anos é pouco para algo ser velho, tem sistemas rodando bem com dezenas de anos, até mesmo rodando em console, mas isso não diz muito também
• quem fez não determina muito, tem que ver o código
• Muita boa prática que as pessoas seguem na verdade são más práticas (tenho palestra sobre isso, esse erro é cometido até por experientes), então sem saber mais sobre isso pode não ser problema
• SOLID é uma dessas boas práticas, têm sistemas SOLID mais mal feitos que outros que não seguem. Em alguns casos fazer SOLID pode ser uma má prática, o maior erro é não considerar contexto e seguir receita de bolo cegamente, então pode trocar um ruim por outro ruim, só que quem refez acha que está bom
• A falta de canonicidade é grave, mas pode ser resolvido incrementalmente. Na maioria das vezes não precisa refazer por causa disso
• Número disso ou daquilo não indica que algo é ruim, pode mudar e passar ter outro problema, toda moeda tem dois lados, nenhum vale mais. Pode ter motivo para ser assim, tem que ver o caso específico, pode ser um ou dois casos, não justificaria
• Ser escalável não é necessariamente um defeito, pra quem fazer algo que não será usado?
• Problemas pontuais de forma geral podem ser refeitos pontualmente sem o sistema inteiro sendo refeito, embora é claro que olhando os detalhes pode encontrar algo muito crítico, pode ter o banco de dados usado de forma errada.

Se tudo isso junto torna inviável, então deve refazer. Mas pelas observações eu tenho a impressão que o sistema terá um monte de coisa nova que talvez não justifique.

Tem o lado de quem vai por a mão e não quer mexer em algo claramente ruim, mas ruim não é o mesmo que inviável. De outro lado tem quem paga. Será que realmente sai mais barato refazer? Vai dar orçamento fechado? Se der, então o problema é seu.

Eu entendo tudo isso que fala, e pode ser um caso para refazer, mas nunca é tão simples quanto parece. No fim das contas é você que terá que conviver com o rolo atual ou ter o trabalho de fazer do zero. Não existe cenário similar, cada detalhe muda o cenário. Se encontrar algo similar então só está ruim porque seguiram as tais boas práticas e ficou tudo ruim. Porque só terão dois sistemas parecidos quando seguiram receitas de bolo que divulgam por aí. Se fizeram sem seguir nada, fica aleatório, um não será igual a outro.

Não sei se consegui ser claro que sempre é mais difícil do que parece refazer do zero, especialmente reproduzir as mesmas regras de negócio. Em geral não conseguirá, não terá quem consiga ajudar da mesma forma. Quem vai usar precisa saber antes que não será igual. Não dará resultados iguais, a não ser por sorte, e a usabilidade mudará. Muitas vezes os usuários se rebelam porque preferiam usar o antigo, mesmo que ele fosse pior.

Veja mais: https://www.tabnews.com.br/sucoDeMaracuja/se-voce-pensa-em-refazer-um-projeto-do-zero-voce-nao-amadureceu-o-suficiente

Faz sentido para você?

Espero ter ajudado.

---

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

Sobre reescrever tudo, este artigo dá um ponto de vista interessante.

Só pra resumi-lo (mas recomendo que leia), a ideia defendida lá é que código velho não é necessariamente ruim, e código novo não garante que vai ficar melhor.

Um dos argumentos é que, por pior que seja, o código antigo possui certas características que são difíceis de reproduzir fielmente, caso sejam reescritos. Por exemplo, o código antigo já foi muito usado e testado em condições reais. Com isso, vários bugs - inclusive aqueles mais raros, que só aparecem em condições bem específicas - foram encontrados e corrigidos ao longo do tempo.

Muitas vezes aquela função com vários if's foi o resultado desse processo: cada if ali pode ser para arrumar um desses bugs. Poderia ter sido feito de forma melhor? Sim, talvez valha a pena refatorar apenas esta parte, quebrando a função em várias, por exemplo. Mas talvez não justifique reescrever tudo. Cada caso é um caso, tem que analisar não só a parte técnica, mas também os demais recursos: o tempo, dinheiro e as pessoas disponíveis que temos dá para refazer quanto? Mas também temos que evoluir o sistema, corrigir bugs, adicionar funcionalidades, e o prazo está apertado. Dá pra encaixar a reescrita de algumas partes nesse cronograma?

Por experiência própria, o que vejo acontecer com certa frequência é tentar encaixar pequenas melhorias e refatoramentos durante o desenvolvimento de alguma atividade. Já que vamos ter que mexer neste pedaço do código para adicionar a funcionalidade X, aproveita e refatora essa parte. Isso costuma ser mais factível e realista do que parar pra refazer tudo.