Refatorar, reescrever ou substituir?

Refatoração, reescrita e substituição podem aparecer na mesma rubrica orçamental, mas compram resultados diferentes. Refatorar compra mudanças mais seguras dentro do sistema atual. Reescrever compra uma nova implementação da mesma responsabilidade de negócio. Substituir compra outro produto e, quer o patrocinador admita ou não, outra forma de trabalhar.

As equipas desperdiçam um ano quando aprovam um resultado e financiam outro. Chamam uma reescrita de refatoração para ela parecer mais segura e depois descobrem que todo comportamento precisa ser redescoberto. Chamam a implantação de um pacote de substituição e orçam apenas licenças e configuração, tratando mudança de processos, migração e integração como detalhes. Ou anunciam uma reescrita quando a restrição real está em contratos, responsabilidade pelos dados ou num mainframe anterior que ninguém pretende tocar.

A escolha não é uma escada de maturidade. Substituir não é automaticamente mais ousado que refatorar, e reescrever não é o meio-termo limpo. Cada opção tem condições em que é económica. A pergunta útil é quais obrigações devem ficar iguais, quais podem mudar e quais devem desaparecer. Quando essas respostas ficam explícitas, o orçamento deixa de ser uma disputa de preferências.

Refatorar compra capacidade de mudança, não um sistema novo

Refatorar muda a estrutura interna de um software funcional e preserva o seu comportamento observável. A definição de Martin Fowler importa porque as equipas alargam o termo até incluir migrações, redesenho funcional e substituição total. Se utilizadores, sistemas chamadores ou operadores conseguem observar uma mudança planeada, o trabalho não é refatoração, mesmo que os engenheiros melhorem o código à volta.

O orçamento compra unidades menores, dependências mais claras, testes melhores, ferramentas de compilação atuais e entregas mais seguras. Pode separar cálculo de entrada e saída, colocar uma API em torno de uma capacidade estável, remover ramos mortos, revelar acoplamento oculto e preparar uma extração. Não compra liberdade do ambiente de execução, modelo de dados, fronteira de implantação ou decisões históricas do produto sem outro trabalho.

Refatorar é correto quando o sistema ainda faz o trabalho certo, o comportamento em produção é compreendido e a tecnologia suporta o próximo horizonte do negócio. Também serve quando as entregas não podem parar. Os engenheiros melhoram um caminho de cada vez atrás das interfaces existentes, publicam com frequência e podem parar com ganhos úteis. A refatoração deve ter pontos de controlo incrementais. Um projeto de doze meses cujo valor só aparece no fim provavelmente é uma reescrita disfarçada.

O limite difícil é a gravidade arquitetural. Limpar métodos dentro de um monólito não remove um gargalo de entrega causado por uma base partilhada e uma única unidade de implantação. Adicionar interfaces a um ambiente de desktop obsoleto não o torna executável no navegador. Se o objetivo exige outra fronteira de confiança, ambiente de execução ou responsabilidade pelos dados, refatorar prepara o caminho, mas não chega lá sozinho.

Uma estimativa credível nomeia a restrição que vai remover. «Melhorar a manutenção» não pode ser testado. «Separar o cálculo de tarifas da entrada e saída do terminal para o executar num teste automatizado» pode. Financie uma sequência dessas restrições e meça tempo de entrega, isolamento de defeitos ou independência de publicação. Não financie o desejo genérico de ter código agradável.

Uma reescrita compra nova implementação e uma conta de descoberta

Uma reescrita substitui a implementação e mantém a responsabilidade de negócio do sistema. Pode mudar linguagem, arquitetura, base de dados e interface, mas herda a obrigação de preservar todo comportamento ainda necessário. Essa obrigação cria a conta de descoberta, que muitas vezes é maior que a conta visível de programação.

Sistemas antigos contêm várias especificações. O código-fonte diz o que um ramo faz. Os dados revelam os valores aceites na prática. Definições do agendador, JCL, scripts e manuais de operação mostram como o trabalho circula. O tráfego de produção mostra formatos e sequências de pedidos. Os utilizadores lembram exceções ausentes noutros lugares. Nenhuma fonte é completa, e as contradições são normais.

Reescrever é correto quando a responsabilidade do produto continua útil, mas a implementação bloqueia o modelo operacional necessário. As razões incluem um runtime sem suporte, implantação incompatível com a recuperação exigida, uma linguagem para a qual já não se contrata ou uma arquitetura que impede isolar necessidades próprias de escala ou segurança. O caso fica mais forte quando o comportamento pode ser observado e comparado mecanicamente.

O orçamento deve pagar quatro blocos: descoberta do comportamento, nova implementação, migração e prova. Programar é apenas um deles. A conversão precisa tratar valores que violam o esquema nominal. A transição precisa considerar trabalho em curso. A prova deve cobrir saídas, efeitos laterais, pressupostos de tempo e falhas, não apenas ecrãs bem-sucedidos. Se a estimativa conta serviços de destino e pontos, mas não a paridade, omite a parte cara.

Hábitos de projeto novo causam problemas aqui. Uma equipa de produto esclarece uma função com o responsável de produto. Uma equipa de reescrita arbitra entre código, tráfego, registos e prática humana, cada qual sendo autoridade em casos diferentes. Um modelo de destino limpo pode rejeitar um estado feio que fecha as contas corretamente. A equipa não pode apagá-lo por não gostar do desenho. Deve preservar o resultado, retirar a regra com aprovação do negócio ou criar uma conversão que explicite a diferença.

A reescrita merece o orçamento quando remove limites estruturais sem obrigar a empresa a reaprender o próprio negócio. Se os patrocinadores querem fluxos, políticas ou escopo muito diferentes, separe essa mudança da paridade. Juntar ambos torna cada divergência ambígua: defeito, redesenho intencional ou regra legada sem documentação.

Substituir compra um produto e uma mudança de processo

A substituição retira o sistema atual em favor de um produto, serviço ou processo operacional existente. A organização deixa de possuir grande parte da implementação e aceita os conceitos, o ritmo de versões e os limites do substituto. Essa troca pode ser excelente para capacidades comuns, mas configurar um produto não o transforma no sistema substituído.

O orçamento compra licença ou subscrição, configuração, migração de dados, integração, identidade, controlos, formação e mudança organizacional. Também pode comprar serviços do fornecedor. Não compra a semântica exata do sistema antigo, a menos que o produto já a ofereça. Personalizar um pacote até reproduzir toda exceção histórica recria o legado numa plataforma sobre a qual a organização tem menos controlo.

Substituir é correto quando a capacidade não distingue o negócio, o produto cobre o trabalho sem personalização profunda e a organização pode adotar o processo. Folha de pagamento, tickets ou documentos podem servir, dependendo das obrigações locais. Um motor próprio de preços, modelo de alocação ou sequência de controlo industrial pede mais ceticismo, pois as regras estranhas podem codificar o negócio, não um acidente histórico.

O custo decisivo está nas lacunas, não na contagem de funcionalidades. Um concurso pode mostrar que o produto tem aprovações, exportações e controlo de papéis. Diz pouco sobre uma aprovação cobrir um lote misto, uma correção manter a data contabilística ou uma exportação chegar antes de um limite posterior. Essas pequenas semânticas produzem alternativas caras depois da escolha.

Substituir também transfere poder sobre o roteiro. O fornecedor pode descontinuar uma interface, mudar um limite ou agrupar de outra forma uma função necessária. Os contratos distribuem parte do risco, mas não devolvem controlo técnico. Orce uma saída, exportações duráveis e adaptadores em torno de integrações quando fizer sentido. Se sair do produto exige reconstruir a empresa sob pressão, a compra criou uma dependência estratégica que deve ser avaliada como tal.

Os três orçamentos usam moedas diferentes

Os orçamentos diferem porque cada opção consome um recurso escasso diferente. Refatorar gasta atenção de engenharia enquanto preserva a continuidade operacional. Reescrever gasta capacidade de descoberta e verificação para preservar o comportamento noutra implementação. Substituir gasta a disposição da organização para mudar comportamentos e aceitar limites externos. Comparar apenas estimativas de entrega esconde o recurso que acabará primeiro.

Numa refatoração, o comportamento do produto e a fronteira operacional ficam estáveis. O acoplamento oculto gera incerteza, as equipas omitem pontos de teste e trabalho de entrega, e progresso significa que uma restrição nomeada desapareceu em produção.

Numa reescrita, a responsabilidade de negócio e comportamentos escolhidos ficam estáveis. A semântica não documentada gera incerteza, as equipas omitem descoberta, conversão e prova de paridade, e progresso significa que casos gravados produzem resultados aceites nos dois sistemas.

Numa substituição, o resultado de negócio exigido fica estável e a prática local pode mudar. A adequação do produto gera incerteza, as equipas omitem mudança de processo, integração e saída, e progresso significa que utilizadores concluem casos reais sem exceções personalizadas.

Por isso, comparar custo por ponto de função é fraco. A reescrita pode produzir menos linhas e exigir muito mais decisões. A substituição pode instalar rapidamente e consumir centenas de horas de finanças, operações e conformidade. A refatoração parece lenta por entregar peças pequenas, mas pode reduzir cedo o risco de incidentes e versões. O dinheiro conta, porém o tempo de decisão e o acesso a especialistas costumam definir o calendário.

Considere interrupções. A mesma operadora experiente pode ser necessária para explicar regras, validar dados convertidos e manter o serviço atual. Uma estimativa que a aloca a tempo inteiro conta trabalho fictício. Mostre a procura por função e período. Um plano tecnicamente possível pode falhar porque exige a mesma pessoa indisponível em três frentes.

Trate a contingência conforme a opção. Na refatoração, ela segue o acoplamento e a fraqueza dos testes. Na reescrita, segue diversidade de comportamentos, qualidade dos dados e estado da transição. Na substituição, segue lacunas, limites do fornecedor e adoção. Uma percentagem uniforme deixa a folha arrumada e a decisão menos honesta.

Mapeie obrigações antes de estimar soluções

Um mapa de obrigações separa o que o sistema faz por acaso do que a organização deve continuar a fazer. Construa-o antes de pedir estimativas a equipas ou fornecedores. Caso contrário, cada parte escolhe silenciosamente outro escopo, e a proposta mais barata costuma conter a maior omissão.

Use provas, não adjetivos. Para cada obrigação, registe ator, gatilho, entradas aceites, saída ou efeito, limite temporal, regra de falha, fonte de prova e permissão para mudar. Uma linha pode exigir que uma correção antes do fecho regional mantenha a data de negócio original, comprovada no histórico do agendador e no livro contabilístico. Outra pode permitir retirar um relatório impresso depois que o único utilizador aceite uma exportação.

Um artefacto compacto pode ser assim:

ID: BILL-042
Actor: billing supervisor
Trigger: corrected usage batch accepted before 18:00 local cutoff
Required outcome: invoice keeps original service period; adjustment posts today
Failure behavior: reject the whole batch and preserve prior balances
Evidence: production request pair + ledger rows + operator runbook section 6
Change permission: outcome fixed; screen flow may change
Candidate treatment: preserve in rewrite, configure-and-test in replacement
Owner: revenue operations

Este registo faz mais do que um requisito chamado «suportar correções de faturação». Dá um caso de paridade à equipa de reescrita, uma pergunta precisa ao fornecedor e uma fronteira a proteger à equipa de refatoração. Também expõe divergências cedo. Se finanças e operações pedem comportamentos de falha diferentes, nenhuma tecnologia resolve o conflito.

Classifique cada obrigação como fixa, negociável ou retirada. Fixa significa que o resultado deve sobreviver, não cada ecrã ou tabela. Negociável significa que um responsável nomeado aceita outro processo. Retirada significa que alguém autorizado aprovou a remoção e identificou efeitos posteriores. «Ninguém mencionou» não significa retirada.

Amostre casos difíceis, não médios. Inclua reversões, ficheiros tardios, falhas parciais, pedidos duplicados, mudanças de horário, períodos reabertos e registos anteriores ao esquema atual. O caso comum demonstra que o produto funciona. O caso incómodo revela se encaixa.

Regras de decisão vencem o teatro de pontuações

Escolha primeiro com regras de eliminação e compare depois as opções sobreviventes. Matrizes ponderadas criam falsa precisão: as partes ajustam pesos até vencer a favorita, enquanto uma condição fatal recebe uma média respeitável. Uma restrição rígida deve desqualificar a opção, não tirar sete pontos.

Use estas barreiras:

1. Se o comportamento necessário deve mudar de forma material, a refatoração pura não cobre o programa.
2. Se o comportamento local exato deve permanecer e nenhum produto o suporta sem personalização profunda, a substituição falha na adequação.
3. Se o ambiente atual serve o horizonte e a mudança interna é a principal restrição, a reescrita ainda não justificou o risco.
4. Se o comportamento de produção não pode ser observado, gravado ou reconstruído, uma reescrita de uma vez não tem referência defensável.
5. Se a organização não adota o processo do produto, a compra apenas adia a discussão.

Depois compare custo total, interrupção, reversibilidade, tempo até à primeira redução de risco e provas disponíveis na transição. Mantenha intervalos visíveis. Uma proposta estreita apesar da qualidade desconhecida dos dados não é mais disciplinada, esconde incerteza. Pergunte que descoberta reduziria o intervalo e financie-a antes do programa completo.

Uma prova curta e paga pode testar a premissa mais arriscada. Para refatorar, isole uma dependência e publique pela nova fronteira. Para reescrever, repita uma amostra de comportamento nos dois sistemas. Para substituir, configure dois casos difíceis de ponta a ponta com extensões padrão e exporte os registos. Não escolha uma demonstração fácil. A prova deve poder matar a proposta com pouco custo.

O registo de decisão deve explicar por que as opções rejeitadas falharam. Caso contrário, novos líderes reabrem o debate seis meses depois com menos contexto. Registe obrigações testadas, provas vistas, pressupostos abertos e o evento que exige reconsideração. Isso protege a decisão sem fingir que ela nunca mudará.

A escolha errada falha de formas reconhecíveis

Uma refatoração mal rotulada falha pela expansão do escopo. A equipa começa por limpar dependências e descobre que os patrocinadores esperam nova interface, novo modelo de dados e regras de aprovação diferentes. Os engenheiros não conseguem preservar e redesenhar ao mesmo tempo sem arbitragem. As entregas abrandam, adaptadores temporários multiplicam-se e a liderança culpa a refatoração quando o projeto deixou de o ser meses antes.

Uma reescrita falha quando o novo sistema é julgado por requisitos escritos e a produção pelo comportamento acumulado. Testes passam, demonstrações parecem limpas e a transição revela regras de ordem, arredondamento ou recuperação ausentes. A equipa mantém ambos os sistemas enquanto investiga. Cada correção muda o alvo e enfraquece testes anteriores. O ano desaparece numa cauda crescente de exceções.

Uma substituição falha quando a seleção premia largura funcional e adia a adequação. O produto ganha porque representa todos os substantivos do concurso. Na implantação, os utilizadores descobrem que os verbos acontecem noutra ordem. O integrador adiciona scripts, campos próprios e filas manuais. As atualizações viram ensaios, e a complexidade espalha-se entre produto, middleware e folhas de cálculo.

Há uma falha mais discreta: resolver a restrição errada. Uma empresa reescreve um serviço para publicar mais depressa, mas um processo trimestral ainda controla cada implantação. Outra substitui uma aplicação para reduzir suporte, embora dados ruins de entrada causem a maioria. Uma refatoração ataca o código quando ninguém possui as regras de negócio. Ligue o resultado prometido à causa antes de escolher uma intervenção.

Observe a linguagem dos comités. «Igual por igual» costuma esconder comportamento não examinado. «De origem» costuma excluir integração e controlos locais. «Reescrita incremental» pode descrever uma boa migração ou a falta de fronteira final. Peça obrigação, prova e teste de aceitação por trás de cada frase.

Programas híbridos precisam de um contrato dominante

A maioria dos grandes patrimónios usa mais de um tratamento, mas cada capacidade delimitada precisa de um contrato dominante. Refatore partes cujo comportamento e plataforma continuam adequados. Reescreva capacidades distintivas cujos resultados devem sobreviver noutra arquitetura. Substitua funções comuns onde a empresa aceita um processo padrão. A mistura só funciona com fronteiras e responsabilidades explícitas.

Não chame todo o património de «híbrido» para evitar decisões locais. Para cada capacidade, nomeie tratamento, sistema oficial durante a transição, autoridade perante atualizações contraditórias e condição de retirada. Se dois sistemas podem mudar o mesmo cliente ou saldo, a migração criou um problema de consistência distribuída. Um slide com setas não o resolve.

Ordene o trabalho pela informação, não pela conveniência organizacional. Uma pequena refatoração pode expor uma interface estável que torna a reescrita observável. Uma substituição pode precisar de dados de referência limpos antes do teste. Uma reescrita pode produzir eventos que movem um módulo comum. Construir uma nova camada em torno de uma interface prestes a ser retirada transforma código transitório em custo permanente.

O padrão Strangler Fig, nomeado por Martin Fowler, substitui capacidades gradualmente em torno do sistema existente. É útil quando pedidos podem ser encaminhados numa fronteira estável e ambos os comportamentos coexistem. Não é magia para lotes com estado mutável partilhado, transações longas ou efeitos que não podem ser duplicados. Nesses casos, crie a fronteira pela propriedade dos dados ou por uma unidade de transição controlada, em vez de fingir que HTTP resolve a migração.

Dê à maquinaria transitória um teste de expiração. Escritas duplas, filas de reconciliação, esquemas compatíveis e adaptadores temporários precisam de dono e condição de remoção. Senão, o programa celebra o novo sistema e paga duas arquiteturas para sempre. O orçamento deve remover o andaime de migração, não parar quando o primeiro tráfego chega ao destino.

A prova decide se o orçamento comprou algo

Concluir deve significar comportamento demonstrado e sistema operável, não código integrado ou software instalado. Cada opção precisa de prova diferente porque prometeu resultado diferente.

Uma refatoração prova comportamento estável e melhoria da restrição nomeada. Execute a regressão, compare métricas relevantes e demonstre a nova capacidade: teste isolado, entrega independente ou dependência removida. Se o código parece mais limpo e as entregas continuam igualmente arriscadas, o orçamento não comprou o resultado prometido.

Uma reescrita precisa de um arnês de paridade. Envie as mesmas entradas gravadas aos dois sistemas, normalize diferenças permitidas como identificadores e timestamps e compare saídas e efeitos. Classifique divergências como defeito no destino, mudança aceite, defeito na origem a preservar temporariamente ou dados de teste ruins. O rasto de aprovação das diferenças aceites faz parte do artefacto.

A CodeHero usa este modelo em reescritas legadas: a plataforma lê todo o código, produz uma arquitetura moderna em Go, Rust ou TypeScript e verifica o comportamento com tráfego de produção gravado. Isso cabe num orçamento de reescrita porque implementação e prova de paridade são entregues juntas, com projetos entregues em menos de 30 dias.

Uma substituição prova adequação através de trabalho real, incluindo exceções. Os utilizadores concluem casos com permissões, integrações e dados convertidos. As operações devem restaurar o serviço, reconciliar uma troca falhada e extrair registos sem improviso da equipa. Aceitação contratual por ativação de funções prova apenas que interruptores foram ligados.

Defina limites de transição antes de ver os resultados. Decida quais divergências bloqueiam, quem aceita uma diferença, quanto tempo dura a reconciliação e o que provoca retorno. Se os líderes decidem durante um incidente, a pressão do calendário redefine «aceitável» defeito a defeito.

A prova final deve continuar útil depois do lançamento. Mantenha mapa de obrigações, corpus de paridade, regras de conversão, decisões de adequação e testes operacionais sob responsabilidade. Tornam-se a especificação que o sistema antigo nunca teve. Deitá-los fora garante que a próxima mudança começa outra vez com arqueologia.

Financie a incerteza que realmente existe

A escolha correta aparece quando o orçamento corresponde à incerteza. Financie refatoração se confia no propósito e na plataforma, mas não consegue mudar com segurança. Financie reescrita se confia na responsabilidade do negócio, precisa substituir a implementação e consegue provar paridade. Financie substituição se consegue adaptar o processo a um produto existente e aceitar a transferência de controlo.

Não aprove um substantivo de transformação. Aprove obrigações, um tratamento para cada uma, a prova desse tratamento e a restrição removida. Pergunte onde estão financiadas descoberta, migração, verificação, preparação operacional e retirada. Linhas ausentes não viram trabalho grátis, aparecem depois como atraso.

A primeira despesa útil costuma ser um exercício estreito de redução da incerteza: mapear um fluxo difícil, inspecionar dados reais, repetir casos ou configurar a pior pergunta de adequação. O resultado pode matar a opção favorita. É dinheiro bem gasto porque evita um ano de entrega baseado numa premissa falsa antes do primeiro sprint.

O exercício deve produzir provas reutilizáveis. Um teste de produto deixa casos configurados, registos exportados e explicação de todas as extensões. Uma prova de reescrita deixa corpus versionado, regras de normalização e divergências classificadas. Uma prova de refatoração deixa uma interface testada e evidência de produção de que a dependência já não controla a entrega. Uma apresentação que só declara confiança obriga a repetir a descoberta.

Compras deve pedir aos proponentes que orcem as mesmas obrigações sem impor a mesma forma de entrega. Um produto pode cumprir por configuração e processo. A reescrita pode preservar por código e conversão. A refatoração pode proteger ao remover uma dependência. Compare provas e restrições residuais, não ecrãs, serviços ou pessoas.

A governação deve manter decisões no nível certo. Conselho ou comité possui tolerância ao risco, limites de financiamento e permissão para mudar grandes resultados. Responsáveis de domínio aceitam diferenças específicas. Engenheiros decidem implementação dentro desses limites. Se o comité revê cada campo, decisões acumulam-se. Se engenheiros decidem sozinhos a semântica contabilística, o programa corre para uma disputa na transição.

Financie a retirada como um resultado positivo. Um sistema antigo disponível «para consulta» ainda precisa de controlo de acesso, infraestrutura, retenção e conhecimento. Defina consultas históricas, local dos registos, responsável pela última reconciliação e desativação de credenciais, tarefas e interfaces. Uma transformação que lança o destino e não desliga a origem comprou outro sistema.

Um conselho pode aceitar um intervalo se a equipa explicar o que o move. Não deve aceitar uma data precisa baseada em comportamentos sem nome e acesso imaginário a especialistas. Torne a incerteza legível, escolha o orçamento que a remove e exija prova ligada à promessa. Assim, refatoração, reescrita e substituição deixam de ser slogans concorrentes e tornam-se investimentos responsáveis.