Modernize o legado sem parar o negócio

Há uma frase que ouvi em quase todas as empresas que encontrei com um produto maduro em mãos: “isso é tão ruim que é melhor reescrevê-lo completamente”.

Eu também disse isso. Com total convicção. Olhando para um código que ninguém ousava mexer, com dependências que pareciam ser mantidas pela fé e uma documentação que consistia em perguntar à única pessoa que estava ali há sete anos.

Quando ingressei como CTO na Enterticket, encontrei exatamente esse cenário: um produto legado que funcionava — faturado, tinha clientes reais, operações sustentadas todos os dias — mas que levou um mundo para evoluir. E, como era de se esperar, numa das primeiras reuniões alguém colocou em cima da mesa a opção nuclear: começar do zero.

Não demorei muito para perceber que essa era, quase sempre, a pior decisão que poderíamos tomar.

A grande armadilha da reescrita

A Grande Reescrita é a armadilha favorita do ego técnico. E digo isso sem condescendência, porque caí nisso.

É sedutor por vários motivos. É mais divertido construir algo novo do que compreender algo antigo. Dá a sensação de controle: “desta vez vamos fazer certo”. E permite que você não enfrente a parte desconfortável da engenharia, que é conviver com as decisões – boas e ruins – que outros tomaram antes de você.

O problema é que reescrever do zero um sistema que está em produção é apostar o negócio em um único cartão. Enquanto você constrói o substituto, o mundo não para: o sistema antigo ainda está vivo, ainda precisa de patches e sua concorrência continua lançando novos recursos que você não consegue igualar porque toda a sua equipe está ocupada reconstruindo o que você já tinha.

Dezoito meses depois – se você chegar lá – você lança um produto que, na melhor das hipóteses, faz a mesma coisa que o anterior. Zero novo valor para o cliente durante todo esse tempo. E isso presumindo que o projeto termine, o que muitas vezes não acontece.

O que você realmente perde quando reescreve

Acima do risco de prazo, há três coisas que são perdidas e que quase nunca aparecem na estimativa inicial.

As regras de negócios que ficam escondidas no código. Aquele estranho que parece um erro é, quase sempre, a cicatriz de um caso real: um cliente importante, uma exceção legal, um bug que custou dinheiro. Quando você reescreve, essas regras não estão em nenhum documento. Eles estão no código que você vai jogar fora. E você os redescobre um por um, na produção, geralmente quando quebram.

O impulso. Uma equipe que fica mais de um ano sem entregar valor visível se desgasta. A gerência fica impaciente, os vendedores não têm nada de novo para contar e o moral da equipe diminui. A energia de construir algo novo dura três meses; a reescrita dura muito mais tempo.

Dinheiro, o que não é detalhe. Cada mês de reescrita é um custo sem retorno. Não estamos a reduzir a dívida técnica de forma incremental: estamos a financiar uma promessa.

A alternativa: modernização evolutiva

A boa notícia é que existe um caminho que não obriga você a escolher entre “suportar o legado para sempre” e “queimar tudo”. Chama-se modernização evolutiva, e a ideia é tão antiga quanto sensata: mudar o sistema pouco a pouco, enquanto ele continua a funcionar.

O padrão clássico para isso é o Strangler Fig. O nome vem de uma árvore que cresce em torno de outra até substituí-la completamente, sem nunca deixar uma lacuna onde antes havia uma árvore. Aplicado ao software: você cerca o sistema antigo, move uma capacidade de cada vez para o novo e desliga a parte antiga somente quando a nova já a cobre completamente.

Para que isto funcione sem contaminar o novo com os vícios do antigo, uma camada anticorrupção ajuda: uma fronteira que se traduz entre os dois mundos e evita que modelos de dados legados vazem para o sistema moderno. É a diferença entre construir próximo ao legado e construir dentro dele.

A verdadeira vantagem? Você agrega valor desde a primeira semana, distribui o risco por dezenas de pequenos passos em vez de concentrá-lo em um único big bang e preserva o conhecimento do negócio à medida que o transfere, em vez de perdê-lo tudo de uma vez.

Como abordar isso na prática

A ordem é mais importante do que a velocidade. Isso é o que funcionou para mim.

1. Meça o que realmente dói. Não reescreva o que funciona só porque é feio. Identifique quais partes do sistema concentram bugs, atrasos e reclamações. Aí está o seu retorno; o resto pode esperar anos sem problemas.
2. Isole-se antes de jogar. Estabeleça uma fronteira clara entre o antigo e o novo. Uma camada anticorrupção, uma API estável, tanto faz. Você precisa ser capaz de mudar uma peça sem que todo o edifício trema.
3. Comece com muita dor e poucos riscos.A primeira migração deve ser um sucesso visível. Escolha algo que seja importante para o negócio, mas que, se der errado, não destruirá a operação. Essa primeira vitória lhe dá confiança para tempos difíceis.
4. Ele desliga o antigo apenas quando o novo o cobre.O legado não é apagado no dia em que você lança o substituto. Ele é apagado no dia em que você está em produção há semanas sem incidentes e ninguém sente falta dele. Manter as duas versões por algum tempo não é indecisão: é prudência.

E quando faz sentido reescrever?

Seria desonesto convencer você de que reescrever nunca é a resposta. Às vezes é.

Quando a tecnologia básica está realmente morta – sem suporte, sem pessoas que a conheçam, sem caminho de atualização – a correção é um desperdício de dinheiro. Quando o domínio empresarial mudou tanto que o modelo original já não representa a realidade, arrastá-lo custa mais do que refazê-lo. E quando o sistema é pequeno e limitado, a reescrita pode ser uma questão de semanas, não de anos: aí o risco é aceitável.

A chave é que esta decisão seja uma conclusão fundamentada baseada em custos e riscos, e não um impulso nascido da frustração de ler o código de outras pessoas. Reescrever porque os números justificam é estratégia. Reescrever porque “tem preguiça de entender” é ego com orçamento.

A questão que realmente importa

Depois de quinze anos fazendo isso, cheguei a uma conclusão simples: a arquitetura serve ao negócio, e não o contrário.

Modernizar não significa buscar elegância técnica ou ter uma pilha bacana este ano. Consiste em reduzir o custo de mudar o amanhã sem deixar de entregar hoje. Se uma modernização não torna sua equipe mais rápida e seu produto mais fácil de evoluir, não é modernização: é redecoração.

Essa é, aliás, uma das coisas que mais valorizo quando acompanho equipas na Venturest: a decisão certa quase nunca é a mais espectacular. É o que mantém o negócio funcionando e ao mesmo tempo o torna mais capaz internamente. Sem lock-in, sem parar a entrega e deixando a equipe mais forte que antes.

Então, antes de você aprovar aquele plano de “vamos reescrever tudo”, vale a pena se fazer apenas uma pergunta:

Sua equipe está se modernizando... ou reescrevendo e orando?