Vamos refatorar tudo e pronto

Este artigo, deu origem a este vídeo no (YouTube)[https://youtu.be/Wzt-t6I25_c]
Já bateu aquela vontade de refatorar tudo de uma vez ou Começar do zero o projeto, ou porque não tava do jeito que você queria, ou porque você encontrou um bug que parece que é mais fácil resolver começando tudo zero ( isso acontece com react native kkkkkkk não recomendo), ou porque você acha que a arquitetura do seu projeto não está boa o suficiente? Bom, isso também acontece comigo, mas nesse blog eu vou falar sobre quando fazer e quando não fazer esse tipo de mudança no seu projeto.

Introdução

Essa vontade esse ímpeto, vem de 2 lugares, o primeiro deles é o tal do perfeccionismo que já te faz querer começar algo no melhor estágio possível, e isso é uma presunção e prepotência sem limites. Hoje eu assisti um vídeo do canal Arthur Miller que é eu recomendo vocês assistirem, (tem 5 minutos)[https://youtu.be/6evIPCCIq0k?si=Gzg-wLrfOeG_BB5t] e ele fala sobre isso, que perfeccionismo é o medo da falha, muitas vezes você só usa isso como desculpa para não começar algo novo e falhar, como sempre falhamos.

Essa vontade de refatorar tudo, também pode vir de um outro lugar, que é quando você olha para algo que fez, e entende com o seu conhecimento atual, que aquilo não é tão bom quanto você achava que era na época. E isso é bom, porque mostra que você aprendeu, mas também, pode se tornar uma armadilha, porque, sempre que você aprender algo novo ou se deparar com um problema, você vai lá e re-começa tudo do zero? Isso não é produtivo, e existem formar melhores de se aplicar o conhecimento novo, sem necessariamente refatorar tudo ou começar do absoluto zero.

Minha experiência

Quando eu comecei a programar, eu fazia muito código ruim (até hoje faço alguns), mas naquela época era pior, e como eram projetos simples, dificilmente eu refatorava, o que acontecia é que eu estava sempre codificando algo e estudando, então sempre no próximo projeto eu estava aplicando coisas novas, outras coisas que aconteciam era que por estudar algo, eu ficava empolgado e já fazer alguma coisa, lógico que tudo ia pro lixo, mas ficava o conhecimento, e quando chegava um projeto para valer, no trabalho ou algum freelance, eu já estava mais experiente e podia fazer algo melhor. A real é que dificilmente eu refatorava um projeto já existente, eu sempre começava um novo, mesmo que fosse uma versão do anterior, porém melhorada, muito difícil pegar um código e mudar. Isso porque era mais fácil começar certo, do que ir corrigir as minhas gambiarras lá. Mas tem um detalhe, isso só será possível, porque os projetos eram para estudo, não eram projetos de produção, eram projetos que eu fazia para jogar fora, então não importa, e podia simplesmente começar de novo para melhorar sempre.

Projetos em produção – Refazer do zero

Quando você tem um projeto em produção, com algum cliente usando, ou até mesmo um projeto super extenso, recomeçar do zero é muito difícil, imagina, migrar usuários, migrar dados e etc. Além de todo trabalho e esforço para garantir que tudo está bem, nesses cenários, existem poucas situações que de fato justifiquem começar um projeto do zero novamente, porque envolve muitos riscos, então para aceitar esse risco, os ganhos precisam ser claros.

Esses motivos são:
1 - O projeto utiliza versões de software que não são mais mantidas, e não tem uma forma fácil de substituir essa dependência crucial do seu projeto, a gente chama isso de END OF LIFE, quando algum software que é a base do teu projeto, simplesmente não pode ser mais usado justamente por introduzir problemas que não terão solução, e essas correções vão quebrar funcionalidades e causar um efeito em cascata.
2 - Custo de manutenção supera o custo da reescrita: Ou seja, custa mais caro manter o projeto dentro de um determinado período de tempo, do que se nesse mesmo período de tempo você reescrevesse ele, por exemplo, adicionar funcionalidades leva muito tempo, deploys levam muito tempo, qualquer problema é impossível de debuggar, fazer o onboarding de novas pessoas no produto se torna impossível justamente porque demora muito para eles se tornarem produtivos ao entrarem no projeto.
3 - O Projeto não resolve o problema: O sistema foi escrito para resolver o problema X, mas resolve Y, e não é possível reverter esse cenário, logo você reescrever vai ser importante.

E nesses casos, vão existir várias estratégias de migração, e uma muito usada é aquela onde você mantém o sistema novo e o sistema antigo funcionando, criando funcionalidades novas no sistema novo, migrando as funcionalidades do sistema antigo para o novo, por algum momento você vai replicar dados e etc, mas aos poucos os dados vão sendo migrados, e ai quando terminar de migrar aquela funcionalidade, você desliga o modulo antigo, e continua a migração.

Eu mesmo trabalhei 2 anos fazendo isso, era uma empresa alemã que trabalhava com um software legado de 30 anos feito em oracle forms, e eu fazia parte do time de construção da nova versão em java com front em angular, e parte do meu trabalho era acessar o sistema antigo, e ver como as coisas funcionavam para replicar ou melhorar no sistema novo. E muitas vezes o teste também era redirecionar o ApiGateway para redirecionar o fluxo para nova versão e testar.

Refatoração

Mas se eu preciso fazer mudanças, e meu projeto não se encaixa em nenhum desses, como resolvo o problema? Você faz pequenas refatorações e mudanças no projeto, e sempre testando.

Na PitchYn, no backend tivemos um caso onde precisávamos atualizar a versão do SpringBoot, porque já estava entrando em uma que estava ficando sem suporte, e precisamos fazer o upgrade para a mais recente, nesse caso tudo tranquilo até que nós vimos uma mudança critica no Spring security, que forçou uma refatoração de toda essa parte do sistema para que fosse resolvida, e no final deu certo.

Passamos pela mesma situação com o app ReactNative, onde uma atualização foi necessária, e nesse cenário eu realmente cheguei a pensar que poderia ser melhor reescrever tudo do zero, do que ficar corrigindo aqueles erros, porque pegamos: mudança de arquitetura do react, mudança de versões de dependências do projeto. Mas resisti a tentação e só foquei em resolver os problemas, porque do ponto de vista prático, não valia a pena reescreve todo o front, e essa idea de reescrever o projeto, se mostrou mais uma fuga, do que uma solução real pros problemas.

Conclusão

No final do dia se o seu código feio funciona em produção, sem problemas, sem falhas de segurança, os clientes estão felizes, legal, continue com ele, fazendo pequenas refatorações e melhorias quando der, porque é sempre bom melhorar. Muitas vezes essa ideia da otimização infinita, pode acabar atrapalhando a continuidade do software, se tornando um ralo de dinheiro e uma armadilha que te faz perder muito tempo, por isso resista, e entenda que não existe nada perfeito, e sim, coisas que atendem ao propósito para qual foram criadas, sem esquecer que a qualidade é importante. Se quiser assistir o vídeo, link está (aqui)[https://youtu.be/Wzt-t6I25_c]