Revisão de código empática — Para pessoas autoras
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.
Não é ideia desse artigo apontar culpados, mas não é difícil notar que, em geral, as formações da área de Exatas valorizam o racional e a corretude sem direcionar como isso se estabelece em relações de equipe.
E isso frequentemente afeta as dinâmicas de equipes, sem que os membros tenham consciência disso.
- Baixa empatia: manifesta-se por meio de comentários que desqualificam a pessoa autora do código, sem tentar entender a motivação, não gerando valor à revisão;
- Alta empatia: faz uso de perguntas e sugestões, construindo uma solução a quatro (ou mais) mãos, gerando uma solução melhor que a inicial.
Esse artigo é dividido em duas partes: para pessoas autoras (este artigo) e para pessoas revisoras, e é altamente baseado no Code Review Guidelines for Humans, do Philipp Hauer.
Para pessoas autoras, algumas sugestões de diretrizes:
- Lembre-se: você não é seu código;
- Estamos todos do mesmo lado;
- Seja humilde;
- Lembre-se do "efeito IKEA";
- Esteja aberto a novas perspectivas;
- Discuta sobre boas práticas.
Lembre-se: você não é seu código
Parece uma observação óbvia, mas ter isso em mente ajuda a interpretar melhor as avaliações feitas nos PRs/MRs: muitas vezes é fácil levar para o lado pessoal.
Deve-se lembrar que os comentários feitos na revisão são sobre o código em si, e não sobre você.
Convém lembrar ainda que erros são e serão cometidos sempre, e nem por isso você será uma pessoa menos valorizada no time por conta disso.
Pelo contrário!
A receptividade a comentários e correções trazem melhorias individuais, e por consequência, para o time todo.
Estamos todos do mesmo lado
É válido assumir que você e a pessoa revisora estão na intenção de construir o melhor produto possível.
Então eventuais sugestões e críticas são partes do processo de atingir esse gol!
Seja humilde
Somos humanos acima de tudo, e humanos cometem erros.
Ou seja: enquanto software continuar a ser escrito por humanos, irão existir erros (e por enquanto, por máquinas também).
Isso no entanto não significa uma licença para desleixo com o próprio código: lembre-se de sempre fazer o melhor possível com seu conhecimento e o mais adequado para cada situação.
É importante ainda tirar a conotação negativa da palavra "erro".
O erro é sempre uma oportunidade de aprendizado, por maior que seja a senioridade de uma pessoa desenvolvedora.
Por fim: não faça relação entre erros cometidos e ser um profissional confiável. Admitir erros mostram que você é uma pessoa:
- Profissional;
- Honesta;
- E humana acima de tudo.
Lembre-se do "efeito IKEA"
A IKEA é uma loja de móveis e decoração para o lar, onde no Brasil encontramos algumas similares.
O "efeito IKEA" é descrito como um viés cognitivo onde as pessoas dão um valor desproporcional a algo em que elas parcialmente criaram.
No caso de um móvel, por exemplo, esse evento se manifesta pelo valor dado a um móvel montado pela própria pessoa, ao invés de se comprar um móvel já montado.
E como isso se relaciona com revisão de código?
Normalmente tendemos a supervalorizar o código que escrevemos, justamente pela participação no processo de criação.
Isso se relaciona com "Você não é seu código", como vimos ali em cima.
Portanto, lembre-se: desapega.
O processo de revisão eventualmente vai convergir para um código melhor, onde isso pode inclusive descartar a solução inicial.
E está tudo bem, afinal como vimos também ali em cima, "Estamos todos do mesmo lado".
Esteja aberto a novas perspectivas
Estar aberto a novas perspectivas é um aspecto-chave da revisão de código.
Pessoas desenvolvedoras de software tem diferentes:
- Backgrounds;
- Crenças;
- Conhecimentos;
- Experiências.
A pessoa revisando seu código pode não estar familiarizada com algo cujo conhecimento você domina completamente (e naturalmente cria um viés).
Essa é, portanto, uma excelente oportunidade para disseminar conhecimento, permitindo que a outra pessoa aprenda sobre algo, podendo assim dar uma nova perspectiva sobre isso.
Discuta sobre boas práticas
Boas práticas de desenvolvimento normalmente estão baseadas na literatura e na cultura praticada em cada equipe.
O momento da revisão de código é uma excelente oportunidade de uniformizar essas práticas, fazendo com que os membros de uma mesma equipe tenham um mesmo entendimento da melhor maneira a se escrever um código nesse contexto.
Portanto, encare o momento de revisão de código como uma fonte valiosa de conhecimento e mais uma oportunidade de aprendizado.
Conclusão
Para pessoas autoras, o processo de revisão de código deve ser considerada uma oportunidade de aprendizado.
Nada do que for comentado se refere à pessoa especificamente, e estar exposta ao erro não a torna menos confiável. Pelo contrário! Admitir e aprender com isso demonstra profissionalismo e honestidade.
Na segunda parte deste artigo falaremos sobre o processo de revisão para o lado da pessoa desenvolvedora. Até lá!
