Por que quase nunca aprovo reescrever um sistema do zero

Um cliente de logística me ligou decidido a jogar três anos de produto no lixo e recomeçar. Passei a call inteira tentando impedir. Reescrever do zero é a decisão que mais parece coragem e mais costuma sair caro, e quase sempre existe um caminho mais chato que entrega melhor.

Numa terça de abril o fundador de uma logtech me ligou já decidido. Três anos de produto, cinco pessoas no time, e a frase que eu escuto umas duas vezes por mês: "a base tá podre, vamos reescrever tudo do zero e fazer direito dessa vez". Ele queria que a Revin tocasse esse rewrite. Passei os quarenta minutos seguintes da ligação tentando convencê-lo a não fazer.

Não porque a base fosse boa. Era ruim mesmo, eu já tinha dado uma olhada antes da call. O ponto é outro: reescrever do zero quase sempre é a decisão mais cara que um founder aprova no ano, disfarçada de coragem. Já vi esse filme vezes suficientes pra ter medo dele.

Se você tem um fornecedor, um dev ou a sua própria cabeça sugerindo apagar tudo e começar de novo, este texto é sobre a conta que ninguém coloca no slide do rewrite.

A vontade de recomeçar não é burrice

Vou ser justo com quem quer reescrever. Ler código que outra pessoa escreveu com pressa é uma das tarefas mais ingratas da engenharia. Você abre um arquivo de mil linhas, não tem teste nenhum, os nomes das variáveis mentem, e cada vez que puxa um fio três outros se mexem. Diante disso, a tela em branco parece um descanso. Recomeçar é a fantasia de todo dev que herdou uma bagunça, e eu entendo a fantasia porque também já tive.

O problema é quem lucra com ela. Quando um fornecedor te propõe um rewrite completo, ele está te vendendo seis, oito, doze meses de trabalho novo em que não precisa entender quase nada do que já existe. É confortável pra ele e caro pra você: ele troca a parte difícil, que é ler e consertar o que está de pé, por uma parte divertida que você financia. Foi por isso que, quando a logtech me procurou, meu primeiro trabalho foi tentar impedir a venda mais fácil que eu poderia ter fechado.

A tela em branco de um projeto novo parece um alívio. É também onde a conta começa a subir.

A conta que some do slide

O rewrite chega ao founder como um número só: quanto custa construir o novo. Some do slide o resto da conta, que costuma ser maior. Enquanto o time novo escreve, o sistema velho continua de pé, atendendo cliente, quebrando, cobrando manutenção. Você paga dois produtos ao mesmo tempo, um que morre devagar e outro que ainda não nasceu.

Tem também o imposto que ninguém avisa: você vai reintroduzir bugs que já tinha resolvido. Aquele if estranho no meio do checkout que ninguém entende costuma estar ali porque um cliente real quebrou de um jeito específico em 2023. O rewrite apaga essa cicatriz sem saber que ela existia, e você reabre a ferida meses depois, redescobrindo na marra por que o código velho era feio.

Um cliente meu de 2023, um marketplace de autopeças com uns quarenta mil SKUs, gastou sete meses e por volta de R$ 380 mil num rewrite que nunca chegou a substituir o sistema antigo. Os dois rodaram em paralelo até o caixa apertar. Quando pararam, tinham migrado umas 40% das telas e um time inteiro exausto. Voltaram pro sistema velho, agora com metade da equipe pra mantê-lo.

De cada dez founders que me procuram querendo reescrever, uns oito não precisavam. Sei que o número é enviesado: quem reescreveu e deu certo não me liga pra contar, então minha amostra é feita de quem se deu mal. Mas mesmo cortando pela metade, ainda é gente demais gastando à toa por uma decisão que parecia óbvia numa noite ruim.

Três perguntas antes de reescrever a primeira linha

Antes de aprovar qualquer coisa, eu faço o founder responder três perguntas em voz alta. Não são sofisticadas. Servem só pra separar o rewrite que é necessidade do rewrite que é cansaço.

• É arquitetura ou é bagunça? Bagunça se refatora sem jogar nada fora. Arquitetura errada de verdade (o banco que não aguenta o modelo do negócio, a escolha de stack que trava o produto) é rara, e é o único caso em que reescrever grande costuma se pagar.
• Dá pra congelar features por seis meses? Um rewrite honesto significa parar de evoluir o produto enquanto ele é reconstruído. Se o negócio não sobrevive a esse congelamento, o rewrite já nasce perdendo pro concorrente que continuou entregando.
• Alguém ainda entende o sistema atual? Se o conhecimento saiu junto com o fornecedor antigo, você não vai reescrever o produto: vai reescrever os mesmos erros no escuro, sem nem saber quais eram.

Se a resposta de qualquer uma das três for desconfortável, o rewrite provavelmente vai doer mais do que a base que você quer jogar fora.

Prédio histórico restaurado com o andaime por fora e a vida seguindo por dentro. É assim que uma base velha melhora sem fechar as portas.

O caminho chato que quase sempre ganha

Existe uma alternativa que ninguém coloca em slide porque é sem graça: melhorar o que está de pé, um pedaço de cada vez, com o produto no ar o tempo todo. No jargão chama-se strangler fig. Você planta o novo em volta do velho e vai estrangulando módulo por módulo até o antigo sumir sozinho. Não tem grande dia de virada nem foto bonita. Tem release toda semana.

Foi o que a gente acabou fazendo com a logtech. Nada de começar do zero. As duas primeiras semanas foram só leitura: mapear o que existia, escrever teste em cima do comportamento atual pra travar o que já funcionava, e achar o módulo mais podre. Era o de roteirização. Reescrevemos ele por trás de uma interface estável, o resto do sistema nem percebeu a troca, e seguimos pro próximo. Uns seis meses depois, boa parte do código crítico era novo e o produto não ficou um único dia fora do ar. É esse tipo de decisão que a gente destrincha logo no diagnóstico.

Reescrever atrás de interface não é mais lento que um big bang. Costuma ser mais rápido, porque cada semana entrega algo que você testa com usuário de verdade, em vez de apostar seis meses numa virada única que pode nem subir. A parte chata é justamente a que protege o seu caixa.

De volta àquela ligação de terça

O fundador da logtech não reescreveu. A gente estrangulou o pior primeiro, ele continuou vendendo o produto durante a obra, e o rewrite dos sonhos que ele tinha orçado com outro fornecedor, quase um ano parado, nunca precisou existir. Ele me disse depois que a decisão mais lucrativa daquele ano foi a de não fazer nada de heroico.

Se tem alguém agora te empurrando um recomeço do zero, desconfie de quem ganha com o botão de apagar. Antes de assinar, vale meia hora olhando a sua base com quem lê código pra viver, que é onde essa conversa costuma começar.