Saiba o que é revisão de código, porque ela é uma prática importante em times de desenvolvimento de software, como revisar do jeito certo e também as melhores práticas para você dominar a revisão nos projetos em que trabalha.
Em resumo:
- O que é code review ou revisão de código?
- Quais são os benefícios?
- O processo de revisão de código
- Boas práticas para não estressar o time e revisar tudo de boa
O que é code review?
Antes de mais nada, é preciso que você tenha ao menos uma noção básica sobre controle de versão e sobre o fluxo de trabalho normal no dia a dia de um desenvolvedor.
Esse fluxo, simplificando bastante, seria mais ou menos assim:
- Você recebe uma tarefa. Pode ser consertar um bug, mudar o layout de uma tela ou alguma coisa assim.
- Depois de entender o que precisa ser feito você faz as alterações no código fonte, nos arquivos de configuração, na documentação e tudo que precisar ser versionado.
- E por último você submete esse código para ser integrado com o restante do software, geralmente passando por um pull request.
Pull request é o conjunto das alterações que você está submetendo, podendo passar por aprovação do time.
Então o que é revisão de código?
Revisão de código é a prática de submeter seu código fonte para revisão e aprovação por outros membros do time de desenvolvimento antes que ele seja mesclado com o código principal.
Já trabalhei em empresas que não faziam o review e também já trabalhei com projetos em que isso é obrigatório.
Agora eu vou te mostrar como você também tirar os melhores benefícios das revisões de código no seu dia a dia.
Qual a importância de revisar o código?
São vários os motivos para um time de desenvolvimento querer fazer code review. Vou citar os que eu considero mais importantes.
Corrigir erros e garantir que os requisitos sejam atendidos
Sabe aquelas situações onde você não consegue enxergar onde está o erro no seu código e aí vem outra pessoa e na mesma hora consegue apontar o problema?
Pois é. Às vezes a gente comete erros no código, principalmente erros de lógica, e não percebe.
Então quanto mais pessoas revisarem o seu código, maiores as chances de alguém achar alguma coisa que pode dar errado. E isso é bom, porque aí você tem a chance de corrigir cedo.
Além disso, é preciso ter certeza de que a implementação atende aos requisitos. Em outras palavras, que ela resolve o problema corretamente.
Garantir padrões de desenvolvimento
Todo time deveria seguir alguns padrões como formatação de código, nomenclatura de classes e métodos, ou organização dos arquivos no projeto, por exemplo. Isso vale até para padrões de projeto, padrões arquiteturais e coisas desse tipo.
A revisão de código é uma ótima oportunidade para rever se esses padrões estão sendo aplicados.
Prevenir problemas de segurança
Todo mundo sabe que não se pode salvar senhas, chaves de APIs e outras informações confidenciais nos arquivos que são versionados num projeto de software.
Existem várias ferramentas para automatizar esse escaneamento, mas isso não quer dizer que você não possa descobrir problemas de segurança como esses manualmente.
Quem nunca copiou e colou alguma coisa e esqueceu de alterar?
Já vi uma situação em que encontraram no código HTML de uma aplicação dados de usuários que provavelmente foram usados para testes e não foram removidos.
Nada gravíssimo mas é uma coisa que tem que ser evitada. Bem, nesse caso a revisão não evitou o problema mas ela é a melhor hora para detectar esse tipo de coisa.
Melhorar a qualidade do software
Tudo isso que eu citei até agora é para melhorar o código, sem dúvida. Mas agora eu me refiro a tornar o código mais simples, mais legível ou com um desempenho melhor.
Seu código pode estar todo correto do ponto de vista da sintaxe ou da lógica, mas pode não ser fácil de entender, ou pode estar fazendo mais do que o necessário.
E sempre tem um jeito melhor de resolver um problema. Às vezes o que falta são diferentes pontos de vista sobre aquele mesmo problema.
Por isso a revisão de código é uma ferramenta tão importante para a qualidade de software.
Aprendizado
Desenvolver software vai muito além do código. Disso você pode ter certeza. E também é uma coisa que você não aprende só lendo ou assistindo aulas, você tem que fazer.
Mas ler código dos outros também é uma habilidade importantíssima a ser desenvolvida. Porque fazendo isso você tem contato com um jeito diferente de pensar e de resolver problemas.
Imagine que oportunidade para um desenvolvedor menos experiente seria revisar o código dos colegas veteranos ou ter seu código revisado por eles!
Se você estiver nessa situação e não se sentir seguro para sugerir alterações, pelo menos aproveite a chance de ver como os outros fizeram e aprender com isso.
Então tem duas oportunidades de aprendizado aí: primeiro, quando outros revisam o seu código e sugerem mudanças e, segundo, quando você revisa o código dos outros e entende como eles fizeram.
O processo de revisão de código
Não sei se posso falar num processo nesse caso mas, seria ótimo se a revisão de código se tornasse parte do processo de desenvolvimento de software, um hábito diário.
O que vem a seguir foi o que eu aprendi fazendo code review enquanto trabalhei com um time gringo de um altíssimo nível técnico numa aplicação usada a nível global.
O processo seria: revisar, discutir, melhorar e aprovar.
Pode ser um processo iterativo mas é bom que ele não se repita indefinidamente. Na verdade, quanto menos iterações, melhor. O desenvolvedor fica feliz quando o código é aprovado bem rápido.
1. Revisar
Analisar não só o código mas também o contexto que deu origem a ele e o resultado que ele produz, que é o que interessa.
Para quem faz ou já fez programação em par, seria uma boa coisa a se fazer: o colega que está ali do seu lado revisar seu código e dar sugestões.
Mas em tempos de trabalho remoto, a gente tem muitas ferramentas para fazer isso. Por exemplo, o próprio GitHub facilita isso e o GitLab também.
Também é bom que pelo menos duas pessoas revisem o código de um colega, mas não é absolutamente necessário.
2. Discutir
Quem estiver revisando o código deve sempre dar um feedback construtivo. Pode ser uma sugestão de mudança, um questionamento ou até mesmo um reconhecimento por algo que foi bem feito.
Às vezes, vale a pena iniciar uma conversa para tirar dúvidas, ou fazer uma demonstração. Na maioria das vezes, isso não é nem necessário.
É importante aproveitar esse momento para tirar todas as dúvidas.
3. Melhorar
Se o código realmente precisar ser corrigido, isso vai ser feito e submetido novamente para aprovação.
4. Aprovar
Somente depois que todas as pendências forem resolvidas é que o código estará pronto para ser mesclado.
Em algumas ferramentas como o GitLab, cada comentário durante a revisão cria uma thread, ou seja, uma discussão que fica pendente até que alguém a resolva.
Uma boa prática é que quem sugeriu as alterações revise novamente e veja se as mudanças foram satisfatórias.
Você comentou, você mesmo revisa de novo, resolve a thread e aprova, se for o caso.
O pull request pode estar ligado a uma pipeline de integração contínua. Se os testes automatizados e outras verificações que rodam na pipeline não passarem, pode ser sinal de que tem algo errado.
Por isso o resultado dos testes já é algo a se considerar antes de dar a aprovação.
Por fim, estando tudo certo, o código pode ser mesclado.
Como submeter seu código para revisão – boas práticas
Algumas dicas do ponto de vista de quem vai submeter o código para revisão.
Para isso também não tem regras específicas mas eu vou mostrar algumas boas práticas para ajudar a melhorar a revisão como um todo, baseado na minha experiência.
1. Seja o primeiro a revisar seu próprio código
Uma regra de ouro da revisão de código é a seguinte: o revisor não deve ser a mesma pessoa que escreveu o código.
Mas, antes de submeter suas alterações para revisão, não custa nada conferir se está tudo certo, fazer um double check.
Por exemplo, veja se não ficou algum comentário desnecessário; ou algum trecho de código que você usou só para debugar. Enfim, coisas que você não precisa incluir no seu commit.
Também não esqueça de rodar os testes unitários.
Acontece que, na pressa de entregar a nossa solução, a gente costuma deixar uns detalhes para trás.
Mas não se preocupe. A revisão serve justamente para apontar esses detalhes, entre outras coisas.
2. Forneça evidências
Essa é uma prática que nem todos os times adotam. É como uma documentação para ajudar na revisão.
Podem ser prints da tela mostrando que a sua implementação funciona ou comparando o antes e o depois.
Ou podem ser logs, resultados dos testes, ou qualquer coisa que sirva como “prova” de que o seu código funciona. Isso vai facilitar a vida de quem for revisar.
Em alguns casos, fornecer dados de teste também pode ser útil.
Com isso você ganha pelo menos dois benefícios: além de mostrar que a implementação realmente funciona, as evidências podem servir para mostrar como testar ou reproduzir um caso de uso.
3. Poucas alterações de cada vez, por favor
Nada pior do que revisar dezenas de arquivos de uma vez. Se for preciso, divida o pull request em partes.
Ter um monte de arquivos para revisar de uma vez só aumenta as chances de alguma coisa importante passar despercebida.
Revisão automatizada
Tem muitas ferramentas de revisão de código que fazem uma análise automática e dão dicas de onde ele pode ser melhorado.
Sem entrar muito em detalhes de ferramentas específicas, eu diria que você e seu time não deveriam deixar de lado a revisão manual por um motivo muito simples:
As ferramentas que existem por aí fazem uma análise estática do código, analisam o conteúdo dos arquivos.
Dá até para prever quando vai acontecer um loop infinito ou se algum trecho de código nunca vai ser executado.
Mas essas ferramentas não conseguem analisar tão bem quanto um humano o contexto em que esse código foi escrito e vai ser executado.
A melhor coisa então seria fazer a revisão manual junto com a automatizada.
Não existe bala de prata
Para finalizar eu queria dizer que não existe bala de prata. Não existe solução que resolva todos os problemas.
Se quem revisa o código não estiver preocupado com a qualidade do software, não adianta.
Se as revisões ficarem se acumulando porque o time não tem interesse ou não tem tempo para revisar o código dos colegas, isso pode atrasar as entregas.
E mesmo revisando tudo com muito cuidado, algum erro pode acabar passando despercebido.
Mesmo assim, a revisão de código é uma prática que pode ajudar muito um time de desenvolvedores a compartilhar conhecimento entre si e melhorar a qualidade do software.
Não deixe de conferir o Release podcast no Spotify.
Evandro da Silva Amparo 