Revisão de código empática — Para pessoas revisoras
Revisão de código faz parte do dia-a-dia de qualquer time de desenvolvimento: os famigerados PRs/MRs (pull/merge requests).
Porém, nós como pessoas desenvolvedoras de software poucas vezes paramos pra pensar em como essa tarefa corriqueira é uma faca de dois gumes: pode servir tanto para arruinar relacionamentos, quanto para potencializar o desenvolvimento, ambos tanto individuais quanto da equipe.
Esse artigo é a continuação da parte para pessoas autoras, e é altamente baseado no Code Review Guidelines for Humans, do Philipp Hauer.
Para pessoas revisoras, essas são as sugestões:
- Use a primeira pessoa;
- Fale sobre o código, não sobre a pessoa;
- Pergunte!
- O modelo Observação, Impacto e Requisição para dar feedback;
- Aceite diferentes soluções;
- Não pule na frente de todos os trens;
- Elogie e agradeça;
- Três filtros para o feedback.
Use a primeira pessoa
Comentar em primeira pessoa sugere necessariamente seu ponto de vista.
Utilizar colocações como "eu sugiro …", "eu gostaria de …", "é difícil para mim …" colocam a pessoa revisora na posição de entender e contribuir.
O contrário disso é comentar diretamente usando "você", por exemplo.
Comentários desse tipo tendem a ser mais entendidos como um ataque pessoal. Desse modo a pessoa não vai estar pensando em como poderia fazer melhor, mas sim em como se defender.
Fale sobre o código, não sobre a pessoa
Ainda conectado com o tema anterior, falar sobre o código torna a revisão objetiva.
Utilizar termos como "este código faz …" ao invés de "você está fazendo isso e aquilo …" fazem com que dificilmente a revisão possa ser levada para o lado pessoal.
Mas pra isso, é importante também que a pessoa autora entenda que ela não é seu próprio código, como vimos na primeira parte desse artigo.
Pergunte!
Perguntar em uma revisão de código é algo que desencadeia um processo de discussão e melhoria.
Utilizar "o que você acha de …", "que tal se …" ao invés de "faça isso", "mude aquilo", "isso deveria ser de tal maneira", ajudam a entender o ponto de vista da pessoa autora.
O uso de perguntas faz com que a pessoa pense sobre a sugestão e, de maneira colaborativa, chegue-se em uma nova e melhor solução, que não necessariamente é o código em revisão, nem a sugestão de mudança.
O modelo Observação, Impacto e Requisição para dar feedback
Antes de dar um feedback, utilize o modelo OIR (Observação, Impacto e Requisição) para estruturar o feedback.
- Observação: descreva de maneira objetiva o ponto a ser comentado (exemplo: "essa função possui 100 linhas");
- Impacto: seja objetivo quanto ao impacto que o código causa (exemplo: "é difícil para mim entender uma função com 100 linhas e pode ser difícil dar manutenção no futuro");
- Requisição: faça a sugestão utilizando primeira pessoa ou utilizando perguntas (exemplo: "que tal quebrar essa função em pedaços menores?").
Importante retomar pontos anteriores onde observação e impacto falam sobre o código, e a requisição deve utilizar perguntas ou ser feita em primeira pessoa.
Aceite diferentes soluções
Todos nós, como pessoas desenvolvedoras, temos soluções preferidas.
Mas é importante distinguir entre boas práticas e gosto pessoal. Uma solução diferente da preferida, mas que ainda assim siga boas práticas, não deve ser motivo de contestação em uma revisão de código.
Não pule na frente de todos os trens
Quando revisamos código é comum identificarmos uma série de pontos a serem comentados.
No entanto, criticar todo e qualquer um desses pontos faz com que a revisão seja irritante e reduz a abertura ao feedback.
Se isso afeta o relacionamento entre as partes, isso reduz a chance de se resolver problemas, que é o objetivo primário da revisão de código.
Um PR/MR normalmente se propõe a resolver um problema em específico, e nesse caso a revisão deveria se focar se esse problema está sendo bem-resolvido.
Portanto, focar-se em aspectos secundários (ainda que importantes) como convenções de código, indentação e etc, pode desviar o foco para a correção de um algoritmo importante, por exemplo.
(Sobre a metáfora de não pular na frente de todos os trens)
Elogie e agradeça
Revisão de código não é feita somente de críticas: elogios e agradecimentos são motivadores tanto para a pessoa que revisa quanto pra pessoa autora.
Como pessoa que revisa, ainda que o código não necessite de nenhum ajuste, deixe um comentário positivo se achar pertinente. "Parece bom pra mim", "gostei do uso de tal padrão", "bons testes", são alguns exemplos que podem ser usados.
Do lado da autoria também é interessante agradecer feedbacks pela revisão e pelo tempo investido. É uma via de mão-dupla que ajuda a continuar tendo revisões boas e produtivas.
Por fim, é importante que ao elogiar evite-se o uso do "feedback sanduíche", que é aquele em que se diz algo legal, depois se coloca uma crítica e fecha-se com algo legal de novo.
Isso normalmente deprecia o feedback tornando-o menos genuíno. Se há críticas a serem feitas, melhor fazê-las separadamente usando o modelo OIR conforme discutido acima, deixando os elogios para uma seção específica sem contrapontos.
Três filtros para o feedback
Por fim, antes de dar um feedback, é interessante passar por três filtros:
- É verdade?
Evitar opinião pessoal, dizer se é certo ou errado. Melhor: recomendar, perguntar e citar literatura. - É necessário?
Relacionado com não pular na frente de todos os trens. Quão importante para o PR/MR em questão é necessário determinado comentário? Ainda que seja uma discussão importante, mas se for mais complexa, melhor marcar uma discussão em separado. - É gentil?
Novamente: utilizar perguntas e sugestões é uma maneira de se fomentar discussões e construir melhores soluções de maneira colaborativa.
Exemplo
A seguir, um pequeno exemplo de como usamos essas técnicas no dia-a-dia da SumUp.
No exemplo acima utilizamos as técnicas de:
- Pergunte!
Tentando entender a opção do uso deNodePort. - Use a primeira pessoa
O autor pergunta sobre uma recomendação e a revisão faz a mesma na primeira pessoa, evidenciando ser um ponto de vista. - Fale sobre o código, não sobre a pessoa
O trecho claramente pergunta sobre a opção feita, ao invés de usar algo do tipo "por que você usouNodePortaqui"? - O modelo OIR para dar feedback
Observamos o uso deNodePort, o impacto é ter um efeito colateral de expor isso desnecessariamente para fora do cluster K8S. Apesar de não ter sido feita uma requisição explícita, o autor do código concordou com o impacto desnecessário. - Elogie e agradeça
Após os devidos esclarecimentos, ambos concordaram em uma solução melhor que a inicial.
Conclusão
Para quem revisa, o processo pode ser ainda mais desafiador: ainda que se saibam todos os motivos técnicos para um dado comentário, é necessário trazê-los adequadamente para a discussão.
Sempre com um propósito único: construir de maneira colaborativa uma solução melhor que a inicial.
Revisão e o processo de feedbacks devem ser encarados como um exercício contínuo, onde a melhoria só se dá pela prática: não espere acertar de primeira e nem acertar sempre.
Porém, importando-se genuinamente com o outro e com o valor gerado pela revisão, espere grandes resultados tanto no nível de produto quanto em termos de relacionamento dentro de uma equipe.
