Modernizar software legado sem uma reescrita total

Quase todas as empresas estabelecidas têm um: um software que toda a gente detesta em silêncio. É lento, é feio, metade da equipa conhece um truque para o erro que ninguém chegou a corrigir, e a única pessoa que o entendia saiu em 2019. O instinto é sempre o mesmo — deitar tudo abaixo e construir um novo. E esse instinto, mais vezes do que se imagina, é precisamente a forma como boas empresas perdem um ano e uma pequena fortuna para nada.

Já vi a grande reescrita correr mal vezes suficientes para ter um reflexo quanto a isso. Um fundador mostra-me o seu rangente sistema de encomendas ou a sua antiquíssima ferramenta de planeamento, suspira e diz alguma versão de «só precisamos de substituir tudo». E talvez um dia o faça. Mas a reescrita completa — arrancar o sistema antigo, construir um novo e reluzente em paralelo, carregar num interruptor — é uma das jogadas mais arriscadas de todo o software. É cara, demora muito mais do que o prometido e, durante todo esse tempo, anda às cegas, na esperança de que o novo cubra cada caso estranho que o antigo tratava em silêncio há quinze anos.

A boa notícia é que a reescrita total quase nunca é a única opção, e raramente a melhor. Há uma forma mais serena de modernizar — gradual, reversível e respeitadora do negócio que ainda tem de ganhar dinheiro enquanto trabalha. Este é um guia desse caminho: como perceber o que precisa mesmo de correção, como substituir as partes dolorosas sem deitar abaixo o sistema inteiro, e como saber quando uma reescrita completa é, de facto, a decisão certa.

Porque é que a reescrita total é tão tentadora — e tão perigosa

A reescrita completa é sedutora porque promete uma folha em branco. Acaba-se a confusão legada, acabam-se os compromissos, uma base de código nova construída como deve ser com ferramentas modernas. Num quadro branco parece óbvio. Na realidade, está a comprometer-se a reconstruir anos de lógica de negócio acumulada — muita dela não documentada, alguma a viver apenas na cabeça de pessoas que já saíram — enquanto o relógio anda e as faturas chegam.

A armadilha mais profunda é o problema do universo paralelo. Durante os meses ou anos que demora a construir o substituto, tem dois sistemas: o antigo, que ainda tem de sustentar o negócio, e o novo, que ainda não está pronto. Cada alteração de que o negócio precisa tem de ser feita duas vezes, senão o sistema novo fica atrás da realidade antes mesmo de arrancar. As equipas esgotam-se a manter ambos vivos. E como ninguém pode mudar enquanto o sistema novo não fizer tudo, não há vitória precoce, nem retorno, nem prova de que funciona — apenas uma longa e ansiosa espera por um único e enorme dia de lançamento, tudo ou nada.

Há aqui um ditado bem conhecido do setor, e é merecido: o segundo sistema, a grande reescrita, costuma demorar o triplo do estimado e chegar com menos funcionalidades do que aquilo que substitui. A estimativa não está errada por descuido. Está errada porque, no início, ninguém consegue ver todas as pequenas coisas que o sistema antigo faz bem sem dizer nada.

O que 'legado' significa de verdade (não é uma questão de idade)

Atiramos a palavra legado como se quisesse dizer apenas velho. Não quer. Imenso software a funcionar há uma década está perfeitamente bem — aborrecido, estável, já pago, a fazer o seu trabalho. A idade por si só não é razão para tocar fosse no que fosse. O erro mais caro de toda esta área é modernizar algo que funcionava em silêncio só porque parecia datado.

O software ganha o rótulo de legado quando começa a atrapalhá-lo ativamente. Quando não o pode alterar em segurança porque ninguém o entende por completo. Quando não consegue ligar-se às ferramentas de que hoje depende. Quando uma só pessoa é a única capaz de o manter vivo. Quando é tão lento ou frágil que a sua equipa construiu todo um folclore de truques à sua volta. Essa é a verdadeira definição — não o ano em que foi escrito, mas o custo que lhe impõe hoje e o risco que carrega para amanhã.

Diagnostique antes de tocar fosse no que for

Antes de uma única linha ser reescrita, precisa de um mapa honesto de onde a dor realmente vive. Na maioria das vezes, o sistema que toda a gente odeia está 80% bem. O problema concentra-se em poucos pontos específicos — um ecrã lento, uma integração partida, um fluxo que obriga à dupla introdução de dados — e esses poucos pontos geram quase todas as queixas. Encontre-os e terá encontrado o seu projeto inteiro.

A forma de os encontrar não é primeiro uma auditoria técnica — é uma conversa. Sente-se com as pessoas que usam a ferramenta todos os dias e pergunte onde dói. Onde esperam? O que voltam a digitar? O que evitam por ser doloroso? Onde mantêm uma folha de cálculo privada para contornar o sistema oficial? Esses truques são ouro: cada um é uma radiografia precisa de um problema que vale a pena corrigir.

• Os ecrãs e os passos de que as pessoas mais se queixam — não em teoria, no seu trabalho diário real.
• Cada ponto onde os dados são digitados duas vezes porque dois sistemas não falam um com o outro.
• As integrações que partiram, ou que nunca existiram, obrigando ao copiar-colar manual entre ferramentas.
• Tudo o que só uma pessoa sabe operar ou reparar — os seus pontos únicos de falha.
• As partes que estão genuinamente bem, para as proteger e deixar em paz.
• Aquilo de que o negócio precisará no próximo ano e para o qual o sistema atual simplesmente não consegue crescer.

Quando faz isto com honestidade, o projeto costuma encolher. O dono que entrou a dizer «substituam tudo» sai a perceber que precisa de corrigir três coisas. Isso não é uma deceção — é um alívio. Três coisas corrigíveis são um projeto que pode terminar este trimestre. Uma substituição completa é um ano a que talvez não sobreviva.

A abordagem strangler: substitua-o peça a peça

Há um padrão para fazer isto em segurança, e tem um nome um pouco sombrio mas memorável: a abordagem strangler, da figueira-estranguladora — uma trepadeira que cresce à volta de uma árvore e vai assumindo gradualmente a sua estrutura até que, por fim, o novo crescimento se sustenta sozinho e o velho tronco desaparece. Aplicada ao software, a ideia é lindamente prática: não substitui o sistema antigo numa única troca heroica. Faz o novo crescer à volta dele, peça a peça, até não restar nada do antigo de que alguém precise.

Na prática funciona assim. Escolhe uma peça dolorosa — digamos o módulo de faturação que toda a gente odeia. Constrói um substituto moderno para apenas essa peça. Encaminha a faturação para o novo módulo enquanto tudo o resto continua a correr no sistema antigo, intacto. Observa-o por algum tempo. Quando está sólido, essa parte do sistema antigo cala-se e passa à peça seguinte. O sistema antigo encolhe gradualmente, como uma vela, em vez de ser deitado abaixo de uma só vez.

O que torna isto muito mais seguro do que uma reescrita é que cada passo é pequeno, em produção e reversível. Nunca anda às cegas. Cada nova peça entra rapidamente em uso real, por isso descobre depressa se funciona mesmo. Se algo correr mal, só arriscou um módulo, não o negócio inteiro — e normalmente pode voltar ao caminho antigo enquanto o corrige. Colhe vitórias pelo caminho em vez de um único lançamento aterrador no fim. E o negócio continua a funcionar, normalmente, todo o tempo.

Como é, na verdade, o ritmo

1. 1
   Escolha a peça mais dolorosa e mais autónoma

   Quer muita dor e arestas limpas — um módulo que doa bastante e que não tenha os dedos metidos em tudo o resto. Esse é o seu primeiro alvo.
2. 2
   Coloque uma camada fina à frente do sistema antigo

   Uma pequena camada de encaminhamento decide que pedidos vão para o sistema antigo e quais vão para a nova peça. É a costura que torna tudo o resto possível.
3. 3
   Construa e lance apenas essa única peça

   Substitua um módulo, ponha-o em mãos reais e encaminhe apenas essa fatia de trabalho para ele. Semanas, não anos — e o resto do sistema nunca se mexeu.
4. 4
   Estabilize e depois passe à peça seguinte

   Assim que o novo módulo é de confiança, a parte correspondente do sistema antigo fica em repouso. Repita com a peça dolorosa seguinte, aprendendo à medida que avança.
5. 5
   Desative o sistema antigo quando estiver vazio

   Com o tempo, o sistema legado não faz nada de que alguém dependa. Só então o desliga — em silêncio, sem drama, porque tudo o que importa já se mudou.

Repare no que distingue isto da reescrita: não há um único dia de lançamento a temer. Não há um universo paralelo a manter. O sistema novo está em produção desde a terceira semana, a ganhar o seu sustento e a ensinar-lhe coisas, em vez de esperar num laboratório por um lançamento que não para de escorregar.

Às vezes nem sequer precisa de o substituir

Antes de substituir fosse o que for, vale a pena perguntar se o sistema antigo precisa de ser substituído ou apenas de deixar de ser uma ilha. Um número surpreendente de problemas de «precisamos de um sistema novo» são, na verdade, problemas de «os nossos sistemas não falam uns com os outros». O software antigo faz bem o seu trabalho — está apenas num silo, obrigando as pessoas a transportar dados à mão de um lado para o outro.

Nesses casos, a solução mais barata e rápida não é um sistema novo. É uma ponte. Envolve o software antigo com uma ligação — uma integração que lhe permite trocar dados automaticamente com as suas outras ferramentas — e uma camada moderna por cima para as partes que as pessoas realmente tocam. O motor datado continua a trabalhar por baixo; a equipa ganha uma superfície limpa e o fim do copiar-colar. Não é glamoroso, mas é muitas vezes o maior retorno por euro de todo o esforço.

Quando uma reescrita completa é mesmo a decisão certa

Passei este guia inteiro a dissuadi-lo da grande reescrita, por isso sejamos justos: às vezes é mesmo a resposta. Há fundações tão podres que nenhum remendo, ponte ou substituição peça a peça as salva, e fingir o contrário apenas adia o inevitável enquanto gasta dinheiro a escorar um cadáver.

Os sinais honestos são específicos. A tecnologia em que o sistema assenta está morta ou a morrer — sem suporte, sem atualizações de segurança, ninguém que reste capaz de lhe pôr as mãos. O negócio mudou de forma tão profunda que o modelo antigo já não corresponde de todo à realidade. Ou o sistema está tão emaranhado que até pequenas alterações partem rotineiramente coisas em locais não relacionados, o que normalmente significa que não há costuras limpas para aplicar a abordagem strangler à partida. Quando duas ou três destas coisas são verdade ao mesmo tempo, o trabalho gradual deixa de ser a escolha mais segura.

E aqui está a recompensa silenciosa de fazer primeiro o trabalho gradual, mesmo que acabe por reconstruir: quando lá chegar, vai entender o sistema muito melhor do que entendia no início. Cada módulo que substituiu ensinou-lhe algo que os autores originais nunca puseram no papel. Uma reescrita iluminada por esse conhecimento é um animal completamente diferente, muito mais seguro, do que a que é lançada no otimismo do primeiro dia.

A parte que ninguém menciona: é sobretudo uma questão de pessoas

Aqui vai algo que os guias técnicos saltam. A parte mais difícil de modernizar software antigo não costuma ser o código — são as pessoas que passaram anos a adaptar-se a ele. Conhecem as suas manias. Têm memória muscular dos seus atalhos esquisitos. Um novo módulo objetivamente melhor pode, ainda assim, parecer pior durante as primeiras duas semanas, simplesmente por ser desconhecido. Se ignorar isto, até uma migração técnica perfeita pode falhar.

A abordagem gradual também ajuda aqui, quase por acaso. Como a mudança chega numa pequena peça de cada vez, as pessoas absorvem-na aos poucos em vez de terem de reaprender tudo numa única segunda-feira de manhã. Envolva cedo os utilizadores do dia a dia. Deixe-os moldar o substituto antes de estar terminado. A equipa que ajudou a desenhar o novo ecrã de faturação defendê-lo-á; a equipa a quem ele foi imposto há de rejeitá-lo, mesmo que idêntico. A modernização é um projeto de gestão da mudança disfarçado de software.

Perguntas frequentes