Introdução
Uma frase que me faz refletir sobre o processo de Code Review e sua importância é a seguinte:
"Os olhos veem tudo, só não veem os próprios olhos" Autor desconhecido.
E a justificativa é simples: ao desenvolvermos um código, estamos acostumados com aquilo que foi desenvolvido e, muitas vezes, podemos deixar passar coisas. No entanto, ao receber o olhar / feedback de outra pessoa, passaremos a enxergar coisas que não tínhamos visto antes e, dessa forma, podemos melhorar o que foi feito.
Esse artigo traz reflexões e recomendações que podem auxiliar no processo de Code Review, baseado na minha experiência de mais de 7 anos como desenvolvedora. Além disso, também apresento nesse artigo dicas de ferramentas que podem otimizar a revisão de código, de forma que o tempo do desenvolvedor, como revisor, seja mais direcionado ao que importa no processo: revisar o código.
Responsabilidades no Processo de Code Review
Existem 2 tipos de personagens bem definidos no processo de revisão de código: o do autor e o do revisor. Todos nós, como desenvolvedores, atuamos diariamente como um desses personagens e, nas duas seções a seguir, destaco algumas responsabilidades que devemos ter ao estar em cada papel.
Responsabilidades do Autor
Ao submeter um código para revisão é importante que tenhamos segurança do que estamos enviando e que sigamos o processo da melhor forma possível. Para isso, é interessante estarmos atentos às seguintes responsabilidades:
Revisar
O primeiro revisor do seu código é você mesmo. Então, antes de deixar o código disponível para revisão de outras pessoas, é importante que você mesmo, como autor, faça uma análise do que está enviando para garantir que não esqueceu de nada ou até mesmo aplicar melhorias.
Detalhar
Fornecer o máximo de informações a respeito do código que está sendo enviado para revisão. Para isso, é interessante adicionar uma descrição detalhando quais os requisitos que o Pull Request visa atender, além, claro, de adicionar evidências do funcionamento do seu projeto com a mudança.
No caso de bugs, é interessante adicionar evidências do antes e depois, ou seja, como estava antes, com o bug, e como ficou após a correção.
Estar aberto às sugestões
Ao enviar o código para revisão, esteja aberto às sugestões dos seus companheiros. Afinal, é sobre o código, não sobre você.
Incluir os revisores adequados
Se possível, inclua revisores que tenham conhecimento do contexto do código que você está alterando. Isso pode ajudar na validação das regras de negócio do seu fluxo.
Se comunicar de forma clara e respeitosa
Seja para pedir mais informações sobre um feedback, responder perguntas ou para justificar certas decisões de código.
Responsabilidades do Revisor
Ao revisar um código, também somos responsáveis por uma série de etapas para executar o processo de revisão da melhor forma possível, como, por exemplo:
Fornecer feedback construtivo
Ao fornecer o feedback da revisão, isso deve ser feito de forma respeitosa e construtiva. Devemos nos atentar às palavras que utilizamos e lembrar que o foco é avaliar o código e se os requisitos foram atendidos.
Justificar
É importante justificar por quê o código ficaria melhor com a sugestão, pois a outra pessoa talvez não entenda o contexto e sua visão de melhoria.
Focar em questões centrais
O foco deve ser avaliar se o código está de acordo com os padrões do projeto, se a lógica faz sentido e se os requisitos foram atendidos, não avaliar se suas preferências pessoais foram atendidas. Cada pessoa possui uma forma de implementar suas soluções lógicas e isso deve ser respeitado também.
Separar um tempo
É importante separar um tempo para revisar código, para que a revisão seja feita de forma adequada, com calma, e em um tempo aceitável, de forma que não prejudique o tempo de trabalho da pessoa que está submetendo o código para revisão.
Benefícios da Revisão Contínua
Na imagem abaixo destaco alguns benefícios que a revisão contínua de código proporciona:
Ferramentas para Otimizar o Code Review
Em todo o processo de Code Review, existem certas ferramentas que podem ser utilizadas de forma que o tempo nesse processo seja otimizado. Afinal, existem algumas etapas que podem ser um pouco repetitivas e, para resolver isso, podemos usar a tecnologia ao nosso favor para automatizá-las.
Nas seções a seguir são apresentados casos de uso de duas ferramentas que podem ajudar na automação de processos: Github Actions e Github + Slack.
Caso você não utilize Github, nem Slack, não se preocupe. O objetivo é apresentar propostas de automação de processos para otimizar o tempo na revisão de código, então o conceito pode ser adaptado para as tecnologias de acordo com seu contexto.
Github Actions
O que é Github Actions?
De acordo com a definição do próprio Github:
GitHub Actions é uma plataforma de integração contínua e entrega contínua (CI/CD) que permite automatizar a sua compilação, testar e pipeline de implantação. É possível criar fluxos de trabalho que criam e testam cada pull request no seu repositório, ou implantar pull requests mesclados em produção. GitHub Actions vai além de apenas DevOps e permite que você execute fluxos de trabalho quando outros eventos ocorrerem no seu repositório. Por exemplo, você pode executar um fluxo de trabalho para adicionar automaticamente as etiquetas apropriadas sempre que alguém cria um novo problema no repositório.
Ou seja, através do Github Actions, que é uma plataforma de CI/CD, também é possível criar diferentes configurações, customizações e validações nos Pull Requests. Justamente por isso, é possível utilizá-lo para automatizar certas etapas no processo de Code Review.
Nas seções seguintes são apresentados 2 exemplos de situações que poderiam acontecer no processo de revisão de código e como a configuração do Github Actions poderia ajudar.
Caso de Uso 1: Autor Fantasma
Imagine a seguinte situação: um desenvolvedor submete um código para revisão, mas não o atribui a ninguém. E toda vez que isso acontece, os revisores têm que comentar e pedir para o autor atribuir o Pull Request (PR) a alguém. Depois, os revisores têm que voltar a revisar e validar novamente se isso foi feito. Algo tão simples, mas que pode se tornar repetitivo e demandar um tempo a mais tanto do autor, para corrigir, como do revisor, para revisar novamente.
Uma forma de resolver isso é criar uma action que, automaticamente, atribui o PR a alguém. Geralmente, o PR deve ser atribuído ao próprio autor e, nesse caso, a action poderia ficar da seguinte forma:
Como funciona:
Primeiramente, para que o script do tipo YAML (.yml) seja executado, ele deve ser adicionado a uma pasta na raiz do seu repositório com o seguinte caminho: .github/workflows.
Para conferir em detalhes como criar diferentes workflows, basta acessar a documentação: Github Workflows.
Sobre o script da action em si, temos o seguinte:
Linhas 3 e 4: Indicamos que o script deve ser executado para Pull Requests quando seu status muda para o tipo aberto (opened) ou pronto para review (ready_for_review).
Linha 10: Utilizamos uma action pública, com boa reputação, disponível no Marketplace de actions para fazer o trabalho de atribuir o autor do PR.
Dessa forma, sempre que um PR for criado, automaticamente o autor é atribuído.
Caso de Uso 2: Labels indefinidas
Uma outra situação pode acontecer com a vinculação de labels ao Pull Request: você, como revisor, tem que todos os dias validar o código e validar se as labels foram adicionadas, caso não tenham, você tem que solicitar o ajuste para o autor. E você faz isso 1, 2, 10 vezes na semana. Um pouco chato, não é?
Para solucionar esse caso, é possível delegar essa responsabilidade para uma action, como no exemplo abaixo. No exemplo, é feita uma validação se existem labels associadas ao Pull Request, caso não existam, um erro será exibido nos steps de validação do PR.
Como funciona:
Linhas 3 e 4: Indicamos que o script deve ser executado para Pull Requests em vários tipos de eventos, inclusive quando as labels são adicionadas ou removidas (labeled, unlabeled).
Linha 10: São feitas duas validações:
A primeira é uma validação para garantir que o script todo somente será executado caso o PR não esteja como draft. Isso é feito para otimizar a quantidade de minutos que são utilizados, pois o Github Actions possui custo, então é muito importante economizar os minutos, sempre que possível.
A segunda validação é a que cumpre o objetivo de validar se o PR possui labels.
Caso a validação se confirme, um erro é gerado e o PR aparecerá com o status de erro, como mostra a imagem abaixo:
Notificações com Github + Slack
Uma outra etapa que pode ser otimizada no processo de Code Review, é a de solicitar a revisão. É comum nesse processo solicitar o review pela própria plataforma de versionamento, o que pode disparar um email para as pessoas que foram incluídas como revisores. Porém, isso pode não ser muito efetivo, visto que nem sempre as pessoas consultam o email com muita frequência.
Então, uma dica é criar um canal / grupo para centralizar o compartilhamento de Pull Requests pronto para serem revisados. E, de forma complementar, para que esse processo não seja feito de forma manual, é possível automatizar o envio de notificações para esse canal sempre que um PR for marcado como pronto para review.
Utilizando o Github e o Slack como exemplo, já existe uma ferramenta com a integração das duas plataformas que permite enviar diferentes tipos de notificações do Github automaticamente para o Slack: Github + Slack.
Como Configurar?
Para o caso de uso mencionado, os passos para configurar as notificações de PRs prontos para revisão seriam:
Definir qual canal do Slack seria utilizado para compartilhar os Pull Requests;
Efetuar a conexão de Github + Slack, como demonstrado nesse guia oficial;
Adicionar o bot do Github no canal de PRs:
/invite @github
Efetuar a inscrição no canal para atividades no repositório da sua equipe:
/github subscribe <organization>/<repository>
Configurar o canal para receber somente notificações de Pull Requests prontos para revisão.
Por default, a configuração de notificação de PRs já vem ativa, então não é necessário se inscrever nela, mas caso quisesse, o comando seria:
/github subscribe <organization>/<repository> pulls
Por default, algumas outras configurações vem ativas. Então, para desativá-las, execute:
/github unsubscribe <organization>/<repository> issues commits releases deployments
E pronto, assim que um novo PR estiver pronto para revisão, uma notificação será enviada no canal, aparecendo de forma similar a imagem abaixo:
Fonte da Imagem: Github.
Todos esses passos estão na documentação oficial da ferramenta de forma mais detalhada.
Conclusão
Ao longo desse artigo foram discutidos os benefícios do Code Review e como esse processo é importante no dia a dia dos desenvolvedores de software. Além disso, foram apresentados exemplos de etapas desse processo que podem ter seu tempo otimizado, e ferramentas que podem contribuir com essa otimização. Foram apresentados pequenos exemplos, mas, a partir deles, é possível criar diferentes soluções que se adequem à realidade da sua equipe de trabalho. As possibilidades são infinitas :)
Referências
Gostou desse conteúdo? Clique no botão abaixo para apoiar pelo Github Sponsors :)
Comments