O processo de code-review tem sido uma prática comum nas empresas que prezam por mais qualidade no código. É essencial o olhar de outra pessoa desenvolvedora antes de um pull request ser aprovado. Geralmente, estamos enviesados no teste, ou não prestamos atenção em algum detalhe técnico na hora em que estamos codando.

Os comentários e discussões servem para alguns propósitos, como estabelecer novos padrões, manter a qualidade de code-base, eliminar possíveis bugs e compartilhar conhecimento entre os times. Para entender melhor os pontos positivos, veja esse artigo completo sobre o assunto.

Acontece que, para que essas discussões sejam saudáveis, é necessário um pouco de empatia. Algumas coisas precisam ser ditas de forma mais amigável, sem um olhar crítico destrutivo e menos ainda de humilhação. Esse tipo de comportamento torna o processo de estabelecer e difundir padrões muito hostil e demorado.

No GetNinjas nós adotamos, meio que por costume e hábito, algumas regrinhas de convivência; não escritas num manifesto, mas passadas por osmose para cada um(a) dos(as) desenvolvedores(as).

*Triborg é o nome de um dos nossos projetos.

Com base nessas regras, deixo aqui algumas das práticas e pontos que prestamos atenção antes de comentar num pull request. Assim, sempre que for analisar um código, poderá levar em conta alguns fatores importantes que descrevo logo abaixo.

Esquecer de algum detalhe

É normal esquecer algo ou algum cenário de teste quando você está desenvolvendo. O ideal seria ter todos esses cenários descritos antes de fazer a funcionalidade para não ter surpresas depois. Mas mesmo com isso descrito, alguns comportamentos inesperados podem acontecer.

Cabe a quem analisa o código, principalmente quem é do seu time, levantar esses detalhes esquecidos na implementação. Além disso, adicionar comentários sobre um possível bug de implementação encontrado nessa funcionalidade ou alteração que possa ajudar a cobrir o código para evitar o mesmo no futuro.

Imaturidade ou baixa experiência com a linguagem

Existem vários tipos de perfis nos times e empresas. Por isso, é bom levar em conta essa informação antes de fazer um review muito sarcástico ou em tom de repreensão abusiva.

Não há necessidade de usar os comentários para provar que você tem mais experiência que outra pessoa. Além disso, são eles que vão fazer com que o(a) novato(a) aprenda de verdade.

Lembrando que você um dia passou pelo mesmo momento que a pessoa inexperiente. Um pouco de empatia não faz mal a ninguém.

Desconhecer os padrões do time

Esse é um dos pontos mais fáceis de resolver, mas mesmo assim, quando uma pessoa nova no time faz um pull request, diversas pessoas continuam fazendo o review como se fosse alguém já acostumado com todo esse ambiente e com os padrões estabelecidos. O review fica contido apenas em code style, quando deveríamos discutir sobre a forma, padrões de arquitetura e conceitos de lógica.

Há várias maneiras de resolver esse problema, dentre elas, estabelecer padrões compatíveis com os da comunidade e criar um repositório de code style. Basicamente, todas as linguagens possuem um desse (exemplo: o de JavaScript do Airbnb. Fizemos um fork no GetNinjas pra seguirmos).

Outra ideia é utilizar ferramentas automatizadas pra aplicar essas regras do code style. Existem várias, como Hound CI, Linthub ou um plugin do Codeclimate.

Acho que as discussões acabam ficando mais na lógica do que nos detalhes estéticos do código, como aspas simples ou duplas, variáveis declaradas numa linha ou uma em cada etc…

Fazer às pressas por alguma pressão externa

Sim, o mundo não é perfeito e o tempo de desenvolvimento impacta diretamente no negócio. Muitas vezes, algumas coisas são feitas na correria pra atender alguma demanda de negócio. É ruim? Sim! Falta planejamento? Na maioria das vezes sim, mas nem sempre. Pode haver algum fator externo, como por exemplo o caso de um gateway de pagamento mudar a estrutura de sua API ou integração com outros sistemas mudarem.

O fato é que, havendo algum fator comprovadamente externo, é melhor não “segurar” um pull request e tentar entender o porquê daquele código ter sido feito tão na correria assim, e, consequentemente com vários problemas de arquitetura ou de design.

Não ter familiaridade com o processo de code-review

Mais um ponto que remete à pessoas que acabaram de entrar no time. É imprescindível que o code-review de alguém que acabou de entrar tenha mais orientações, do que correções e alterações forçadas. É melhor explicar como funciona o processo de review do código, do que sair enchendo o pull request de comentários sobre os padrões do time. Eu já fiz muito disso e assumo aqui essa falha.

Lembrando que, se houver uma forma da nova pessoa do time conhecer como funciona o processo de avaliação de código, fica mais fácil dela aprender e aplicar as possíveis melhorias, antes de subir seu código.

É importante também ter paciência nos primeiros meses da pessoa no time e lembrar sempre que, isso não coloca a capacidade da mesma em cheque, apenas por não conhecer o processo de avaliação do código.

É claro que é importante que a pessoa se adapte ao processo o quanto antes, mas dê tempo ao tempo.

Esquecer de subir alterações locais

Ter esquecido de fazer o commit e push de algo que continha o possível fix, sugerido em algum comentário é mais comum do que parece. Às vezes, você faz algo no próprio navegador, no caso do mundo front-end, e esquece, por exemplo, de replicar no editor. Já fiz isso por diversas vezes…

Nesse caso, não tem como adivinhar: é preciso perguntar diretamente para o autor do pull request se ele esqueceu de algo ou está tudo certo. Apenas listando aqui como uma das possíveis coisas do dia-a-dia, podem acabar gerando comentários ríspidos sem necessidade.

Testar uma nova funcionalidade

Normalmente, numa empresa que sempre está puxando os(as) desenvolvedores(as) para o lado da inovação, acontece de subirmos PRs com funcionalidades ou tecnologias muito recentes.

Nesse caso, vale tentar descobrir juntos uma forma melhor de usar a linguagem ou ferramenta e não sermos sarcásticos.

Não entender gírias ou piadas internas

Todos os times têm sua própria forma de se comunicar, fazer piadas ou brincadeiras. É muito bom e isso torna o ambiente mais agradável (contando que não sejam piadas agressivas ou preconceituosas). O fato é que, nem sempre quem acabou de entrar pode entender essas brincadeiras.

De duas, uma: ou explica a piada, logo depois do comentário, ou não faz. Deixar um comentário e não explicar, seja no chat ou pessoalmente, deixa a outra pessoa boiando ou até mesmo pensando algo errado sobre isso.

Alguns comentários são mais comuns nos times, como o famoso ? e o ✂️ — usados comumente pra remover uma linha em branco ou indentação. Mas alguns são muito específicos. No GetNinjas temos o famoso :segue_bola_teste:, que é uma piada interna (se um dia entrar lá você vai entender, ou me pergunte num evento por aí).

Resumindo

Há vários fatores de atenção antes de fazer um review. Leve em conta alguns desses itens, antes de assumir outro ponto que não foi levantado. Isso ajuda a ter empatia com a pessoa que subiu esse novo código e está, na maioria das vezes, no seu próprio time.

Nós, aqui no GetNinjas, buscamos sempre manter nossos code-reviews sadios. Se vemos algo muito fora do normal, tentamos contornar e resolver o problema antes que vire um incidente entre as pessoas. Faz parte da nossa cultura resolver o quanto antes qualquer tipo de mal entendido.

Eu vi, não sei onde, uma frase muito boa sobre equipes: não há espaço pra egos num time. Levando para o dia-a-dia, fica mais fácil entender que todos estão ali, juntos, pra aprender algo e ensinar também.