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

> Cinco sinais que o gestor verifica sem abrir o código, as perguntas certas para a equipe, um checklist pronto e quando vale pedir uma auditoria externa.

Fonte: https://pervian.tech/blog/como-avaliar-qualidade-de-codigo · Pervian Tech · publicado em 2026-10-01

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](https://pervian.tech/blog/divida-tecnica-explicada-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](https://pervian.tech/blog/ci-cd-para-gestores) 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](https://pervian.tech/blog/sistema-lento-diagnostico-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 que você observa | O que costuma indicar |
|---|---|
| Estimativas curtas e cumpridas | Código organizado, com partes bem separadas |
| Estimativas curtas, mas sempre estouradas | Surpresas no código: regras escondidas, efeitos colaterais |
| Estimativas longas para coisas pequenas | A equipe já conhece a fragilidade e embute o risco |
| Estimativa só depois de "investigar" | Ninguém entende bem aquela parte do sistema |
| Mudança pronta, mas demora para ir ao ar | Problema no processo de publicação, não só no código |

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](https://pervian.tech/blog/propriedade-do-codigo-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](https://pervian.tech/blog/sistema-dependente-de-um-programador), 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](https://pervian.tech/blog/node-dotnet-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](https://pervian.tech/blog/assumir-sistema-legado-sem-documentacao).
- 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](https://pervian.tech/blog/reescrever-ou-refatorar-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](https://pervian.tech/blog/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](https://pervian.tech/servicos/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](https://pervian.tech/#contato).