Como avaliar a qualidade do código de um sistema sem programar

O fornecedor entregou o sistema, a homologação passou e as telas funcionam. Seis meses depois, cada pedido de ajuste volta com uma estimativa maior que a anterior, uma correção no financeiro quebra o relatório de vendas e ninguém quer publicar versão na sexta-feira. O dono da empresa pagou por um software e não sabe dizer se recebeu um ativo ou um problema.

A situação é parecida quando o sistema é herdado: um desenvolvedor saiu, uma empresa parceira encerrou o contrato, ou o sistema veio junto com uma aquisição. Alguém precisa decidir se vale continuar investindo nele, e essa pessoa raramente lê código.

A boa notícia é que dá para avaliar qualidade de código sem programar. Não pelo código em si, mas pelo que ele produz no dia a dia: tempo de mudança, frequência de erro, dependência de pessoas e risco de segurança. Este texto mostra quais sinais olhar, que perguntas fazer à equipe e quando vale chamar alguém de fora para olhar por dentro.

A resposta curta: como avaliar sem ler uma linha

Se você tem pouco tempo, a avaliação se resume a cinco perguntas. Cada uma tem uma resposta que o gestor consegue verificar sem abrir o código:

1. Mudanças simples levam tempo proporcional ao que pedem? Incluir um campo, mudar um texto de e-mail ou ajustar uma regra de desconto deveria levar pouco tempo. Se cada ajuste pequeno vira projeto, o código está cobrando caro.
2. Correções quebram outras coisas? Regressão é o nome técnico para "consertou aqui, quebrou ali". Se acontece com frequência, as partes do sistema estão amarradas demais e não há testes automatizados protegendo o que já funciona.
3. Alguém além do autor revisa o que vai para produção? Código que ninguém revisa acumula atalhos e só uma pessoa entende.
4. As peças de terceiros estão atualizadas? Frameworks, bibliotecas e versões de linguagem fora de suporte deixam de receber correções de segurança.
5. Um profissional independente já olhou o código? A opinião de quem escreveu nunca é suficiente, para o bem ou para o mal.

As seções seguintes detalham cada sinal e terminam com um checklist para usar na próxima reunião.

Por que qualidade de código é assunto de gestão

Código ruim não aparece no balanço, mas aparece no resultado. Ele se manifesta como custo de mudança: cada nova funcionalidade consome mais horas da equipe do que deveria. Aparece como risco operacional: o sistema para no fechamento do mês, a nota fiscal não sai, o pedido some. E aparece como dependência: só uma pessoa sabe mexer, e a empresa fica refém dela.

Esse acúmulo tem nome, e já explicamos em detalhe no texto sobre dívida técnica para gestores. Aqui o foco é anterior: como descobrir o tamanho do problema antes de decidir o que fazer com ele.

Qualidade também não é questão de estética. A pergunta de gestão é outra: este sistema consegue acompanhar o negócio pelos próximos anos a um custo razoável?

Sintomas visíveis de código ruim

Antes de qualquer métrica, observe o que já acontece. Os sintomas abaixo aparecem em conversas, chamados e reuniões:

• "Não dá para mexer nisso." Módulos que a equipe evita são o sinal mais claro de código frágil.
• Bugs que voltam. O mesmo erro reaparece porque a regra está copiada em vários lugares e a correção acertou só um.
• Publicação com cerimônia. Colocar uma versão no ar exige madrugada, roteiro manual e alguém de plantão.
• Lentidão que piora com o tempo. Telas que abriam rápido ficam lentas conforme a base cresce. Nem toda lentidão é culpa do código, e vale separar as causas antes de concluir, como mostramos no texto sobre diagnóstico de performance.
• Erros sem explicação. Quando algo falha, ninguém consegue dizer por quê sem horas de investigação, porque o sistema não registra o que fez.
• Gente nova demora a render. Um desenvolvedor recém-chegado leva meses até entregar algo sozinho, porque não há padrão nem documentação que explique como as partes se encaixam.

Nenhum desses sinais isolado condena o sistema. Três ou mais ao mesmo tempo indicam que vale aprofundar a avaliação.

Tempo para mudanças simples

Este é o indicador mais útil para o gestor, porque traduz qualidade de código em tempo de equipe.

Como medir

Escolha três ou quatro mudanças pequenas e típicas do seu negócio. Por exemplo:

• incluir um campo novo no cadastro de cliente e mostrá-lo no pedido;
• mudar o texto do e-mail de confirmação de compra;
• alterar uma regra de comissão de vendedor;
• adicionar uma coluna num relatório existente.

Peça à equipe uma estimativa para cada uma e, quando possível, acompanhe quanto tempo levou de fato até estar em produção. Compare com o que essas mudanças levavam no passado, se houver histórico no sistema de chamados.

Como interpretar

O tempo absoluto importa menos do que a tendência e a proporção. Se a mesma mudança leva cada vez mais tempo, a qualidade está caindo, mesmo que a equipe seja boa.

Regressões e testes automatizados

Regressão é quando uma correção ou funcionalidade nova quebra algo que já funcionava. Ela é o sintoma mais caro, porque o erro costuma chegar ao cliente antes da equipe.

O antídoto técnico são os testes automatizados: pequenos programas que verificam, a cada mudança, se as regras principais continuam funcionando. Você não precisa ler os testes, mas pode fazer perguntas objetivas:

• Existem testes automatizados? A resposta "testamos manualmente antes de publicar" significa que a proteção depende da memória de alguém.
• Eles rodam sozinhos a cada mudança? Testes que só rodam quando alguém lembra não protegem nada.
• Cobrem as regras críticas? Cálculo de imposto, preço, comissão, estoque e faturamento são os primeiros que devem ter teste.
• Quando um teste falha, a publicação é bloqueada? Se a equipe pode publicar com teste quebrado, o teste é decorativo.

Peça também para ver os chamados dos últimos meses e conte quantos foram causados por uma entrega recente. Esse número, acompanhado ao longo do tempo, vale mais que qualquer relatório técnico.

Revisão de código e padrões

Em equipes saudáveis, nenhuma linha vai para produção sem que outra pessoa leia. Essa prática se chama revisão de código, e ela pega erros, espalha conhecimento e mantém o padrão do projeto.

Perguntas para fazer:

• Toda mudança passa por revisão antes de ir ao ar? Peça para ver algumas revisões recentes na ferramenta de versionamento. Você não precisa entender o conteúdo, só ver se existem comentários e aprovações.
• O código está num repositório versionado que a empresa controla? Código que mora só no computador de um desenvolvedor é risco de continuidade. O acesso ao repositório também é questão contratual, como discutimos no texto sobre propriedade do código-fonte no contrato.
• Existe um padrão escrito? Regras de organização, nomes e formatação, mesmo que simples, tornam o código previsível para quem chega.
• Há ferramentas de análise automática? Existem ferramentas que apontam código duplicado, trechos complexos demais e falhas de segurança conhecidas. Se a equipe usa, peça o relatório. Se não usa, vale perguntar por quê.

Sistema feito por uma única pessoa, sem revisão nem padrão, deixa a empresa refém dela: risco de gestão, não técnico.

Dependências desatualizadas

Nenhum sistema é escrito do zero. Ele usa uma linguagem de programação, um framework, um banco de dados e dezenas de bibliotecas de terceiros. Cada uma dessas peças tem um ciclo de vida: recebe atualizações por um tempo e depois é abandonada. Esse ciclo pesa na escolha entre Node.js, .NET ou Java.

Peças fora de suporte geram dois problemas:

• Segurança. Falhas descobertas depois do fim do suporte não são corrigidas. O sistema fica exposto, e isso pesa também em obrigações de proteção de dados.
• Custo de atualização acumulado. Quanto mais tempo sem atualizar, maior o salto e maior o risco quando a atualização se torna obrigatória, por exemplo quando o servidor de hospedagem deixa de aceitar a versão antiga.

Pergunte à equipe:

• Qual a versão da linguagem e do framework em uso, e até quando elas recebem suporte?
• Existe alguma biblioteca com falha de segurança conhecida? (Há ferramentas que respondem isso automaticamente.)
• Quando foi a última atualização geral das dependências?

Se ninguém sabe responder, esse já é o diagnóstico.

Auditoria de código por terceiros

Os sinais acima mostram que há um problema. A auditoria mostra onde ele está e quanto custa resolvê-lo. Ela é feita por profissionais que não escreveram o sistema e, por isso, não têm interesse em defender nem em condenar o que encontraram.

Quando vale a pena

• Antes de assumir um sistema herdado de outro fornecedor ou de uma equipe que saiu. Nesse caso, a auditoria é parte do processo descrito no texto sobre assumir um sistema legado sem documentação.
• Antes de um investimento grande em novas funcionalidades sobre uma base antiga.
• Quando a equipe atual e a gestão discordam sobre a saúde do sistema.
• Em aquisições de empresas em que o software é parte relevante do valor.
• Antes de decidir entre manter, refatorar ou reescrever.

O que uma boa auditoria entrega

• Mapa de riscos em linguagem de negócio: o que pode parar a operação, o que expõe dados, o que encarece mudanças.
• Avaliação da arquitetura: como as partes se conectam e onde estão amarradas demais.
• Situação de testes, revisão e publicação: o processo, não só o código.
• Inventário de dependências: versões, suporte e falhas conhecidas.
• Prioridades: o que resolver primeiro, o que pode esperar e o que não vale mexer.

Desconfie de auditoria que entrega só uma lista longa de problemas sem priorização. O valor está em dizer quais deles importam para o seu negócio.

Como pedir

Uma auditoria precisa de acesso ao repositório de código, à documentação existente (mesmo que pouca), ao ambiente de homologação e, idealmente, a algumas conversas com quem usa e mantém o sistema. O prazo varia com o tamanho do sistema: costuma ir de alguns dias a algumas semanas, e só dá para estimar com segurança depois de ver o código.

Checklist para avaliar a qualidade do código

Use esta lista na próxima conversa com a equipe técnica ou com o fornecedor:

• Mudanças pequenas e típicas são entregues num tempo proporcional ao que pedem?
• A tendência das estimativas é estável, e não crescente?
• Correções raramente quebram outras partes do sistema?
• Existem testes automatizados cobrindo as regras críticas do negócio?
• Os testes rodam sozinhos e bloqueiam a publicação quando falham?
• Toda mudança é revisada por outra pessoa antes de ir ao ar?
• O código está num repositório que a empresa controla e acessa?
• Linguagem, framework e bibliotecas estão em versões com suporte?
• Publicar uma versão é rotina, sem madrugada nem roteiro manual?
• Mais de uma pessoa consegue dar manutenção em cada parte do sistema?

Se mais da metade das respostas for "não" ou "não sei", o próximo passo é um diagnóstico técnico, não uma decisão de reescrever.

O que fazer com o diagnóstico

Avaliar é a parte fácil. A decisão vem depois, e há basicamente três caminhos:

• Manter e melhorar aos poucos. Quando a base é razoável e os problemas estão concentrados, a equipe reserva uma parte de cada ciclo para arrumar os pontos críticos, começando pelos módulos que mais mudam.
• Refatorar partes inteiras. Quando um módulo específico concentra os problemas, ele é reorganizado por dentro, com testes, sem mudar o que o usuário vê.
• Substituir gradualmente. Quando a base não sustenta o negócio, partes novas são construídas ao lado da antiga e assumem funções uma a uma. Reescrever tudo de uma vez raramente é a melhor escolha, e a comparação está no texto sobre reescrever ou refatorar um sistema legado.

Em qualquer caminho, três cuidados valem:

1. Comece pelo risco, não pelo gosto. Falha de segurança e risco de parada vêm antes de código feio.
2. Meça antes e depois. Use os mesmos indicadores da avaliação, como tempo de mudança e regressões, para saber se o esforço está dando resultado.
3. Garanta o acesso. Repositório, servidores, domínios e credenciais devem estar em nome da empresa antes de qualquer outra coisa.

Mais artigos sobre esse tipo de decisão estão na categoria engenharia.

Perguntas frequentes

Quanto tempo leva uma auditoria de código?

Depende do tamanho do sistema e da documentação disponível. Uma auditoria de código costuma levar de alguns dias a algumas semanas, e a estimativa só fica segura depois que os auditores veem o repositório. O prazo também depende de acesso rápido ao código, ao ambiente de homologação e às pessoas que usam e mantêm o sistema.

Ferramentas de análise automática substituem uma auditoria de código?

Não. Ferramentas de análise automática apontam código duplicado, trechos complexos demais e falhas de segurança conhecidas, mas não avaliam arquitetura, processo de publicação nem impacto no negócio. O relatório delas é um bom insumo para a auditoria de código, mas decidir o que resolver primeiro exige análise humana de quem conhece sistemas parecidos.

Vale a pena reescrever um sistema com código de baixa qualidade?

Raramente de uma vez. Antes de reescrever, vale medir onde estão os problemas: se a base é razoável, melhorias contínuas resolvem; se um módulo concentra as falhas, refatorar esse módulo costuma bastar. Quando a base não sustenta o negócio, a substituição gradual, com partes novas assumindo funções uma a uma, reduz o risco.

Código de baixa qualidade é um risco de segurança?

Sim, principalmente quando o sistema usa linguagem, framework ou bibliotecas fora de suporte, que deixam de receber correções para falhas descobertas. Código sem revisão e sem testes também facilita erros que expõem dados. Por isso a avaliação de qualidade de código inclui o inventário de dependências, que pesa também nas obrigações de proteção de dados.

Quem deve ser dono do repositório do código-fonte?

A empresa que contratou o sistema. O repositório do código-fonte deve ficar numa conta em nome da empresa, assim como servidores, domínios e credenciais, para que a manutenção não dependa de um desenvolvedor ou fornecedor específico. A cessão dos direitos sobre o código também precisa estar prevista em contrato, com validação do jurídico.

Como a Pervian Tech trabalha qualidade de código

Na Pervian Tech, avaliar a qualidade de um sistema faz parte do trabalho de arquitetura de software. Começamos pelo que o negócio sente, como tempo de mudança, erros recorrentes e dependência de pessoas, e só depois abrimos o código, as dependências e o processo de publicação. O resultado é um mapa em linguagem de negócio, com o que resolver primeiro, o que pode esperar e o que não vale mexer.

Nos projetos que desenvolvemos, revisão de código, testes automatizados nas regras críticas e repositório em nome do cliente são prática padrão, não item opcional. Cada plano é sob medida, porque cada sistema concentra seus problemas em lugares diferentes.

O investimento é definido sob consulta, depois de um diagnóstico inicial gratuito. Se você recebeu ou herdou um sistema e não sabe o que tem nas mãos, conte sua situação.