A revisão do código é uma atividade de garantia de qualidade de software na qual uma ou várias pessoas verificam um programa, principalmente ao visualizar e ler partes de seu código-fonte, e o fazem após a implementação ou como uma interrupção da implementação. Pelo menos uma das pessoas não deve ser o autor do código.
A atividade de Code Review é muito importante para verificar a qualidade do código produzido e é através dela que é possível identificar problemas, antes mesmo de um projeto ser implantado em produção, e assim, evitar retrabalhos, análise de logs, identificação de bugs, etc.
A recomendação é que o Code Review seja realizado por alguém experiente e que tenha uma boa visão arquitetural, além também ter um bom entendimento sobre requisitos não funcionais.
Abaixo está disponível um checklist modelo que pode ser utilizado no Code Review. Lembrando que é um modelo e poder ser ajustada ou melhorada conforme a necessidade.
Fique a vontade para reportar algum problema ou sugestão!
Índice
- Compartilhamento de conhecimento e aprendizado em equipe
- Soluções alternativas e melhorias no código
- Conhecimento compartilhado e menos dependência de um único membro da equipe
- Disciplina na discussão do código e entrega de qualidade
- O que os revisores de código procuram?
- Exemplo de Checklist | Code Review
- Conclusão
Compartilhamento de conhecimento e aprendizado em equipe
Um dos principais benefícios do Code Review é o compartilhamento de conhecimento entre os membros da equipe de desenvolvimento. Muitas vezes, o time não tem tempo para escrever artigos ou compartilhar exemplos de uso de tecnologias e melhorias no código. Nesse sentido, o Code Review se torna uma excelente oportunidade para que todos possam aprender e ensinar uns aos outros.
Por exemplo, ao revisar o código de um colega, é possível perguntar sobre a utilização de um determinado padrão de projeto e aprender mais sobre ele. Além disso, as sugestões e dúvidas levantadas durante o processo de revisão enriquecem o conhecimento de todos os envolvidos.
Soluções alternativas e melhorias no código
O Code Review é uma excelente oportunidade para identificar soluções alternativas e melhorias no código. Quando mais de uma pessoa revisa o código, é possível ter diferentes pontos de vista e opiniões sobre a implementação. Dessa forma, surgem sugestões e alternativas que podem tornar o código mais eficiente e fácil de manter.
Por exemplo, um revisor pode sugerir uma forma diferente de implementar um recurso ou melhorar a legibilidade do código. Essas sugestões podem contribuir para a melhoria do produto final e para o aprendizado da equipe.
Conhecimento compartilhado e menos dependência de um único membro da equipe
Outro benefício do Code Review é que ele ajuda a compartilhar o conhecimento do código do sistema entre todos os membros da equipe. Isso é especialmente importante para evitar a dependência de um único membro da equipe.
Por exemplo, se apenas uma pessoa sabe como determinado trecho de código funciona, isso pode se tornar um problema caso essa pessoa saia da equipe ou fique indisponível por algum motivo. Ao compartilhar o conhecimento do código através do Code Review, todos os membros da equipe entendem melhor o sistema na totalidade.
Disciplina na discussão do código e entrega de qualidade
Por fim, o Code Review ajuda a estabelecer uma cultura de disciplina na discussão do código da equipe. Com o tempo, a revisão de código se torna um hábito natural e um processo importante para a entrega de um software de qualidade. Além disso, o Code Review contribui para o desenvolvimento de um senso crítico e uma cultura de colaboração na equipe de desenvolvimento.
O que os revisores de código procuram?
As revisões de código devem observar:
- Design: O código é bem projetado e apropriado para o seu sistema?
- Funcionalidade: O código se comporta como o autor provavelmente pretendia? A maneira como o código se comporta é boa para seus usuários?
- Complexidade: O código poderia ser simplificado? Outro desenvolvedor seria capaz de enteder e usar facilmente esse código quando se deparar com ele no futuro?
- Testes: O código possui testes automatizados corretos e bem desenhados?
- Nomeação: O desenvolvedor escolheu nomes claros para variáveis, classes, métodos, etc?
- Comentários: Os comentários são claros e úteis?
- Estilo: O código segue nossos guias de estilo?
- Documentação: O desenvolvedor também atualizou a documentação relevante?
Exemplo de Checklist | Code Review
Etapas
- Baixar o código e executar os testes localmente;
- Rodar a build do repositório;
- Analisar a cobertura de testes, bugs, code smells, códigos duplicados, segurança;
- Executar os testes automatizados;
- Validar o checklist da próxima sessão.
Checklist
Geral (Back & Front):
- Os nomes (constantes, variáveis, parâmetros, métodos, classes, pacotes, etc.) estão claros e revelam a sua intenção?
- As classes/funções estão pequenas e estão seguindo o princípio de Single-Responsability
- A duplicidade de código foi evitada?
- Quando necessário, existem comentários no código?
- O código está formatado corretamente?
- Códigos incompletos, sem uso ou mesmo comentados, foram removidos?
- Atributos sem uso ou mesmo comentados, foram removidos?
- Importações sem uso ou mesmo comentadas, foram removidos?
- Todos os commits tem uma referência de uma tarefa na descrição?
- As nomenclaturas seguem o padrão definido?
- A build está sendo executado sem erros e Inclusive Testes?
- O código subiu sem erros para o ambientes?
- Não foi encontrado indentação/reposicionamento em trechos do código que não necessitavam ser alterados?
- A nomenclatura dos testes segue o padrão de Behaviour Driven Development? ( Dado / Quando / Então )
- A documentação técnica da Jornada foi atualizada?
- Checklist de segurança
- O log está no NÍVEL correto (INFO)?
- Verificar se os microservices estão com tracing;
- Verificar se os commits estão com o número da tarefa no comentário;
- A execução do sonar para a review em questão está Ok?
- As urls dos ambiente estão corretas em casos de integração, config-maps?
Back-End Java:
- Existe um teste unitário que representa a classe? (Não aplicado a classes de configurações e entidades de domínio)
- A confidencialidade das informações logadas estão sendo respeitadas?
- Todos os atributos fixos estão nas declarações como constantes finais estáticas? (Não devem existir valores mágicos no código)
- Todos os testes comitados estão sem o @Ignore?
- A cobertura de testes para o código comitado esta acima dos 90%?
- Validar o Swagger
- O componente estrutural de exceções está sendo utilizado e a pilha de exceções está sendo tratada do modo correto (não deve ocultar exceções)?
- O catálogo de microsserviços foi atualizado?
Front-End:
- Os elementos de tela relevantes aos testes automatizados possuem IDs ou identificadores CSS que possibilitem sua captura?
- A quebra de componentes está feita de maneira correta?
- Os componentes estão sendo testados por simulação de interações com o html a fim de validar a real funcionalidade do componente?
- Teste unitários estão rodando sem erro?
- Build está rodando sem erro?
- Rodou o ambiente local e conferiu se as novas implementações estão funcionando?
- Foi verificado o documento de especificações do layout disponibilizado pelo time de UX?
- Foi verificado o documento de acessibilidade disponibilizado pelo time responsável?
Conclusão
Enfim, pessoal, esse processo tem muito o que nos ensinar ainda, acredito que com ele podemos alcançar novos lugares no quesito qualidade de software e conhecimento como um todo. Sempre que possível, use ferramentas para analisar código, como os linters por exemplo. Acredito que a junção do lado automatizado com o lado humano do processo de code review é a chave para o sucesso.
Em resumo, o Code Review é muito mais do que uma simples revisão do código. Ele pode ajudar a promover a colaboração e o compartilhamento de conhecimento entre os membros da equipe, aumentar a qualidade do código e contribuir para uma cultura de disciplina e excelência no desenvolvimento de software.!
Você precisa fazer login para comentar.