Priorização é sempre algo complicado, não é mesmo? O tempo está sempre contra a gente, e as vezes precisamos fazer escolhas difíceis sobre onde devemos focar a nossa atenção e o nosso esforço. Com code reviews não é diferente. Por isso é muito importante traçar uma estratégia para investir seu tempo de revisão de maneira eficiente.

Conforme a organização em que trabalhamos cresce, vai ficando cada vez mais difícil acompanhar tudo o que está acontecendo. Pessoas novas vão entrando na equipe, ao mesmo tempo em que a base de código cresce numa velocidade ainda maior. O conhecimento técnico e de negócios, que antes era de conhecimento de todos os desenvolvedores, começa a se concentrar nas equipes, podendo gerar uma série de problemas:

• Diminuição da qualidade dos code reviews, pois algumas equipes podem estar desfalcadas de pessoas com conhecimento técnico ou de negócios
• Diminuição no número de code reviews em projetos de pouca visiblidade
• Redução no alinhamento entre as equipes, podendo resultar em retrabalho ou até mesmo bugs
• Risco de perda de conhecimento e dificuldade na realocação dos membros das equipes, já que alguns contextos podem se tornar muito dependentes de pessoas específicas

Como reduzir esses problemas?

Nem todos os code reviews são iguais

Os code reviews são uma excelente prática para melhorar a qualidade do código e diminuir o número de erros. Mas um outro benefício, tão importante quanto estes, é o compartilhamento de conhecimento entre os desenvolvedores.

Quando eu reviso um PR (Pull Request ou Change request, dependendo da ferramenta), sinto que conhecendo o seu contexto fica mais fácil fazer uma revisão mais aprofundada e assertiva. Dúvidas do tipo:

• Essa solução realmente resolve o problema?
• Existem maneiras melhores de resolver o problema?
• Essa funcionalidade faz sentido do ponto de vista de negócios?
• É viável prosseguir com essa funcionalidade agora?

Ficam mais mais fáceis de serem enxergadas e respondidas. Mas, para ter essas respostas, ter um bom conhecimento sobre o negócio é fundamental. Por isso, as vezes acabamos revisando apenas os PRs nos quais já temos contexto, sejam eles da nossa equipe ou de partes do sistema que já conhecemos. Se pensarmos no nível organizacional, esse tipo de comportamento pode resultar nos problemas citados, muitas vezes difíceis de serem diagnosticados.

Apresentando a Pirâmide de Code Reviews

Uma prática que pode ajudar a resolver esses problemas é a Pirâmide de Code Reviews.

Essa pirâmide, inspirada na Pirâmide de Testes, nos ajuda na priorização do que devemos fazer.

Pull Requests da nossa equipe são a base da pirâmide, pois são neles onde dedicaremos mais tempo. Como já possuímos o conhecimento necessário para fazer um bom code review, é provável que essas revisões sejam feitas mais rapidamente. Dessa forma, ajudamos os outros desenvolvedores a entregar seu trabalho com mais qualidade mais rapidamente.

No segundo nível da pirâmide temos dois grupos de PRs: aqueles em que já possuímos contexto e os chamados “PRs críticos”.

Os PRs que já possuímos contexto são mais óbvios: eles envolvem uma parte do código ou do negócio já conhecida pelo desenvolvedor, fazendo com que ele(a) se sinta confortável na revisão. Eles não diferem muito dos Pull Requests do próprio squad, porém como são externos, consideramos que haverão outras pessoas da squad envolvida ajudando na revisão. Por isso gastamos menos tempo neles.

Já os chamados “Pull Requests Críticos” são um pouco diferentes. Esses PRs podem implementar diferentes tipos de funcionalidades, desde resolver um erro crítico até mudanças na arquitetura, e é essencial que os desenvolvedores estejam alinhados com suas alterações. Esse tipo de Pull Request geralmente requer uma atenção imediata dos desenvolvedores, por isso é importante separar um tempo para revisá-los.

O que a pirâmide traz de diferente é tornar explícito que devemos inserir no nosso processo de trabalho as revisões exploratórias. Ou seja, não precisamos mais nos sentir restritos a(s) parte(s) do sistema onde trabalhamos. Pelo contrário, tendo a pirâmide em mente, nos sentimos incentivados a revisar outras partes do código e expandir nosso conhecimento do negócio.

Mas como começar por esse caminho? Será que meus code-reviews serão bem aceitos?

Começando os code reviews exploratórios

Ao revisar uma parte do código ou do negócio que não estamos familizados é natural nos sentir desconfortáveis ou inseguros. Podemos nos sentir desestimulados a discutir, com medo de fazer perguntas “estúpidas” ou redundantes. E se não conhecermos muito bem os desenvolvedores envolvidos no PR isso fica ainda pior. Resumindo: saímos da nossa zona de conforto.

Já apresentamos os benefícios dos code reviews exploratórios, porém como devemos proceder na hora de revisar código desconhecido, onde supostamente nossa efetividade vai ser menor? E como devemos reagir quando uma pessoa de fora revisa o código e começa a fazer perguntas ou questionamentos?

Como o próprio nome já diz, estamos explorando uma parte desconhecida do projeto, por isso ter uma atitude curiosa é essencial. Fazer perguntas, dar dicas e sugestões e compartilhar experiências são ótimos pontos para se ter em mente nessas revisões. Ter bom senso também é importante aqui, pois não precisamos entender todo o contexto de negócio logo de cara na primeira revisão. Identificar o contexto mínimo que precisamos para fazer a revisão é vital para não onerarmos demais o nosso tempo nem o dos demais participantes.

E quando recebermos esse tipo de revisão é importante ter uma atitude respeitosa e didática nos comentários. Perguntas devem ser respondidas sempre educadamente e com um nível suficiente de detalhes(o bom senso vale aqui também). Respostas atravessadas ou incompletas podem prejudicar as revisões e desestimular os revisores a continuarem com essa prática. Lembre-se: ninguém é dono do código, o código que você está fazendo agora será usado por outros desenvolvedores no futuro. E vice-versa. Um ambiente amigável durante as revisões vai tornar essa prática muito mais proveitosa para todas as partes envolvidas.

E quais critérios devemos usar para escolher aonde vamos explorar? Bem, a decisão final fica por sua escolha. Mas se você souber de alguma parte do projeto que carece de revisões, pode ser uma boa idéia dar uma explorada por lá.

Quanto tempo devo me dedicar aos code reviews exploratórios? Isso varia de cada contexto. Se você tem bastante tempo livre para explorar outras partes do código, faça isso! Já se você não tiver tanto tempo assim, tente dedicar pelo menos algumas horas por semana para explorar. Um bom começo seria fazer pelo menos uma revisão exploratória por semana.

E você, como organiza seu tempo para revisar PRs? Você se sentiria confortável em adotar essa prática onde você trabalha? Deixe seu comentário logo abaixo.