Seja qual for a escolha, resista à tentação da inadimplência.
O desenvolvimento de software é um campo que não carece de debates. Mas se eu tivesse dificuldade em escolher o mais acalorado, essa seria a disputa “refatorar ou reescrever”. Como uma rápida pesquisa no Google pode mostrar, existem tantas opiniões quanto desenvolvedores de software, então chegar a um entendimento é algo próximo de uma utopia.
No entanto, as equipes de engenharia de software se deparam com essa escolha com mais frequência, por isso não é incomum que as pessoas recorram a essas opiniões em busca de ajuda. Porém, como os pontos de vista são tão variados, fazer isso acaba parecendo um ato de fé.
Eu (ou qualquer outra pessoa) não posso fornecer uma resposta direta porque não existe uma. Assim como acontece com muitas coisas no desenvolvimento de software, tudo depende de vários fatores que são específicos de cada situação. Em outras palavras, não existem regras gerais sobre se você deve refatorar ou reescrever seu código – mesmo quando muitos especialistas ou desenvolvedores experientes afirmam que um ou outro é o melhor curso de ação.
Na minha opinião, é melhor desenvolver uma mentalidade crítica para abordar qualquer projeto que possa ser refatorado ou reescrito. Munido dele, você pode avaliar qualquer cenário que encontrar na natureza e definir o melhor caminho a seguir. Continue lendo para descobrir quais coisas você precisa manter em mente. Mas primeiro, vamos ter certeza de que estamos na mesma página.
Refatorar e reescrever
| Critério | Código de refatoração | Reescrever código |
|---|---|---|
| Papel principal | Melhore o design do código existente sem alterar seu comportamento externo | Substitua o código existente por uma nova versão que forneça a mesma funcionalidade |
| Tarefas chave | Limpeza de código, otimização, remoção de redundância, melhoria da legibilidade | Começando do zero, projetando, codificando e testando |
| Habilidades necessárias | Compreensão da base de código, bom conhecimento da linguagem de programação, técnicas de refatoração | Forte conhecimento da linguagem de programação, princípios de design de software |
| Consumo de tempo | Geralmente menos demorado, feito de forma incremental | Mais demorado, toda a base de código precisa ser reescrita |
| Risco | Menor risco, pois as mudanças são pequenas e incrementais | Maior risco, novo código pode introduzir novos bugs |
| Custo | Geralmente menor, pois não requer uma reescrita completa | Maior, pois requer redesenvolvimento completo |
| Erros existentes | Pode ajudar a identificar e corrigir alguns bugs existentes | Bugs existentes podem ser eliminados, mas novos podem ser introduzidos |
| Compreensão do código | Aumenta a compreensão da base de código pelos desenvolvedores | Pode melhorar ou diminuir a compreensão, dependendo da complexidade do código |
| Impacto na funcionalidade | Não adiciona novos recursos, concentra-se em melhorar o código existente | Pode adicionar novos recursos e melhorias junto com a reescrita do código existente |
| Teste | Requer testes, mas geralmente menos extensos devido a pequenas alterações incrementais | Requer testes completos de todas as funcionalidades |
| Melhor para | Bases de código que precisam de pequenas melhorias ou apresentam problemas de manutenção | Bases de código difíceis de manter, entender ou mal estruturadas |
| Resultado | Melhor qualidade de código, capacidade de manutenção e desempenho potencialmente melhor | Nova base de código, potencialmente com melhor estrutura, desempenho e novos recursos |
Um dos problemas mais comuns que você encontrará nos artigos que abordam esse debate é que seus autores geralmente não esclarecem o que querem dizer com refatorar e reescrever. Talvez seja porque eles acreditam que os desenvolvedores sabem do que estão falando. Embora isso possa ser verdade (qualquer desenvolvedor conhece essas práticas, independentemente de sua experiência), o problema é que não existe uma definição universal delas.
Então, para evitar qualquer confusão, direi o que penso deles. Pode ser diferente da sua definição, e tudo bem. Não estou tentando convencê-lo a usar essas definições. É principalmente para esclarecer sobre o que falarei quando me referir a ambos mais tarde.
Eu sou mais da escola Martin Fowler quando se trata de reestruturação. Isso significa que, sempre que falo em refatoração, refiro-me a alterar o design de algo sem impactar seu comportamento. Trata-se de retocar o código para aumentar sua qualidade enquanto o software permanece o mesmo. Assim, o resultado parece o mesmo, mas oferece melhor desempenho, segurança, integra-se melhor com tecnologias mais recentes e é mais escalável, entre outras coisas.
Uma reescrita, por outro lado, é riscar todo o código existente e começar do zero para chegar ao mesmo lugar (ou até mesmo a um lugar melhor). Isso significa compreender o software como ele é e recriá-lo por meio de um novo código. Poderíamos dizer que esta é a “opção nuclear”, na medida em que nos livramos do que temos para fornecer uma alternativa melhor.
Em geral, os desenvolvedores adoram reescrever as coisas. Há vários motivos para isso: é mais fácil começar do zero, você não precisa se preocupar com coisas quebrando porque está ajustando partes específicas do código, você pode criar um produto melhor – você pode até escrever uma documentação melhor para ele enquanto você estamos reescrevendo! No entanto, acreditar que reescrever é superior por causa dessas coisas significa ignorar voluntariamente outros aspectos cruciais que acompanham a decisão de reescrever em primeiro lugar.
Vamos ver alguns deles.
Além de reescrever a canção da sereia
Todos os motivos que mencionei acima são as primeiras coisas que vêm à mente quando os engenheiros de software se deparam com um software antigo e de baixo desempenho. Tudo termina da mesma maneira – engenheiros querendo reescrever para começar do zero. No entanto, os desenvolvedores raramente são os únicos a decidir o destino de um software. Na verdade, algumas considerações costumam ser mais significativas ao decidir o caminho a seguir.
Destes, os impulsionadores empresariais estão no topo da lista. Uma reescrita (especialmente de software complexo) pode ser uma tarefa demorada que pode acabar custando muito dinheiro sem nenhuma vantagem real do ponto de vista comercial. Talvez reescrever o software consuma muitos recursos que impedem a equipe de se concentrar em tarefas mais valiosas. Talvez o software reescrito não tenha ROI suficiente para justificar a reescrita em primeiro lugar. Dessa forma, as reescritas muitas vezes podem ir contra os objetivos de negócios, um dos principais motivos pelos quais são rejeitadas.
Isso nos leva aos riscos associados à reescrita. Talvez reescrever todo o software possa ter um impacto nos negócios, mas, no tempo que leva para ser concluído, permite que a concorrência lance um produto semelhante no mercado mais rapidamente. Pode haver novos concorrentes no mercado assim que você concluir a reescrita. Ou talvez o dinheiro que você investe na reescrita o impeça de investir em um ativo mais estratégico (seja ele tecnológico ou não).
Finalmente, existem certos aspectos relacionados diretamente ao próprio software. Talvez o software que você deseja reescrever não seja de fácil manutenção, mas é resiliente, oferece bastante segurança e tem um excelente desempenho. Se você não tiver certeza absoluta de que pode replicar tudo isso, reescrevê-lo pode acabar saindo pela culatra. Você pode terminar com um software de manutenção mais fácil que não seja tão resiliente, seguro ou que tenha um desempenho pior do que o que você tinha antes.
Apresentar essas considerações não significa que reescrever seja uma má opção (estou tentando evitar os extremos a todo custo). Em vez disso, fornecem as informações necessárias a serem levadas em consideração na tomada de decisão. Assim, eles ajudam a traçar um quadro mais realista do que a reescrita pode significar.
Projetando uma abordagem crítica
Como reescrever é o que a maioria dos engenheiros de software considera quando precisa melhorar um sistema existente, é essencial começar por aí. Considerar os motivadores de negócios e os riscos associados pode ser uma ótima maneira de decidir se uma reescrita é adequada para você. Em termos simples, você precisa definir se reescrever é uma opção viável para você antes de considerar os aspectos técnicos de tudo.
No entanto, há uma coisa complicada em fazer isso. Você pode estar considerando reescrever ou refatorar porque tem muitas dívidas técnicas ou seu software está quase obsoleto. Nesse cenário, ambas as opções são arriscadas. Se você permanecer o mesmo simplesmente porque as coisas funcionam, você corre o risco de que seu software não resista por muito tempo, seja impossível de manter em um futuro próximo ou não seja escalável. Se você reescrevê-lo, poderá não obter os mesmos recursos.
Isto significa que não existe uma opção isenta de riscos – considere as suas e esteja ciente delas, mas não baseie a sua decisão apenas nos riscos (ou na ausência deles), simplesmente porque não existe um cenário em que você estará livre deles. .
Então, a melhor maneira de ver isso, na minha opinião, é a seguinte:
- Considere as implicações comerciais de qualquer uma das opções. Quais são as suas potenciais consequências?
- Analise e avalie os riscos. Uma das opções pode ser mais arriscada que a outra, mas não necessariamente. Você entende o que significa seguir um caminho ou outro?
- Descreva os motivos pelos quais você deseja refatorar ou reescrever. O que você está tentando realizar?
- Identifique o quão longe seu software atual está desses objetivos. Torne-o o mais detalhado possível.
- Defina um caminho claro que o leve de onde você está até onde deseja estar. É mesmo possível? Talvez haja incompatibilidades com novas tecnologias ou não haja caminhos para transformar software desatualizado em hardware moderno.
- Divida os dois processos seguindo esse caminho. O que está envolvido na refatoração do código? E quais são os incluídos em uma reescrita? Esta é uma parte fundamental da avaliação, por isso não tente expressar o processo em quanto tempo você acha que ambos os processos levarão. Em vez disso, tente pensar nas tarefas e em suas complexidades, pois isso permitirá comparar melhor as duas opções.
- Compare os caminhos à sua frente. Talvez você perceba que, embora a refatoração possa exigir mais etapas, essas etapas são mais fáceis do que as menos incluídas na reescrita. Ou talvez fique claro que a refatoração é um esforço intransponível devido às muitas tarefas que implica.
- Com uma visão mais clara de ambos os caminhos, reavalie os motivadores do seu negócio e os seus riscos. Depois de levar em conta todas essas considerações, você estará mais bem preparado para tomar uma decisão final.
O debate refatorar versus reescrever é estéril quando se trata de operações diárias, pois muitas vezes se desvia para o terreno teórico. Como não existem dois projetos iguais, é vital repassar essas etapas práticas para melhor abordar o assunto e definir se uma estrada é melhor.
Uma recomendação final da minha parte. Mesmo que você perceba que uma abordagem apresenta melhores resultados para seus projetos, resista à tentação de optar por essa opção como padrão, pois você pode se deparar com um projeto específico que pode se beneficiar da outra abordagem. Pode parecer cansativo fazer essa análise toda vez que você trabalha com código antigo, mas garanto que é a única maneira de obter os melhores resultados para seus projetos.
Fonte: BairesDev
