Code Review: estamos fazendo direito?

Com a popularização e consolidação do Agile e do open source, a prática de code review tornou-se conhecida e promovida dentro das equipes (mesmo aquelas trabalhando em código fechado). Mas será que estamos realmente fazendo code review direito, mesmo em equipes onde ele está teoricamente adotado?

Este artigo irá abordar duas disfunções clássicas relacionadas ao assunto e mostrará algumas ideias de como resolvê-las. No entanto, vale salientar que o propósito do artigo não é estabelecer um guia passo-a-passo de como fazer um code review.

O BÁSICO

O propósito primário do code review é preservar a base de código de um produto, isto é, garantir que o novo código satisfaça padrões estabelecidos de qualidade e corretude.

Um bom code review pode evitar desperdícios e custos altos de manutenção ao garantir que código extremamente complexo ou até mesmo desnecessário entre para a base de código corrente.

Além disso, o code review é uma ótima ferramenta para troca de conhecimento. Pode-se ensinar e aprender muito praticando-o, o que, além de benéfico para a carreira, promove o nivelamento da equipe.

DUAS CONHECIDAS DISFUNÇÕES

Trabalhando com diversas pessoas em equipes e empresas diferentes, tenho visto o code review ser, com certa frequência, negligenciado: o “reviewer” simplesmente aprova o Pull/Merge Request (daqui em diante: “PR”), investindo nenhum ou pouco tempo para revisá-lo de fato.

Alguns fatores causadores dessa disfunção podem ser:

  1. Equipe trabalhando em “modo Go Horse“. Daria outro artigo, mas o ponto é que tem gente que acha que está num “time ágil” por conta da existência de uma série de papéis e cerimônias!
  2. Funcionários insatisfeitos com a empresa, adotando posturas antiprofissionais.
  3. “Revisor” (ou a equipe toda) muito inexperiente, sem a consciência sobre a importância do review ou mesmo desconfortável ao revisar o PR de alguém mais sênior.
  4. O “revisor” acha chato fazer o code review. (Obviamente, é mais chato do que estar em ação, programando, mas o mundo não é só feito de flores, é?)

Em equipes já acostumadas com o code review, pode aparecer uma disfunção exatamente oposta à primeira: a demora no processo de review. Quem nunca testemunhou ou esteve envolvido num review que durou dias ou semanas, com inúmeros comentários, réplicas, tréplicas?!

Neste caso, alguns causadores podem ser:

  1. Falta de clareza quanto ao próprio PR (falta de entendimento do problema a ser resolvido, ausência de contexto sobre o PR).
  2. Ausência de coding standards preestabelecidos.
  3. Ausência ou pouca discussão sobre a solução antes do “sair fazendo”.
  4. PRs muito grandes.
  5. Código desleixado, de nível técnico muito ruim.
  6. Briga de egos: “a MINHA ideia deve prevalecer”.

E AGORA?

Seguem alguns pontos que podem ajudar a melhorar gradualmente o processo de code review:

» Chame alguém da equipe para discutir antes de implementar algo que irá impactar bastante a base de código (ou que você supõe que poderá causar alguma polêmica).

» Use ferramentas de linting. Automatize toda a formatação e checagem do código por possíveis erros e inconformidades com o coding standard. Não vamos gastar tempo dos revisores com “bobagens” que podem ser resolvidas “pré-PR”.

» Invista uns minutos a mais revisando seu próprio código antes de abrir o PR.

» Não abra um PR sem descrição alguma. Invista algum tempo na descrição de seu propósito. Se possível, inclua ou faça referência à documentação relacionada.

» Diga “podem revisar?” em vez de “podem aprovar?”. Pode ser algo bobo, mas contribui para formar a cultura desejada.

» Tente abrir PRs pequenos. Saber quebrar problemas grandes em pedaços pequenos exige muita prática, então é preciso começar!

» Enquanto reviewer, experimente fazer o review em par com o autor do PR. Isso pode ajudá-lo em caso de achar muito tedioso o processo de review. Também pode evitar os reviews intermináveis já que o feedback será imediato, face-a-face com o autor. Por fim, poderá servir como uma mentoria mais efetiva, em especial para aqueles que abrem PRs de baixa qualidade com uma certa frequência.

Outros pontos que podem ser considerados pela equipe:

» Formalizar um style guide, servindo como o guia definitivo para coding standards. Pode-se adotar um style guide já existente da linguagem e customizá-lo com o tempo.

» Criar ou adotar um guia para realização de code reviews. Recomendo a leitura do material do Google.

CONCLUINDO

Code review não é “code approval”. Investir tempo revisando código é um trabalho tão essencial quanto o próprio ato de codificar e pode evitar muitos problemas ao longo do tempo de vida do código.

Code review deve ser objetivo. Busque trabalhar de forma que PRs tenham o propósito claro para todos e sejam pequenos. Deixe o ego de lado. Não existe a “minha solução” nem a solução perfeita. Siga em frente com o “bom o bastante”.

As ideias de melhoria aqui descritas definitivamente não atendem todos os prováveis fatores causadores das disfunções. É preciso fazer uma autorreflexão e dialogar francamente com a equipe, de modo a resolver os problemas o mais rápido possível.

Por fim, reforço a recomendação de leitura do guia do Google para entender melhor e até mesmo elaborar seu próprio guia de como fazer um review.

Como está o code review na sua equipe? Passando por quais problemas? Que práticas adotou para resolvê-los? Conte aí!

2 comentários em “Code Review: estamos fazendo direito?

Adicione o seu

  1. Fala Robson, blz?

    Já passei por situações de reviews longos e o time usou uma das estratégias que você citou: trabalhar um pouco mais na história/tarefa antes de sair escrevendo código.

    Ouvi de uma pessoa do time: não sou linter. E essa pessoa estava 100% correta, pois estávamos dedicando tempo para coisas simples de formatação, que poderiam ser resolvidas com ferramentas. Aqui surgiu outra ação, passamos a usar o pre-commit.

    Ler código é uma skill tão importante quanto escrever, mas é uma habilidade pouco comentada e explorada.

    Curtir

Participe! Vamos trocar uma ideia sobre desenvolvimento de software!

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

Blog no WordPress.com.

Acima ↑

%d blogueiros gostam disto: