Skip to main content

8 práticas comprovadas de revisão de código para desenvolvedores

Escrito por
blog hero trojan source unicode

14 de janeiro de 2022

0 minutos de leitura

A revisão de código com foco em segurança é o processo de verificar se o código está protegido contra ameaças externas. O código pode conter fragilidades de segurança que comprometem a aplicação ou os blocos de código ao redor. As revisões por pares são um processo manual que complementa os métodos de teste automatizados e oferece uma cobertura de segurança abrangente. Uma revisão segura de código pode identificar fragilidades de segurança e erros na lógica do código relacionados ao funcionamento de uma aplicação. Esse tipo de revisão protege a aplicação contra a perda de dados e de propriedade intelectual, que pode afetar a receita e a reputação da empresa.

Uma das melhores maneiras de melhorar a qualidade e a segurança do software é adotar um processo formal de revisão manual de código. Como podem ocorrer erros durante a escrita do código, contar com novos olhares e conhecimentos complementares pode revelar falhas que o programador original talvez nunca perceba. Além disso, embora qualquer pessoa esteja sujeita a erros, um grupo de especialistas pode detectar bugs ou falhas de segurança no código que as ferramentas automatizadas de revisão talvez não encontrem.

Apesar de todos os benefícios da revisão de código por pares, às vezes é difícil reunir o grupo e realizar a tarefa rapidamente. Para resolver isso, definir práticas de revisão de código ajuda a orientar o processo até o resultado desejado: código seguro e de alta qualidade. Confira oito diretrizes de revisão de código que você pode adotar no processo de desenvolvimento de software da sua empresa.

1. Adicione comentários ao código-fonte durante a criação

A primeira prática é usar comentários não funcionais em trechos do código para explicar aos revisores a intenção por trás de cada bloco. Os comentários ajudam a comunicar por que o desenvolvedor tomou determinada decisão ou fez uma alteração, sem que a equipe de revisão precise adivinhar. Quando bem feitos, eles permitem que revisores experientes compreendam o propósito e a metodologia de toda a sequência de código. Além disso, ter um guia de estilo e aplicá-lo garante que o código seja legível para toda a equipe.

2. Não presuma que algo funciona sem testar

Desenvolver código exige várias iterações de tentativa e erro. O desenvolvedor escreve algumas linhas, compila o código e vê que não funciona. Testar a funcionalidade e o resultado dos novos trechos de código pode reduzir bastante o tempo de revisão mais adiante. Além disso, é muito mais fácil corrigir um trecho pequeno quando se sabe que o restante do código funciona corretamente. Uma abordagem chamada desenvolvimento orientado a testes (TDD) consiste em escrever testes unitários antes de implementar o código. Essa abordagem funciona como uma verificação preliminar de blocos de funções específicos, permitindo que os revisores se concentrem em integrar essas funções ao restante do código.

3. Execute suítes de testes no código proposto

Uma maneira de validar um conjunto específico de procedimentos é usar suítes de testes automatizadas para criar testes unitários para cada bloco de código. A suíte reúne funções conhecidas e avalia o código com base em um resultado positivo esperado. Como outra ferramenta para avaliar o desempenho do código em ações específicas, as suítes de testes aceleram a validação de trechos que executam uma ou mais tarefas definidas pela própria suíte. Uma falha pode indicar ao desenvolvedor uma área específica que precisa de ajustes.

4. Mantenha os pull requests pequenos e com um único objetivo

Pull requests (PRs) são um processo padronizado para solicitar revisões de código por pares. Quando o desenvolvedor conclui a alteração inicial, o PR dá início ao processo de revisão. Para tornar a revisão manual mais eficiente e rápida, o desenvolvedor deve criar PRs com instruções específicas para os revisores. Quanto mais complexo o PR, mais tempo a revisão pode levar, aumentando o risco de o revisor não perceber o objetivo principal. Na verdade, o tamanho ideal de um PR é inferior a 250 linhas, pois os revisores conseguem identificar de 70% a 90% dos defeitos em menos de uma hora.

Comece a participar de desafios de Capture the Flag

Aprenda a resolver desafios de Capture the Flag assistindo sob demanda ao nosso workshop virtual introdutório.

5. Sempre execute verificadores automatizados de código

Antes da revisão por pares, o desenvolvedor pode usar ferramentas de revisão de código, como scanners, verificadores automatizados de código ou analisadores estáticos, para avaliar a qualidade da base de código após as alterações. Essas ferramentas detectam erros evidentes de formatação, como problemas em nomes de funções ou espaçamento. Scanners e linters seguem regras definidas e funcionam como corretores ortográficos para encontrar erros rapidamente. Ao usar essas ferramentas, a equipe elimina esse trabalho da revisão manual por pares e pode se concentrar em erros de estilo ou interpretação.

Por exemplo, ferramentas de revisão de código Java podem encontrar bugs e problemas de segurança no código Java e oferecer recomendações práticas para que os desenvolvedores corrijam tudo rapidamente. Snyk Code oferece recomendações para melhorar a qualidade do código diretamente no seu IDE, proporcionando uma experiência de desenvolvimento sem atritos.

Verificação da qualidade do código em plugins de IDE

O recurso de verificação da qualidade do código da Snyk não estará disponível nas novas versões dos plugins lançadas a partir de 17 de julho de 2025.

6. Revise todo o código e todos os PRs

Como o código é sequencial, os revisores precisam avaliar todo o código e o conjunto de PRs para garantir a coesão. Alterar um trecho pode afetar significativamente as sub-rotinas seguintes. Por isso, a equipe de revisão por pares precisa considerar todo o código e todos os PRs durante a avaliação. PRs maiores e mais substanciais naturalmente recebem mais atenção, mas um erro em um PR pequeno pode ter consequências ainda mais graves do que um conjunto de falhas em um PR extenso.

7. Defina limites para o tempo de revisão e o número de linhas verificadas

Revisar código é um processo demorado e trabalhoso, mas fundamental. Por isso, é essencial limitar o tempo que um revisor ou equipe dedica aos detalhes de cada linha de código. Algumas boas práticas nessa área incluem garantir que os integrantes da equipe não passem mais de uma hora em cada revisão ou limitar o número de linhas revisadas em um determinado período a algumas centenas. Essa abordagem define expectativas para a equipe e garante uma verificação minuciosa do trecho de código relacionado ao PR. Ao organizar as revisões de forma eficiente para toda a equipe, os desenvolvedores recebem feedback valioso e conseguem melhorar rapidamente a qualidade do código.

8. Faça uma revisão de código com foco em segurança

Outra boa prática de revisão é realizar uma revisão segura de código. Enquanto as ferramentas automatizadas verificam erros de espaçamento e nomenclatura e comparam o código com funções padrão conhecidas, as revisões manuais avaliam o estilo, a intenção e o resultado funcional. O terceiro tipo de avaliação é a revisão de código com foco em segurança, que verifica a robustez do código do ponto de vista da segurança.

O código pode conter vulnerabilidades inerentes que comprometem a aplicação ou os blocos de código ao redor. Uma revisão segura de código pode identificar essas vulnerabilidades e também ajudar a encontrar erros na lógica relacionados ao funcionamento da aplicação. O desenvolvedor precisa conseguir escrever código em um ambiente que o proteja contra ataques externos, cujas consequências podem variar do roubo de propriedade intelectual à perda de receita e de dados.

A boa notícia é que já existem ferramentas de teste de segurança de aplicações estáticas (SAST), como Snyk Code, que podem detectar vulnerabilidades antes que elas cheguem à revisão de código ou durante a análise de código. Também existem boas práticas de programação segura que protegem o código-fonte e facilitam uma revisão segura e eficiente. Entre os exemplos estão limitar o acesso ao código, aplicar criptografia robusta e implementar o gerenciamento de segredos para evitar o compartilhamento amplo de senhas e código fixo.

Conclusão: como fazer uma revisão de código

Os desenvolvedores podem continuar refinando e otimizando o código indefinidamente, mas ainda assim talvez não encontrem todos os erros ou falhas de segurança. Com um processo de revisão de código por pares, as equipes de desenvolvimento garantem que o software seja testado adequadamente antes de enviar o código para produção. Combinar a revisão automatizada de código, as etapas de revisão manual por pares e as práticas de revisão segura é a maneira mais eficiente de entregar código seguro e de alta qualidade com rapidez.

Acesse nossa página de Recursos de segurança para conhecer as opções e ferramentas da Snyk que ajudam desenvolvedores a criar código correto e seguro.

Ferramenta gratuita online para verificar código

Proteja seu código antes do próximo commit.

Leia mais

Blog

Modelos de ponta encontraram as vulnerabilidades. Só o atacante encontrou as cadeias.

A análise estática encontrou as falhas, mas só os testes de ataque em aplicações ativas provaram como elas poderiam ser encadeadas para causar invasões. Uma comparação entre Evo COS, Claude Security e Claude Code Security.

feature insights context
Blog

Os ataques autônomos já chegaram. A defesa precisa acompanhar o ritmo.

Os atacantes autônomos estão reduzindo o tempo disponível para a defesa. Saiba como a descoberta, a correção, a validação e a prevenção contínuas ajudam as equipes de segurança a acompanhar esse ritmo.

Blog

Por que agentes de programação com IA continuam criando falhas de controle de acesso

Agentes de programação com IA podem gerar uma lógica de autorização que compila e passa pela revisão, mas permite que um tenant acesse os dados de outro. Saiba por que é difícil detectar falhas de controle de acesso e como evitá-las.