Refatorar, reescrever ou refazer o código do zero? Depende, pois qualquer uma das opções é uma decisão que deve ser muito bem avaliada: o valor do que já foi criado, do que já está codificado, precisa ser levado em consideração quando mudanças são necessárias. Afinal, nenhum código é perfeito, nem saiu do nada.
Este dilema gera debates intensos entre desenvolvedores de software sempre que se fala sobre melhorar um “código legado”, pois envolve minúcias e metodologias.
O paradoxo do código legado:
Antes de alterar o código, você deve realizar os testes. Mas, para colocar os testes em prática, você precisa alterar o código.
Por exemplo, se o código alterar apenas algumas funcionalidades, é refatoração. Senão, é reescrita com jeito de refatoração. Parece simples, mas não é. Avaliar qual decisão é a mais adequada julgando apenas a complexidade pode levar a erros monumentais.
Em muitos casos, quanto menos experiente o desenvolvedor, maior a probabilidade de ele forçar a opção por reescrever totalmente o código. Desenvolvedores mais experientes e especialistas, por sua vez, costumam defender a refatoração é só optar por reescrever o código em último caso. Por que?
Para responder a tantas questões, é preciso invocar Michael Feathers, especialista em revitalização de códigos e design de software, que resume:
Código legado é código sem testes
Working Effectively with Legacy Code, 2004
O que isso quer dizer?
Segundo essa obra de referência, “uma boa quantidade de código legado chega a proporções que variam de 100 para 1 até 1000 para 1 de código legado em relação a código novo.
Já é alguma coisa para definir a estratégia para lidar com o código legado.
Até aqui, já se pode dizer que refatorar e reescrever são dois processos que servem para melhorar códigos de baixa qualidade, limpá-los, torná-los mais fáceis de ler e adicionar novas funcionalidades. Partindo dessa definição, é possível resumir as diferenças entre refatoração e reescritura do código.
O que é refatorar o código de software?
É o processo de alterar o código do software de forma que não mude seu comportamento externo. Esse processo normalmente significa fazer pequenas alterações de código, embora com ajustes estruturais potencialmente significativos. A refatoração serve para reduzir a complexidade e melhorar a qualidade do código, além de diminuir defeitos.
Porém, na refatoração cada segmento de código é testado antes de passar para o próximo. Agora imagine lidar com testes de centenas de milhares de linhas de código: às vezes, esta opção é impraticável por conta de tempo e custos.
O que é reescrever o código de software?
Reescrever envolve descartar totalmente o código antigo e programar de novo. Em geral, isso dá calafrios na espinha da maioria dos desenvolvedores, pois é ainda mais complexo.
É claro que a lógica e os requisitos subjacentes já estão estabelecidos; portanto, reescrever o código é indiscutivelmente mais rápido do que escrevê-lo do zero – e às vezes é mais rápido do que refatorar. No entanto, reescrever o código pode apresentar novos bugs e vulnerabilidades. Mas talvez o fator mais dolorido seja que a reescrita consome muitos recursos, já que, enquanto o código é atualizado, é preciso manter o código antigo rodando.
Isso quer dizer que o desenvolvedor trabalha simultaneamente com o código antigo e o novo, trazendo mais fragilidades, erros e bugs – o oposto do que a refatoração deve alcançar. Não é para ninguém cair aos prantos, mas às vezes isso pode continuar para sempre – o trabalho de transição nunca é concluído.
Exemplo
Digamos que sua empresa tem um aplicativo web com mais de 10 anos e que ainda funciona muito bem. Provavelmente, não é necessário reescrever tudo apenas para otimizar ou atualizar alguma funcionalidade.
Nesse caso, é recomendável fazer uma abordagem híbrida. Não é jogar tudo fora e reescrever, nem escrever do zero: o código é incrementado com novas funções aos poucos (testes, testes, testes) e melhorado ao longo do tempo. Nesse caso, enquanto a TI trabalha nas funcionalidades, também consegue manter o produto existente vivo.
Ou seja, a refatoração e a reescrita não são mutuamente exclusivas. Pode ser possível refatorar um componente, enquanto outro componente pode exigir uma reescrita. Portanto, vale a pena avaliar o software com sua equipe (complexidade de código, cobertura de testes e taxas de defeito) para formar um plano.
Há alguns fatores que dificultam a reescrita ou a refatoração:
- Mais e mais funcionalidades. Isso leva ao aumento da complexidade e da sujeira no código.
- Atalhos, “gambiarras” e improvisações para suportar coisas do tipo “Precisamos dessa nova tela de pesquisa até o mês que vem, e ponto final”.
- Rotatividade de profissionais. Os novos desenvolvedores não conhecem todas as decisões e ideias fundamentais que estão por trás da arquitetura. É inevitável que o conhecimento se perca nas transições.
- Crescimento da equipe de TI: mais pessoas, menos comunicação. Menos comunicação, más decisões.
Razões para refatorar ou reescrever o código
O código tem sérios problemas: é um pesadelo para entender e modificar com alguma segurança. Pode estar repleto de defeitos e bugs, ter vulnerabilidades de segurança e problemas de desempenho.
Pior ainda, a forma como o código foi escrito torna difícil adicionar novas funcionalidades. Em última análise, o código está impactando negativamente o valor (existente e futuro) do produto, ao mesmo tempo que representa um risco para a empresa e custos adicionais pela ineficiência.
Muitas coisas também podem mudar com o tempo – novos sistemas operacionais, dispositivos, APIs, linguagens de programação, surgimento de novas tecnologias, regulamentos de software (como a LGPD) e, é claro, a concorrência. Esses são exemplos de dívidas técnicas inevitáveis que devem fazer parte do escopo do planejamento e do orçamento da empresa.
Razões para NÃO refatorar/reescrever o código
Deixando para trás a discussão técnica, refatorar/reescrever não é adequado quando:
- O código legado, no entanto, é tão confuso que levará mais tempo para refatorar o suficiente e poder fazer qualquer coisa de forma significativa com ele. Os codificadores originais já se foram, a documentação e os comentários podem não existir.
- A reescrita só é viável se houver recursos suficientes para dividir os esforços entre manter o código existente e escrever o novo código.
- A reescrita pode dar terrivelmente errado se o esforço não for avaliado. Sempre que possível, é melhor limitar o escopo da reescrita, caso contrário, isso pode levar anos.
- A linguagem de programação utilizada no código está em declínio ou ultrapassada. Isso pode dificultar a localização de desenvolvedores que saibam lidar com a codificação.
- Quando os componentes estiverem tão intimamente ligados que uma mudança em um sistema exige mudanças em muitos/todos os sistemas, portanto, refatorar não é uma opção viável.
Razões para (SIM) refatorar/reescrever
- A maioria dos softwares é produzida para ganhar dinheiro; assim, todos os fatores envolvidos no custo de desenvolvimento de software devem ser pesados, como o orçamento e o ROI da empresa.
- Refatorar/reescrever normalmente significa criar valor ao seu produto, adicionando novos recursos ou melhorando a interface do usuário/UX para aumentar o envolvimento de seus clientes.
- Código sujo e complicado diminui a eficiência e a produtividade, desacelerando a criação de valor em toda a vida útil do software.
- A má qualidade do código pode fazer com que os desenvolvedores encontrem outro emprego, pois não são capazes de consertá-lo. A rotatividade incorre em custos ou adicionar cerca de três meses de ineficiência até a nova contratação. Vale lembrar que há uma escassez global de desenvolvedores de software.
Mas afinal, como saber quando reescrever ou refatorar um aplicativo?
Ambas as opções, no entanto, têm vantagens e desvantagens.
Refatorar o código ajuda a mantê-lo gerenciável sem grandes revisões, mas pode não configurar o aplicativo para novas tecnologias de desenvolvimento ou linguagens de programação.
Reescrever o código permite mudanças fundamentais, mas corre o risco de confundir os desenvolvedores ou até mesmo quebrar o produto.
Não pense em absolutos sobre refatorar ou reescrever código. Em vez disso, determine qual é a melhor escolha para um projeto específico. Essa decisão depende do tipo de produto, das capacidades da equipe, de seus objetivos de longo e curto prazo e sua disposição para riscos.
E o modelo híbrido?
Por exemplo, digamos que sua empresa tem um aplicativo web com mais de 10 anos e que ainda funciona muito bem. Provavelmente, não é necessário reescrever tudo apenas para otimizar ou adicionar alguma funcionalidade.
Nesse caso, a abordagem híbrida não joga tudo o que foi feito fora, nem reescreve o código inteiro: o produto é refatorado e melhorado ao longo do tempo, conforme os recursos disponíveis.
A refatoração e a reescrita não são mutuamente exclusivas. É possível refatorar um componente, enquanto outro componente pode exigir uma reescrita. Portanto, vale a pena avaliar o software com a equipe (complexidade de código, cobertura de testes e taxas de defeito) para formar um plano.
Como acontece com muitos debates fervorosos na área de desenvolvimento de software, tudo depende de vários fatores que são específicos para cada situação. Em outras palavras, não há regras gerais sobre se o melhor é refatorar ou reescrever.
A melhor opção é desenvolver uma mentalidade crítica para abordar qualquer projeto, avaliar os riscos e definir o melhor caminho a seguir. E,é claro, se nenhuma opção for viável, é melhor reescrever o código do zero.
Sua empresa quer mais do que qualidade de código? A UDS tem excelência em entregas de desenvolvimento de software, com confiabilidade, agilidade, escalabilidade e segurança em cada etapa do projeto. Conheça nossos cases de sucesso.
