Assumindo uma base de código de outro time: os primeiros 30 dias

Herdar uma base de código costuma acontecer em um momento ruim. O contrato com a agência acabou, o único engenheiro saiu, ou o produto cresceu além das pessoas que o construíram. A pressão é para mostrar progresso rápido, e o reflexo é começar a entregar features ou a planejar uma reescrita.

No primeiro mês, as duas coisas são erros. Trabalhar em sistemas herdados é caro (na pesquisa do Stripe, desenvolvedores relataram gastar 17,3 horas de uma semana de 41,1 horas com manutenção e código ruim, Developer Coefficient, 2018), mas você não consegue saber quais problemas importam até entender o que o sistema faz e onde ele quebra.

Esta é a ordem que eu recomendo para qualquer transição: primeiro os acessos, depois o build, depois os fluxos de receita, depois os riscos. Funciona tanto se o time anterior ainda está acessível quanto se ele sumiu há muito tempo.

Dias 1–3: a que você precisa ter acesso?

Antes de ler uma linha de código, descubra quem controla o sistema. Em transições, os problemas mais perigosos raramente estão no código; estão em contas que pertencem a alguém que não trabalha mais para você.

Liste cada um destes itens, quem é o dono hoje, e passe para o nome da empresa:

Depois, rotacione todos os segredos que o time anterior conseguia ler. Não é uma acusação, é só higiene: você não tem como saber onde foram parar cópias das chaves.

Semana 1: você consegue fazer o build e o deploy?

Seu primeiro objetivo técnico é chato e essencial: fazer o build do projeto a partir de uma máquina limpa e publicar uma mudança trivial pelo processo normal.

Anote cada passo enquanto avança. Variáveis de ambiente faltando, serviços não documentados, um script que só funciona no notebook do desenvolvedor anterior: cada um que você encontra agora seria um incidente mais tarde. Ao fim da semana, você deve ter:

• Um README que leve um novo engenheiro do clone até o app rodando.
• Um deploy que passe por um pipeline, não feito na mão.
• Uma mudança mínima (um ajuste de texto, uma linha de log) publicada em produção e verificada.

Não entregue features nesta semana, mesmo que alguém esteja esperando por uma. Enquanto você não conseguir fazer deploy com segurança e reverter, cada feature é uma aposta com a produção.

Semana 2: o que o sistema realmente faz?

Agora leia o sistema, começando pelo que importa para o negócio e não pela estrutura de pastas. Identifique os fluxos de receita: os fluxos que, se quebrarem, custam faturamento ou confiança. Na maioria dos produtos, isso significa cadastro, login, pagamento e a ação principal pela qual os clientes pagam.

Para cada fluxo de receita:

1. Siga-o pelo código, da tela até o banco de dados e de volta.
2. Liste os serviços externos de que ele depende.
3. Adicione monitoramento se não houver: rastreamento de erros e uma métrica simples de taxa de sucesso.

Ao fim da semana, você deve conseguir desenhar o sistema em uma página: os principais componentes, os bancos de dados, as integrações e os fluxos de receita que passam por eles. Essa página é o documento mais valioso da transição, e muitas vezes ela não existe.

Semanas 3–4: onde está o risco?

Com os acessos garantidos e os fluxos de receita visíveis, procure riscos em uma ordem fixa, do mais urgente para o menos urgente:

1. Segurança. Dependências desatualizadas com vulnerabilidades conhecidas, segredos no repositório, falta de checagem de autorização em endpoints sensíveis, buckets de storage públicos.
2. Dados. Backups que existem e que podem de fato ser restaurados (teste um), migrações versionadas, dados pessoais guardados onde não deveriam estar.
3. Erros em produção. Os dez erros mais frequentes. Sistemas herdados costumam ter um ruído constante de falhas que ninguém olha.
4. Testes nos fluxos de receita. Se não houver nenhum, escreva alguns testes end-to-end para os fluxos da semana 2 antes de alterá-los.
5. Desempenho. Queries e páginas lentas nos fluxos de receita, não em todo lugar.

Mantenha uma lista escrita, ordenada por impacto e esforço. Ela vira o plano do próximo trimestre e a evidência para qualquer decisão maior.

Você deve reescrever o código que herdou?

Provavelmente não, e com certeza não no primeiro mês. Uma reescrita joga fora cada correção de bug e cada caso de borda que o sistema antigo aprendeu em produção, e deixa o negócio sem melhorias por meses.

Depois de 30 dias, você tem a evidência para decidir. Reescreva uma parte do sistema quando:

• Mudanças nela são consistentemente lentas e arriscadas, e você consegue mostrar isso com exemplos.
• A tecnologia dela bloqueia algo de que o negócio precisa em seguida.
• Você consegue substituí-la aos poucos, um fluxo de cada vez, atrás de um switch.

Se for esse o caminho, migre jornada por jornada enquanto o sistema antigo continua rodando. Escrevi sobre migrar uma plataforma em produção para uma nova stack sem downtime, que é exatamente essa abordagem.

O que você deve perguntar ao time anterior?

Se o time que está saindo ainda pode ser contatado, uma ou duas horas com ele valem mais do que uma semana lendo código. Pergunte:

• O que quebra com mais frequência, e como vocês corrigem?
• Em quais partes do código vocês têm medo de mexer, e por quê?
• O que está pela metade: features, migrações, refatorações?
• Quais jobs agendados, scripts ou tarefas manuais mantêm o sistema funcionando?
• O que vocês fariam em seguida se fossem ficar?

Registre as respostas. A última pergunta é a que as pessoas respondem com mais honestidade quando estão de saída.