A gente vai falar de um tema bem polêmico, que muitos programadores debatem e que é um dos principais problemas das empresas de software, no meu ponto de vista, que é a refatoração precoce de código.
Eu atuo no mercado de TI há pelo menos 10 anos e já vi isso acontecer desde empresas pequenas até em empresas gigantes: a refatoração precoce de código ou a falta de motivos claros para começar uma refatoração de código. Para quem não está familiarizado com o termo, refactoring ou refatoração é o processo de reescrever em parte ou integralmente um código, seja de um software, de um site ou de um aplicativo. Pra gente entender melhor porque esse tema é bem complexo e, muitas vezes, complicado de se administrar, vou listar alguns pontos que são importantes pra gente começar a entender a refatoração.
Quando a gente tem um sistema pronto, que já está funcionando, que está em produção e que precisa ser refatorado, ou pelo menos que a equipe entenda que faz sentido refatorar, eu sempre gosto de analisar alguns pontos para conseguir tomar uma decisão se realmente uma refatoração é necessária ou não.
Primeiro é fundamental entender se o sistema está funcionando atualmente da forma como deveria. Se o sistema está funcionando, refatorar o código não vai necessariamente impactar no funcionamento, mas pode trazer melhorias na manutenção do código, entre outros aspectos, e esse é um ponto que precisa ser analisado. Se o código não está funcionando como deveria, aí sim você tem uma alerta maior com relação à questão de refatorar. Quando o código não está funcionando a gente tem duas opções: podemos fazer um “curativo” e colocar ele para funcionar de fato, ou realmente iniciar um processo de refactoring.
O segundo ponto é entender quanto tempo vai demorar fazer essa refatoração e, junto com o tempo, a gente tem o terceiro ponto, que é o custo desse refactoring. Por que esses dois caros vêm casados, o tempo e o custo? Normalmente quando os programadores propõem um refactoring, eles não estão muito interessados em saber quais custos a empresa vai ter com aquele processo. Então, se você é o gestor ou CTO e precisa tomar a decisão de iniciar um refactoring de parte do seu sistema ou até mesmo iniciar uma nova versão desse software, você vai precisar calcular esses dois pontos: o tempo que vai levar para fazer essa refatoração e quanto isso vai custar para empresa, se o custo dessa operação compensa ou não em relação ao quanto o software gera. Existe a possibilidade de manter a versão anterior enquanto você está fazendo uma refatoração parcial do código? Fazer uma continuous integration, refatorar código mantendo uma parte em produção, refazer partes sem tirar o sistema do ar é muito mais saudável do que você parar uma operação para refatorar o código, principalmente quando esse software já dá dinheiro. Então é sempre uma balança: o software já está dando dinheiro? Quanto de dinheiro ele está dando? Se eu tiver que parar esse software, quanto dinheiro eu vou perder? Quanto vai me custar de tempo e dinheiro para poder fazer esse refactoring? Essas questões na parte de business são mais importantes até do que os benefícios em longo prazo que esse refactoring pode trazer.
Outro ponto fundamental na hora de se cogitar um refactoring é o seguinte: o que é esperado com essa refatoração? O que você está esperando mudando o código ou mudando o framework? Melhorar a manutenção desse software? Melhorar a implementação de features futuras? Ter uma melhor documentação ou atualizar o código para uma versão mais recente? Qual é o propósito básico desse refactoring? E aí a gente precisa ser muito consciente e ter bom senso para tentar entender se, de fato, vai trazer um benefício em longo prazo fazer esse refactoring ou se existem alternativas. Por exemplo, uma parte do código está difícil de dar manutenção porque um programador foi embora e deixou esse pepino para trás. Então faz sentido refatorar esse código para torná-lo mais padronizado? Talvez faça. Ou será que esse sistema pode ser isolado em um microserviço e continuar funcionando desse jeito que já está? Você ter formas diferentes de programar porque você tem vários tipos de programador é normal. Não ache que seu código vai conseguir ter uma integralidade, que todos os códigos vão ser sempre muito parecidos quando você tem uma equipe fazendo isso. Quando você tem um programador só cuidando do projeto obviamente o projeto tende a ficar mais padronizado, com o modelo que aquele programador está usando. Esse bom senso ao avaliar o que se espera dessa refatoração é extremamente importante também para chegar ao entendimento da viabilidade do refactoring.
Como programador, você precisa conseguir listar quais são os benefícios em médio e longo prazo que esse refactoring vai trazer. Mas como gestor do projeto você também precisa entender quanto tempo e dinheiro vão ser gastos nesse refactoring, para conseguir entender se a empresa está num bom momento para se fazer essa refatoração. A empresa comporta esse refactoring nesse momento? É possível parar a operação ou disponibilizar os profissionais que são necessários para fazer essa refatoração? Esses pontos precisam ser respondidos antes de se pensar em sentar para reescrever esse código. Escrever um código por si só, sem ter um planejamento e sem ter um entendimento claro dos benefícios que esse código vai gerar, não faz sentido nenhum.
Eu mesmo às vezes tenho vontade de refatorar algum código antigo, mas eu tento agir com bom senso nesses momentos e pensar em todos os aspectos antes de tomar essa decisão, principalmente se esse código é muito complexo e vai demandar muito tempo, esforço e dinheiro para que isso aconteça. Em todas as minhas empresas a gente sempre refatorou código para melhorar a usabilidade, para melhorar a documentação, para mudar de framework, para atualizar códigos, etc. Só que todas essas tomadas de decisões passaram por uma reflexão interna da equipe sobre o momento, sobre os custos e sobre a viabilidade, antes de efetivamente começar a fazer alguma coisa.
Outro ponto interessante nessa história é que quando eu começo a refatorar uma parte do código, eu nunca paro a equipe inteira para fazer isso; ou eu mesmo começo a fazer parte da base do código ou eu coloco uma pessoa para fazer, mas uma pessoa só. Você não precisa parar a equipe inteira para começar a configuração de setup e coisas do tipo. Vou dar um exemplo: em uma das minhas empresas a gente resolveu mudar do framework proprietário para um de mercado, que estava sendo desenvolvido. Mudava de JavaScript para TypeScript, a workstation era diferente, então toda a parte de configuração eu estudei, fui lá e implementei. A base que a gente tinha no nosso framework esse novo sistema já cobria, para o que não tinha suporte eu fui procurando alternativas, tipo API para elastic search e coisas que são um pouco mais específicas. A gente usou o NextJS, que é um framework de back end, e essa decisão não foi tomada da noite para o dia, demorou meses. (Vou deixar um post onde falo mais desse processo linkado abaixo)
Eu não conhecia esse framework, então fui estudar sobre ele para entender as possibilidades que ele oferecia, o quanto isso ia ser positivo para gente: a estruturação de códigos, os testes automatizados, a documentação. Esse conjunto de critérios foi avaliado até se chegar à decisão de fato de fazer a migração e eu acho que essa é a maneira mais consciente de se fazer um refactoring. Obviamente, é caso a caso, cada empresa vai ter um time diferente, vai ter as suas necessidades. Eu não tenho como saber da sua realidade, se vai demandar tempo de estudo para tomar essa decisão ou se ela vai ser imediata por uma questão de necessidade, mas eu acredito que é sempre preciso levar essa discussão muito a sério, porque pode fazer uma diferença muito grande no andamento da empresa, inclusive pode prejudicar financeiramente a empresa fazer um refactoring precoce.
Chegou ao ponto de entrar um novo funcionário em uma das minhas empresas e achar que estava tudo errado, que tinha que mudar tudo, sem de fato ter 100% de entendimento do contexto da empresa, em qual momento ela estava e tal e, infelizmente, a gente já teve até que demitir pessoas por causa desse tipo de atitude, de querer forçar a barra de uma refatoração precoce nos sistemas da empresa e acabar trazendo uma série de problemas internos.
No final da história, o que eu quero deixar de mensagem para quem está entrando no mundo de softwares é que fazer um software por si só não gera tanto valor assim, é preciso estar sempre pensando no que a gente está fazendo. Não é só sentar a bunda na cadeira e escrever código, a gente tem que pensar não só no nosso, mas pensar no bem da empresa também. Afinal, a empresa paga o seu salário e se você não pensar no bem financeiro da empresa, ela pode quebrar e te deixar desempregado. Então eu acho que é salutar para a equipe e para todo o ecossistema sempre pensar bem antes de fazer as coisas, seja uma feature nova, uma refatoração, ou qualquer outra mudança.
Esse post é um resumo do conteúdo deste vídeo:
