Uma auditoria de código legado que vale o preço

Uma auditoria de código legado só vale o preço quando outra equipe competente consegue agir com ela sem comprar uma segunda descoberta. Ela deve explicar o que existe, o que ainda roda, quais processos podem falhar e quanto custa cada unidade razoável de mudança. Se o documento termina em diagramas, notas de qualidade e uma recomendação de modernização, você comprou uma peça de vendas.

Já analisei auditorias que pareciam caras por serem longas. As úteis costumavam dar mais trabalho e ser mais fáceis de ler. Cada afirmação apontava para código, evidência de execução, entrevista ou hipótese explícita. Cada fase tinha limite, teste de aceite, dependências e preço. Essa rastreabilidade separa os dois casos.

A auditoria deve definir o limite antes de julgar

Uma auditoria confiável começa dizendo o que foi inspecionado e o que ficou fora. Sistemas antigos raramente cabem num repositório. Uma aplicação COBOL pode depender de JCL, agendadores, copybooks, objetos DB2, transferências e uma planilha Excel da área financeira. Um aplicativo desktop pode escrever direto num banco compartilhado enquanto um script noturno corrige registros que a interface não resolve. Omitir essas bordas prejudica todas as conclusões.

O registro de escopo deve listar repositórios, branches, versões implantadas, arquivos de build, esquemas, jobs, interfaces, configurações, relatórios e procedimentos. Para cada item, registre fonte da evidência e versão ou data observada. Um repositório sem commit não prova o que foi analisado; um esquema de desenvolvimento não prova o que existe em produção.

Também é necessária uma lista de exclusões. Talvez um pacote não possa ser aberto, os logs guardem só sete dias ou o compilador antigo não rode. Não são notas de rodapé. Cada exclusão deve declarar a consequência, como: "A alcançabilidade do batch permanece incerta porque não havia histórico do agendador."

Peça uma tabela com ativo, evidência, confiança e lacuna. A confiança deve refletir a qualidade da prova, não a intuição. Código, saída de build e traces de produção valem mais que uma entrevista isolada. Sem limites e lacunas, a análise não é reproduzível nem justifica o preço.

O mapa de módulos deve mostrar comportamento, dados e donos

Um mapa útil é um inventário ligado a evidências de dependência, não caixas coloridas. Ao selecionar um módulo, um engenheiro deve saber quem o chama, o que ele chama, quais dados lê ou altera e qual processo depende dele. Grafo, tabela ou ambos funcionam com identificadores estáveis e arestas rastreáveis.

Cada nó deve ter caminho, linguagem, artefato ou job, entradas, dados persistentes, interfaces, gatilho ou agenda e dono conhecido. Cada aresta deve dizer por que existe. Resolução estática, imports, análise de SQL, configuração do agendador, metadados e tráfego observado são provas diferentes. Misturá-las esconde incerteza.

Dependências legadas são confusas. Chamadas dinâmicas, nomes gerados, reflexão, tabelas compartilhadas, arquivos temporários e registros de controle enganam um parser simples. O relatório deve manter arestas não resolvidas. "Destino calculado em execução" é útil; um diagrama limpo que omite a chamada é perigoso. Ciclos devem continuar visíveis porque determinam a ordem de extração.

O mapa precisa de uma camada de negócio. "ARUPD07 chama DATECNV" ajuda engenharia. "O fechamento da aplicação de recebimentos depende de ARUPD07 e da importação bancária" ajuda a decidir. As duas visões devem estar no mesmo modelo, ligadas por evidências. Se um workshop precisar recriar a relação após a entrega, ela está incompleta.

Exija os dados, não apenas diagramas. Um arquivo de arestas basta:

source_id,target_id,edge_type,evidence,confidence,business_process
ARUPD07,DATECNV,static_call,src/ar/ARUPD07.cbl:418,high,cash_application
NIGHTLY_AR,ARUPD07,schedule,ops/sched/nightly.jcl:77,high,cash_application
ARUPD07,BANK_RATE,dynamic_call,production_trace:sample_042,medium,cash_application

A equipe pode comparar, consultar e carregar o arquivo em qualquer ferramenta. Uma captura presa num PDF não sustenta planejamento nem verificação posterior.

Código morto é uma afirmação medida, não um percentual

A auditoria deve separar código inalcançável, não observado, dormente e estruturas sem uso, pois levam a decisões diferentes. Equipes confundem essas categorias e apagam algo usado no fechamento anual. A análise estática mostra que nenhuma entrada conhecida alcança uma rotina. A observação só mostra que ela não rodou naquela janela. Não são equivalentes.

O registro deve identificar unidade, método, janela, ciclos cobertos, contraprovas, confiança e ação. Contagem de linhas é fraca. Dez mil linhas geradas podem ser recriadas com segurança, enquanto uma exceção fiscal de vinte linhas traz risco sério. Meça unidade lógica e comportamento antes do percentual.

Use várias evidências: referências de build, alcançabilidade, histórico de jobs, traces, acessos a dados, feature flags e operadores. Nenhuma basta sozinha. O histórico perde recuperações manuais, traces perdem fim de trimestre e entrevistas preservam folclore antigo. A concordância eleva a confiança; contradições entram no relatório.

Um registro defensável diria: "CLAIMS_REPRINT não tem chamadores estáticos, agenda nem execução em dois ciclos normais. Operações informa que o suporte o inicia após falhas de impressora. Classificação: recuperação dormente, não código morto. Ação: manter até o substituto incluir a recuperação." Isso vale mais que um painel com 18% de código morto.

Peça numerador e denominador. "Sem uso" significa linhas, funções, programas, tabelas, telas ou etapas? Comentários e fontes geradas foram excluídos? Compilação condicional e chamadas dinâmicas foram cobertas? Sem respostas, trate o percentual como pista, não como base de escopo ou economia.

Os riscos devem apontar para processos e falhas

Uma lista ordenada só serve quando cada item liga uma condição técnica a evento de negócio, falha e impacto observável. "Alto acoplamento" ainda não é risco. "O job de faturas e o serviço de crédito atualizam a mesma tabela com regras distintas; uma falha parcial pode liberar pedidos contra saldo antigo" permite decisão.

Cada risco deve incluir processo, evento, causa, comportamento, detecção, controle, alcance, evidência e correção. O ranking deve explicar probabilidade e impacto. Decimais não tornam opiniões objetivas; escalas simples com definições costumam ser melhores.

Não coloque manutenibilidade acima da produção porque um scanner a conta. Uma rotina de 4.000 linhas pode ser feia e estável. Uma conciliação limpa de 200 pode perder registros se receber o arquivo duas vezes. Classifique a segunda acima quando houver prova. Exposição, frequência de mudança, recuperação e demora de detecção importam mais que estética.

Riscos precisam de um dono capaz de resolver ou aceitar a exposição, não necessariamente do programador. Se o processo não tem responsável, registre a falha de governança em vez de atribuir a "TI".

Uso um teste direto: quem executa o processo reconhece a falha descrita? Se contas a receber, armazém ou conformidade não relacionam o item a um evento real, o auditor provavelmente classificou problemas de estilo, não riscos operacionais.

Evidência de execução deve cobrir o calendário importante

Um trace só é útil se a janela combina com o calendário do negócio. Trinta dias comuns podem cobrir milhares de requisições e perder fechamento trimestral, renovação anual, preço sazonal ou recuperação rara. A auditoria deve declarar ciclos cobertos e ausentes.

Monte um calendário diário, semanal, de fim de mês, trimestral, anual, por evento e de recuperação. Mapeie execuções nele. Assim, alto volume online não esconde batch raro. Use configuração, procedimentos, transações e entrevistas, não só memória.

Privacidade e limites operacionais fazem parte do método. Talvez sejam usados formatos de requisição, hashes, contagens, amostras ou logs editados. O relatório deve dizer como tratou campos sensíveis e qual fidelidade perdeu. Nunca copie credenciais ou dados pessoais apenas para provar o tracing.

O entregável deve mostrar IDs, horários, entradas, status, componentes, tabelas ou arquivos e processo associado. Agregados devem apontar às observações. Sem essa cadeia, o auditor pode chamar uma rota de "ativa" ou "sem uso" sem demonstrar por quê.

Telemetria ausente não torna o código morto. Ela muda a recomendação: instrumentar, observar por mais tempo ou reproduzir de forma controlada antes de apagar. Incerteza é normal; escondê-la não.

O plano em fases precisa de limites, prova e preço

Uma fase só é comprável com escopo, dependências, aceite e preço explícitos. "Fundação, transformação, otimização" não explica o que muda após a fatura. Uma boa fase nomeia a fatia de negócio ou junção técnica, ativos alterados, interfaces mantidas e prova de aceite.

Cada fase deve declarar cinco itens:

1. Módulos, dados, interfaces e processos incluídos.
2. Pré-condições e decisões do cliente.
3. Entregáveis e ambiente de execução.
4. Testes de aceite, incluindo paridade e operação.
5. Preço fixo ou faixa limitada com hipóteses.

Preço sem hipótese é isca. Hipóteses podem cobrir ferramentas, tráfego, esquemas, licenças ou aceite do cliente. Cada uma deve ter mecanismo de alteração precificado. Se faltar uma definição de interface, o relatório deve dizer como escopo ou preço muda.

A sequência precisa de argumento. Um módulo pequeno parece seguro, mas pode provar apenas conversão de sintaxe. Uma primeira fase melhor cruza uma junção representativa e testa dados, build, implantação e paridade com exposição limitada. A auditoria deve explicar qual incerteza reduz.

Inclua alternativas quando as evidências aceitam mais de um caminho. A equipe pode extrair preços primeiro ou estabilizar o contrato do banco compartilhado. Mostre custo, dependência e risco. Um único roteiro pode disfarçar preferência do fornecedor como necessidade técnica.

Estimativas devem ser reconstruídas a partir da evidência

Uma estimativa confiável mostra como escopo vira preço. Não precisa expor salários ou margem, mas deve mostrar unidades, fatores de complexidade, exclusões, reservas e hipóteses. Sem isso, o número convida à negociação, não ao planejamento.

O modelo deve ligar aos registros. Se uma fase inclui doze programas, três jobs, duas interfaces e uma tabela, cite os IDs exatos. Ajustes devem nomear a causa: despacho dinâmico, build ausente, formato não documentado, conversão ou ambiente indisponível. "Multiplicador de complexidade legada" é vago.

Uma faixa é razoável se o relatório disser como fechá-la. Se o mínimo presume build reproduzível e o máximo sua reconstrução, um teste de um dia pode gerar preço firme. Faixa larga sem regra apenas transfere risco ao comprador.

Peça um registro inspecionável:

Phase: cash application slice
Scope IDs: NIGHTLY_AR, ARUPD07, DATECNV, BANK_RATE
Base work: behavior capture, target implementation, data adapter, deployment
Risk allowances: dynamic call resolution; incomplete printer-recovery trace
Customer inputs: redacted traffic set; operations reviewer
Acceptance: replay parity; close totals match; recovery procedure demonstrated
Price: [amount or bounded range]
Range closes when: build and recovery-path tests complete

O método pode variar, mas não a cadeia entre ativo, trabalho e preço. Se ela for secreta, você não saberá se o valor reflete seu sistema ou uma meta comercial.

Uma auditoria real deixa evidências contestáveis

O pacote final deve trazer registros editáveis e exportações legíveis por máquina. Seus engenheiros devem filtrar módulos dormentes, seguir um risco até tabelas ou ver qual fase possui uma interface. Se o auditor controla o único modelo útil, você alugou entendimento.

Exija IDs de evidência. Uma aresta cita código ou trace; um risco, arestas, incidentes e entrevista; uma fase, riscos e ativos. Assim os engenheiros contestam uma prova, não a conclusão de um consultor.

Inclua notas de reprodução: ferramentas e versões, comandos, branches e commits, janelas, filtros, limites e correções manuais. O objetivo é distinguir evidência gerada de julgamento humano e inspecionar ambos.

Na revisão, escolha uma rota de receita, um batch, um módulo supostamente morto e uma fase cara. Siga cada item para trás. Se a trilha quebrar, registre o artefato ausente antes do aceite. Isso revela mais que outra apresentação.

O contrato deve transferir registros, esquemas, diagramas, scripts específicos e exportações úteis de ambientes proprietários. Licenças podem limitar uma ferramenta, mas seu modelo do sistema não deve sumir quando o acesso expirar.

Documentos de vendas se revelam antes do discurso final

Uma peça comercial começa com um destino decidido e coleta evidência para justificá-lo. Uma auditoria real permite que a evidência mude a recomendação, inclusive mantendo parte do sistema. A proposta e a primeira revisão normalmente revelam qual é qual.

Observe estes sinais:

• Entregáveis prometem achados sem definir campos ou fontes.
• O preço baixo será recuperado numa implementação presumida.
• Riscos vêm de scanner genérico sem processo de negócio.
• O roteiro usa etapas amplas sem testes ou preços.
• O fornecedor mostra o modelo, mas não entrega os registros.

Rejeite precisão teatral. Nota 2,7, mapa vermelho ou percentual exato pode esconder pesos arbitrários. Pergunte que decisão muda com a nota. Se nenhuma, ela só decora a venda.

Independência não é neutralidade. Uma empresa de execução pode auditar bem se separar prova e recomendação, precificar alternativas e transferir artefatos. Uma consultoria sem entrega pode escrever um relatório vago. Julgue o trabalho e os incentivos.

Antes de assinar, inclua registros, campos, formatos, ligações, revisão e prazo de correção no contrato. Não aceite "relatório completo" como entregável. Completo é adjetivo; um registro com colunas definidas é inspecionável.

A auditoria deve permitir a primeira decisão de entrega

Ela termina quando a liderança pode escolher uma primeira fase limitada, entender o risco reduzido, ver sistemas e pessoas afetados e aprovar preço ligado a evidência. Um relatório grosso que termina em "mais descoberta" não chegou lá. Cada incógnita precisa de dono, método de resolução e decisão afetada.

O registro final deve incluir fase escolhida, alternativas, referências, hipóteses abertas, testes, preço e condições de parada. Build irreproduzível, tráfego que contradiz o mapa ou interface controlada por terceiro podem parar o trabalho. Nomeá-los evita manter uma estimativa após mudar suas premissas.

Se o objetivo é reescrever, a paridade pertence à decisão. CodeHero lê toda a base e verifica o comportamento preservado contra tráfego gravado de produção. Exija de qualquer fornecedor o comportamento comparado, o tráfego representativo, a classificação das diferenças e quem as aceita. "Funcionalmente equivalente" sem harness e arbitragem é só outro adjetivo.

Pague quando a auditoria transforma incerteza em escolhas rastreáveis. Recuse quando a transforma em slides. Entregue os artefatos a um engenheiro ausente dos workshops e peça escopo, evidência, risco, teste e preço da fase um. Se ele encontra tudo ligado, a auditoria cumpriu seu papel.