Code Review é a melhor alternativa logo após o pair-programming ou mob-programming.
É um processo importante que ajuda a diminuir o custo do desenvolvimento de forma significativa.
Neste artigo trago pontos importantes e como o Code Review diminui o custo de desenvolvimento.
Por que fazer Code Review?#
Queremos desenvolver com qualidade e queremos entregar valor para o cliente.
Mas para isso precisamos de feedbacks.
Precisamos do feedback dos clientes e dos usuários para saber se estamos construindo o produto certo. Podemos fazer isso com monitoramento, NPS e outros tipos de ferramentas.
Precisamos ter feedback sobre características funcionais e não funcionais do produto. Precisamos saber se o desempenho está de acordo com o esperado, se não existe bugs em casos extremos e caminhos felizes. Podemos fazer isso com testes automatizados.
Mas e sobre a legibilidade do código? Sobre o uso ou não de patterns? Sobre acoplamento e coesão?
Este tipo de feedback só pode vir de um outro colega desenvolvedor.
Sabemos que legibilidade, acoplamento e coesão são alguns dos fatores que aumentam drasticamente o custo de desenvolvimento:
- Legibilidade: Quanto mais fácil, menor o custo
- Acoplamento: Quanto menor, menor o custo
- Coesão: Quanto maior, menor o custo
Design Patterns ajudam o código a ter um baixo acoplamento e alta coesão.
Estilos e padrões de codificação ajudam na melhora da legibilidade: Eles diminuem a carga cognitiva facilitando a aprendizagem e a navegação do código.
E Code Review é perfeito para isso, além de ter outros benefícios
Benefícios para o autor do código#
Uma outra cabeça para opinar#
Duas cabeças pensam melhor que uma. Pode ser que exista uma solução melhor para o problema proposto.
Começa a pensar no leitor do código#
Você começa a pensar em escrever para os outros e principalmente para você do futuro.
Já aconteceu comigo. Eu quis parecer inteligente e escrevi um código de uma linha que resolvia o problema.
Depois de uma semana, tive que mexer na mesma linha e não entendi nada.
Não escreva código inteligente, escreva código simples. E código simples não é fácil de escrever.
Aprendendo com o revisor#
Você tem muito mais oportunidade de aprender quando revisam o seu código. Aprende novos métodos, funções e padrões que facilitam a vida de todos da equipe.
Benefícios para o revisor do código#
Ajuda os outros a aprenderem#
Quando você ajuda o par com o seu conhecimento, a eficiência e o conhecimento interno do time aumenta.
Com certeza, o próximo trabalho do autor do código será melhor.
Oportunidade de aprender#
Essa dica é principalmente para os líderes técnicos e seniores. Tenha certeza que você vai aprender algo. Mesmo que seja um código do estagiário ou de júnior.
Aconteceu comigo inúmeras vezes.
Fique com a mentalidade aberta e dê a você mesmo a oportunidade de aprender com o código dos outros!
Familiaridade com o código#
Ficamos mais familiarizados e contextualizados sobre o código feito pelos outros. Já trabalhei em equipe onde todos eram capazes de mexer e revisar código feito em C#, Java, Groovy, Javascript por causa do Code Review.
Benefícios para o time#
Refatoração para diminuir o custo de desenvolvimento#
Se o processo de Code Review é bem feito e bem aceito, refatoração acontece com natureza ajudando a minimizar o impacto da alteração de código a longo prazo.
Responsabilidade compartilhada#
Trechos do código não se tornam responsabilidades de uma pessoa mas da equipe.
Reduz o “Single Point Of Failure”#
Tem alguém no seu time que se ele parar de trabalhar hoje na sua equipe, cria um buraco de conhecimento sobre alguma parte do seu projeto?
Quando o Code Review é bem feito, o conhecimento de tudo que é feito no time é compartilhado e evita esta situação.
Quando revisar o código?#
Além dos benefícios, devemos saber quando o código está pronto para ser revisado.
Então, antes de revisar o código, o processo deve garantir que:
- O código compila
- O código passou pelos testes automatizados
- O código passou pelo lint
- O código passou por requisitos de qualidade (Ex: Code Coverage, Complexidade Cognitiva, Issues de Segurança e etc)
Se um dos pontos acima falhar, o desenvolvedor deve alterar o código, logo não vale a pena fazer o code review.
Dicas para Code Review#
Primeira coisa importante: Code Review é um processo técnico mas social também.
Você não está revisando código. Você está revisando o trabalho de alguém.
Então seja construtivo na comunicação.
Não diga o que está ruim. Mas diga o que pode ser melhor, como e por que.#
Em vez de escrever:
Escreva:
Lembre-se, é um trabalho de alguém.
O problema é sempre nosso e não só do autor#
Não use “Você” mas sempre use “Nós”. Faça parte do problema e da solução.
Em vez de escrever:
Escreva:
Crie um ambiente seguro para honestidade#
Você pode pedir opiniões também no Code Review.
Em vez de escrever:
Escreva:
Ou você também pode errar na sugestão. Nestas situações peça uma desculpa sincera.
Escreva:
Se encontrar algo bom, elogie!#
Você não é o caçador de coisas ruins no código dos outros.
Elogie algo inesperado.
Escreva:
Outras dicas#
- Crie uma cultura onde o time é capaz de criar commits pequenos. Mostre pouco código e terá bastante feedback. Mostre muito código e tenha pouco feedback.
- Não espere a feature inteira ficar completa. Você pode pedir um Code Review cedo.
- Se os desenvolvedores estão realmente pedindo por um Code Review, este é um sinal de que está indo bem.
- Quando começar com Code Review, comece pelos testes. Normalmente, é possível entender a história e o andamento do commit do autor só pelos testes.
Conclusão#
Code Review não se trata apenas de encontrar bugs ou validar padrões: é um mecanismo de redução de custos que atua diretamente em fatores críticos como legibilidade, acoplamento e coesão do código.
Para autores, é uma oportunidade de escrever código mais claro e aprender com pares. Para revisores, uma chance de ampliar conhecimento e fortalecer a coesão do time. Para o projeto, significa sistemas mais resilientes, com responsabilidade compartilhada e menos riscos de single point of failure.
No fim, o resultado é simples: código que custa menos para evoluir e equipes que aprendem enquanto constroem.
O que você achou do artigo?
Comentem e venham falar comigo!
🥒🥒 Espero que tenham curtido e até o próximo artigo! 🥒🥒