O sistema está no ar há três anos e faz o que precisa fazer. Só que, de uns meses para cá, cada pedido de mudança vira uma negociação: o fornecedor diz que aquilo é mais complexo do que parece, os prazos dobraram, e bugs que já tinham sido corrigidos voltam a aparecer em telas diferentes. Nada disso é comprovável do lado de fora.
Aí vem a parte incômoda. A única pessoa capaz de explicar tecnicamente o que está acontecendo é justamente quem escreveu o código e quem você está começando a questionar. Você não tem como saber se as respostas são honestas, se o sistema realmente ficou complexo ou se está sendo mal cuidado. E o contrato vence em três meses.
A tese deste texto é que essa é uma pergunta que tem resposta, e resposta em linguagem de negócio. Auditoria de código existe para transformar desconfiança em evidência, e custa uma fração do que custa descobrir a verdade depois de renovar um contrato ruim por mais dois anos.
O que é uma auditoria de código?
Auditoria de código é uma avaliação independente da qualidade interna de um software, feita por especialistas que não participaram da construção, com o objetivo de mapear riscos técnicos e traduzi-los em consequências de negócio. Ela olha o que está por baixo da interface: como o sistema foi construído, o quanto ele é seguro, o quanto é caro de evoluir e o quanto depende de pessoas específicas.
A palavra independente é o que dá valor ao exercício. Um time avaliando o próprio trabalho tende a explicar as escolhas em vez de questioná-las, o que é humano e esperado. A auditoria funciona porque quem olha não tem nada a defender.
Vale separar de coisas parecidas. Não é um teste de invasão, que ataca o sistema em funcionamento para achar brechas exploráveis. Não é um teste de qualidade funcional, que verifica se as telas fazem o que deveriam. A auditoria abre o motor e avalia a construção, o que inclui segurança e qualidade, mas vai além das duas.
Por que o sistema funcionar na tela não prova que está bem-feito?
Porque o usuário só enxerga o resultado, nunca o custo de produzi-lo. Dois sistemas com telas idênticas podem ter custos de manutenção que diferem em cinco vezes, e nada nessa diferença é visível para quem usa.
Uma analogia ajuda. Duas casas podem ter a mesma fachada e a mesma planta. Em uma, a fiação está documentada, os canos são acessíveis e trocar uma tomada leva vinte minutos. Na outra, a fiação foi improvisada, ninguém sabe por onde passa, e trocar a mesma tomada exige quebrar parede. As duas acendem a luz. Só uma delas você quer reformar daqui a dois anos.
É essa diferença invisível que se acumula até virar o problema que já descrevemos ao falar de dívida técnica. O sintoma que chega ao gestor é sempre o mesmo: pedidos simples que passaram a demorar muito, e ninguém consegue explicar por quê de um jeito que faça sentido.
O que exatamente a auditoria examina?
Os pontos variam conforme o sistema, mas um trabalho sério cobre pelo menos estas frentes:
- Organização e padrão do código. Se existe estrutura reconhecível e consistente ou se cada parte foi escrita de um jeito. Isso determina quanto tempo um profissional novo leva para produzir, o que impacta diretamente o custo de trocar de equipe.
- Cobertura de testes automatizados. Quanto do sistema é verificado sozinho a cada mudança. Cobertura baixa explica bugs que voltam, tema que detalhamos ao falar de testes de software e QA.
- Dependências e atualizações. Todo sistema usa componentes de terceiros. Componentes abandonados ou muito desatualizados são risco de segurança e bomba-relógio de custo.
- Falhas de segurança evidentes. Senhas escritas no código, permissões mal verificadas, dados sensíveis sem proteção. A auditoria não substitui um teste de invasão, mas encontra o que está à vista.
- Concentração de conhecimento. O quanto o sistema depende de uma única pessoa para ser entendido. É o risco que mais assusta empresas quando fica explícito em números.
- Documentação e capacidade de retomada. Se um time novo consegue rodar o sistema do zero em um dia ou em três semanas, assunto que tratamos ao falar de código-fonte e documentação.
Nenhum desses itens exige que você entenda de programação para interpretar. Todos têm tradução direta em prazo, custo ou risco.
Quando faz sentido pedir uma auditoria?
Existem quatro momentos em que o investimento praticamente sempre se paga.
O primeiro é antes de renovar contrato com o fornecedor atual. Assinar mais dois anos sem saber o estado do que você está comprando é a decisão de maior risco e menor informação que uma empresa toma em tecnologia.
O segundo é antes de trocar de time. Você precisa saber o tamanho real do que está entregando ao próximo fornecedor, sob pena de receber uma proposta baseada em premissas otimistas que vira aditivo três meses depois. Isso muda completamente a qualidade da troca de fornecedor de software.
O terceiro é antes de comprar uma empresa ou um produto digital. O software costuma ser boa parte do valor do negócio, e raramente é examinado com o mesmo rigor das demonstrações financeiras.
O quarto é depois de uma sequência de incidentes em produção. Quando bugs graves aparecem em intervalos curtos, existe uma causa estrutural, e ela quase nunca é a que o time aponta no calor do momento.
O que você recebe no fim e como usar o resultado?
O entregável que serve a um gestor é um laudo em linguagem de negócio, e esse ponto merece ser exigido em contrato. Um relatório com trezentos apontamentos técnicos ordenados por ferramenta é inútil para decidir qualquer coisa.
O formato útil traz uma nota geral de saúde do sistema, uma lista curta de riscos priorizados por impacto e probabilidade, e uma estimativa de esforço para corrigir cada um. Cada risco vem com a frase que importa: o que acontece com o negócio se isso não for tratado. Falta de teste automatizado vira risco de indisponibilidade em atualizações. Concentração em uma pessoa vira risco de paralisação. Dependência abandonada vira risco de segurança com prazo.
Com esse documento em mãos, três conversas ficam possíveis. Com o fornecedor atual, sobre um plano de correção com prazo. Com um fornecedor novo, sobre uma proposta baseada em realidade. E internamente, sobre quanto orçamento reservar para saúde do sistema no próximo ano, em vez de descobrir a conta na forma de uma emergência.
Quanto custa e quanto tempo leva uma auditoria?
Para um sistema de porte médio, uma auditoria costuma levar de uma a três semanas e envolver poucas pessoas experientes. Como referência de proporção, e não como orçamento, o custo tende a ficar bem abaixo de um mês de contrato de manutenção do mesmo sistema, o que a torna uma das análises de melhor relação entre custo e informação em tecnologia.
O que você precisa fornecer é acesso de leitura ao código, ao histórico de alterações e à documentação existente, além de algumas horas de conversa com quem conhece o negócio. Não é necessário parar o time nem avisar o fornecedor previamente, embora avisar seja o caminho mais saudável quando a intenção é continuar a relação.
Um alerta útil: desconfie de propostas que entregam resultado em dois dias. Auditoria séria exige leitura humana do código, e leitura humana leva tempo. Relatório instantâneo é relatório de ferramenta automática, que tem valor, mas não responde às perguntas que levaram você até aqui.
Auditar antes de renovar custa menos que descobrir depois
A assimetria de informação entre quem contrata software e quem o produz é o problema estrutural desse mercado. O cliente paga por algo que não consegue avaliar e depende da palavra de quem produziu. A auditoria independente é o instrumento que corrige essa assimetria, e por isso costuma se pagar já na primeira negociação em que você senta com dados em vez de suspeitas.
Não é um ato de desconfiança contra o fornecedor. Fornecedores bons costumam gostar do exercício, porque ele transforma em evidência o cuidado que eles vinham tendo sem conseguir provar. Quem reage mal ao pedido de auditoria já está respondendo à sua pergunta.
Na DevCore, realizamos auditorias independentes de sistemas construídos por terceiros dentro dos nossos serviços de qualidade de software, sempre com laudo em linguagem de negócio e riscos priorizados. Se você tem um contrato para renovar ou uma desconfiança que não sai da cabeça, fale com o nosso time e vamos avaliar o que está por baixo da interface.
Perguntas frequentes sobre auditoria de código
Preciso avisar o fornecedor atual que vou auditar o sistema?
Do ponto de vista contratual, na maioria dos casos o código é seu e você não precisa de autorização. Do ponto de vista prático, avisar costuma render um processo melhor e mais rápido, porque o time atual ajuda com contexto. Só faz sentido não avisar quando a relação já está rompida ou quando existe suspeita concreta de má-fé.
A auditoria serve para sistema comprado pronto, não feito sob medida?
Para software de prateleira, normalmente não, porque você não tem acesso ao código nem responsabilidade sobre ele. Nesses casos a avaliação certa é de fornecedor e contrato: garantias, prazo de suporte, portabilidade dos seus dados e o que acontece se a empresa encerrar o produto.
O que fazer se o laudo apontar muitos problemas graves?
Não reescrever tudo por impulso. Um laudo bem-feito prioriza, e quase sempre existe um subconjunto pequeno de correções que elimina a maior parte do risco. Trate como plano de doze meses, resolvendo primeiro o que ameaça a operação e a segurança, e depois o que encarece a evolução.