Revisão de código
A revisão de código ou revisão por pares de código é uma prática de engenharia de software na qual uma ou mais pessoas, diferentes do autor de uma alteração, examinam o código-fonte com o objetivo de avaliar sua qualidade antes ou durante sua integração a uma base de código.[1]
Durante a revisão, podem ser identificados defeitos, problemas de projeto, complexidade desnecessária, inconsistências, ausência ou inadequação de testes e documentação, além de oportunidades para melhorar a legibilidade e a manutenibilidade do código.[2]
Embora a identificação de defeitos seja uma das principais motivações para a revisão, estudos empíricos mostram que a prática também favorece a transferência de conhecimento entre desenvolvedores, a compreensão das alterações realizadas no sistema, a consciência da equipe sobre a evolução do código e a discussão de soluções alternativas.[1]
Objetivos
[editar | editar código]Os objetivos específicos de uma revisão dependem do projeto e de suas práticas de desenvolvimento. Entre os aspectos que podem ser examinados estão:[2]
- projeto: verificar se a solução adotada é adequada à arquitetura e ao restante do sistema;
- funcionalidade: avaliar se o código realiza corretamente o comportamento pretendido;
- complexidade: identificar implementações desnecessariamente complexas ou difíceis de compreender e manter;
- testes: verificar a existência e a adequação dos testes automatizados relacionados à alteração;
- nomenclatura: avaliar a clareza dos nomes utilizados em variáveis, funções, métodos, classes e outros elementos;
- comentários e documentação: verificar se são necessários, claros e compatíveis com a implementação;
- estilo e consistência: avaliar a conformidade com as convenções adotadas pelo projeto.
Além desses aspectos, a revisão pode identificar defeitos e estimular o compartilhamento de conhecimento entre autores e revisores.[1]
Processo
[editar | editar código]Na revisão de código moderna, o processo normalmente ocorre sobre uma alteração ou conjunto de alterações proposto pelo autor. Ferramentas de revisão apresentam aos participantes os arquivos modificados e as diferenças entre a versão existente e a nova versão.[3]
Um fluxo típico é composto pelas seguintes etapas:
- o autor prepara uma alteração e a envia para revisão;
- um ou mais revisores examinam o código e podem registrar comentários, dúvidas ou solicitações de mudança;
- o autor responde aos comentários e, quando necessário, modifica o código;
- uma nova versão da alteração pode ser submetida para outra rodada de análise;
- quando os critérios definidos pelo projeto são satisfeitos, os revisores aprovam a alteração, permitindo sua integração à base de código.[3]
O processo pode conter diversas iterações entre autor e revisores até que a alteração seja considerada adequada.[3]
História e formas de revisão
[editar | editar código]Inspeções formais
[editar | editar código]Uma das primeiras metodologias sistemáticas de revisão de código foi desenvolvida por Michael E. Fagan, da IBM, e publicada em 1976. O processo, conhecido posteriormente como inspeção de Fagan, estabelecia uma forma estruturada de verificar projetos e código, com etapas e papéis definidos para os participantes.[4]
As inspeções formais podem envolver preparação prévia, reuniões estruturadas, registro dos defeitos encontrados e verificação posterior das correções.[4]
Revisão de código moderna
[editar | editar código]Com a evolução das ferramentas de desenvolvimento colaborativo, difundiram-se processos menos formais, frequentemente chamados de revisão de código moderna ou revisão contemporânea. Em comparação com as inspeções tradicionais, essas práticas tendem a ser mais leves, frequentes e apoiadas por sistemas próprios de revisão de alterações.[1][3]
Essas ferramentas permitem visualizar as diferenças entre versões, associar comentários diretamente a trechos de código, acompanhar discussões e revisar sucessivas iterações da mesma alteração.[3]
A revisão pode ser realizada de forma assíncrona, sem a necessidade de autor e revisores estarem presentes simultaneamente, ou de forma síncrona, incluindo reuniões e sessões presenciais.
Benefícios
[editar | editar código]A detecção de defeitos é uma motivação tradicional da revisão de código, mas não constitui seu único resultado. Em um estudo conduzido em equipes da Microsoft, Alberto Bacchelli e Christian Bird observaram benefícios adicionais, entre eles transferência de conhecimento, maior consciência da equipe sobre mudanças no código e identificação de soluções alternativas para problemas.[1]
A revisão também pode contribuir para a manutenção de convenções e padrões de qualidade compartilhados. Nas diretrizes de engenharia do Google, por exemplo, o objetivo central da revisão é impedir que sucessivas alterações reduzam a qualidade geral da base de código ao longo do tempo.[5]
A interação entre autor e revisor também pode desempenhar uma função educativa, permitindo a disseminação de conhecimento sobre linguagens, frameworks, arquitetura do sistema e práticas adotadas pela equipe.[5]
Efetividade e tamanho das alterações
[editar | editar código]A efetividade de uma revisão depende de fatores relacionados aos revisores, ao contexto e à própria alteração analisada.
Em um estudo que examinou aproximadamente 1,5 milhão de comentários de revisão em cinco projetos da Microsoft, Bosu, Greiler e Bird observaram que, quanto maior o número de arquivos presentes em uma alteração, menor era a proporção de comentários que os autores consideravam úteis.[3]
Por essa razão, práticas de engenharia frequentemente recomendam que alterações submetidas à revisão sejam pequenas e concentradas em um objetivo específico, desde que continuem suficientemente completas para que seu efeito possa ser compreendido.[6]
A revisão também possui custos: exige tempo dos revisores, do autor para responder e implementar alterações e pode adicionar espera ao fluxo de desenvolvimento. Por isso, processos e ferramentas buscam equilibrar profundidade da análise e velocidade de integração das mudanças.[3]
Relação com outras práticas
[editar | editar código]Análise estática
[editar | editar código]A análise estática de programas examina o código sem executar o programa e pode automatizar a identificação de determinados padrões, erros e violações de regras.
Ela pode complementar a revisão humana. Verificações automatizáveis, como determinadas regras de estilo ou padrões detectáveis por análise estática, podem ser realizadas por ferramentas, enquanto revisores humanos podem concentrar-se em questões de projeto, contexto, legibilidade e adequação da solução.[7]
Programação em par
[editar | editar código]Na programação em par, dois desenvolvedores trabalham conjuntamente na produção do código, geralmente com revisão contínua das decisões tomadas durante sua implementação. A prática difere da revisão assíncrona realizada após a preparação de uma alteração, embora possa desempenhar uma função semelhante de verificação por outra pessoa.
A forma como as duas práticas se relacionam depende do processo da organização. Nas práticas de engenharia publicadas pelo Google, por exemplo, código desenvolvido em programação em par é considerado revisado quando o segundo participante possui qualificação adequada para realizar a revisão.[8]
Ver também
[editar | editar código]Referências
- 1 2 3 4 5 Bacchelli, Alberto; Bird, Christian (2013). «Expectations, Outcomes, and Challenges of Modern Code Review». Proceedings of the 35th International Conference on Software Engineering (em inglês). [S.l.]: IEEE. pp. 712–721. ISBN 978-1-4673-3076-3. doi:10.1109/ICSE.2013.6606617
- 1 2 «What to look for in a code review». Google Engineering Practices Documentation (em inglês). Google. Consultado em 14 de agosto de 2026. Cópia arquivada em 10 de agosto de 2026
- 1 2 3 4 5 6 7 Bosu, Amiangshu; Greiler, Michaela; Bird, Christian (2015). «Characteristics of Useful Code Reviews: An Empirical Study at Microsoft». 2015 IEEE/ACM 12th Working Conference on Mining Software Repositories (em inglês). [S.l.]: IEEE. pp. 146–156
- 1 2 Fagan, Michael E. (1976). «Design and Code Inspections to Reduce Errors in Program Development». IBM Systems Journal (em inglês). 15 (3): 182–211. doi:10.1147/sj.153.0182
- 1 2 «The Standard of Code Review». Google Engineering Practices Documentation (em inglês). Google. Consultado em 14 de agosto de 2026. Cópia arquivada em 2 de agosto de 2026
- ↑ «Small CLs». Google Engineering Practices Documentation (em inglês). Google. Consultado em 14 de agosto de 2026. Cópia arquivada em 10 de agosto de 2026
- ↑ Czerwonka, Jacek; Greiler, Michaela; Tilford, Jack (2015). «Code Reviews Do Not Find Bugs» (PDF) (em inglês). Microsoft. Consultado em 14 de agosto de 2026. Cópia arquivada (PDF) em 27 de maio de 2026
- ↑ «Google's Code Review Guidelines». Google Engineering Practices Documentation (em inglês). Google. Consultado em 14 de agosto de 2026. Cópia arquivada em 13 de agosto de 2026