Reuso de Codigo: Quando Reaproveitar e Quando

O caso Ariane 5: quando reuso vira desastre

O sistema de referencia inercial (SRI) do Ariane 5 era um modulo reutilizado diretamente do Ariane 4. Naquele foguete, funcionou por anos sem problema nenhum. O codigo era estavel, testado e confiavel. Por que nao reaproveitar?

O problema: o Ariane 5 tinha uma trajetoria de lancamento completamente diferente do Ariane 4. A velocidade horizontal do Ariane 5 era muito maior no inicio do voo. O modulo SRI convertia a velocidade horizontal de float 64 bits pra inteiro de 16 bits. No Ariane 4, o valor nunca passava de 32.767 (limite de int16). No Ariane 5, passava. Overflow. Boom.

O relatorio oficial do acidente foi claro: o erro nao era do codigo. O codigo fazia exatamente o que foi programado pra fazer. O erro era da decisao de reutilizar sem revalidar. A equipe assumiu que 'se funcionou antes, funciona agora' sem verificar se as condicoes mudaram.

E essa e a armadilha do reuso: codigo que funciona perfeitamente num contexto pode ser letal em outro. A qualidade do codigo e irrelevante se as premissas do ambiente mudaram. E premissas mudam o tempo todo — novos volumes de dados, novas regras de negocio, novas integrações, novos padroes de uso.

Framework de decisao: reaproveitar ou reescrever?

Nem todo reuso e ruim. E nem toda reescrita e justificada. O problema e que devs tendem a ir pra extremos: ou copiam tudo sem pensar, ou querem reescrever do zero 'porque o codigo antigo e feio'. Os dois extremos sao caros. Voce precisa de criterios objetivos.

Esse framework nao e perfeito, mas e infinitamente melhor que 'acho que da pra copiar' ou 'acho que precisa reescrever'. Pelo menos forca voce a pensar nas premissas antes de tomar a decisao.

Auditando codigo legado antes de migrar

Voce decidiu que vale a pena reaproveitar o modulo, mas precisa auditar antes. Como fazer isso de forma sistematica, sem gastar 3 meses lendo cada linha?

O ponto 3 e o mais subestimado. Valores hardcoded sao premissas escondidas. Um timeout de 5000ms que funcionava quando o servico ficava na mesma rede pode ser insuficiente quando o servico migra pra outra regiao. Uma constante de MAX_ITEMS = 1000 que fazia sentido quando o sistema tinha 50 usuarios pode virar gargalo com 50 mil.

Dica pratica: faz um grep por numeros magicos (constantes numericas sem nome) e por valores de configuracao hardcoded. Cada um e uma premissa implicita que precisa ser validada no novo contexto.

Migracoes seguras com Strangler Fig

Quando a auditoria mostra que o modulo precisa de mudancas significativas, mas voce nao pode parar tudo pra reescrever, o padrao Strangler Fig e a melhor abordagem. O nome vem da figueira estranguladora — uma planta que cresce em volta de uma arvore existente ate substitui-la completamente.

A ideia e simples: em vez de substituir o sistema legado de uma vez (big bang rewrite), voce cria o sistema novo ao lado do antigo e migra funcionalidade por funcionalidade. O sistema antigo continua rodando enquanto o novo vai assumindo. Quando todo o trafego ja usa o novo, voce desliga o antigo.

Na pratica, o Strangler Fig funciona assim: voce coloca um proxy na frente do sistema legado. Quando constroi uma feature nova, o proxy redireciona o trafego daquela rota pro novo servico. Rotas que ainda nao foram migradas continuam indo pro legado. Com o tempo, todas as rotas apontam pro novo sistema e o legado e desativado.

Netflix usou esse padrao pra migrar do datacenter proprio pra AWS ao longo de 7 anos. Shopify usou pra migrar do monolito Rails pra microsservicos. As duas migracoes foram bem-sucedidas justamente porque nao tentaram fazer tudo de uma vez.

Casos reais: Netflix e Shopify

Netflix: 7 anos de migracao incremental

Em 2008, a Netflix sofreu uma corrupcao de banco de dados que derrubou o servico de entrega de DVDs por 3 dias. Esse incidente convenceu a lideranca de que precisavam migrar pra cloud. Mas em vez de tentar reescrever tudo, eles adotaram uma estrategia incremental.

Primeiro migraram os sistemas que nao tocavam no video streaming — billing, metadata, recomendacoes. Depois foram migrando os servicos mais criticos um por um. O streaming em si foi o ultimo a migrar. A Netflix so desligou o ultimo servidor de datacenter em janeiro de 2016 — quase 8 anos depois do inicio.

O resultado? Zero downtime durante a migracao. E o sistema novo era dramaticamente mais resiliente. Se tivessem tentado um big bang rewrite, a chance de o Netflix ficar fora do ar por dias durante a transicao seria alta.

Shopify: do monolito aos componentes

O Shopify roda em um dos maiores monolitos Rails do mundo. Em vez de migrar pra microsservicos (o hype da epoca), eles adotaram uma abordagem diferente: modularizaram o monolito. Extrairam dominios de negocio em componentes isolados dentro do mesmo codebase, com fronteiras bem definidas.

Quando um componente ficava maduro o suficiente e precisava de escala independente, ai sim era extraido pra um servico separado. Nao todos de uma vez. Nao porque 'microsservicos sao o futuro'. So quando havia necessidade concreta.

A licao dos dois casos e a mesma: migracoes bem-sucedidas sao incrementais. Voce nao precisa reescrever tudo. Precisa reescrever o que importa, quando importa, e manter o resto funcionando enquanto isso.