Trazendo uma mentalidade de revisão de código saudável para sua equipe

Uma 'revisão de código' é um momento no processo de desenvolvimento em que você (como desenvolvedor) e seus colegas trabalham juntos e procuram bugs em um código recente antes que ele seja lançado. Nesse momento, você pode ser o autor do código ou um dos revisores.

Ao fazer uma revisão de código, você pode não ter certeza do que está procurando. Por outro lado, ao enviar uma revisão de código, você pode não saber o que esperar. Essa falta de empatia e expectativas erradas entre os dois lados podem desencadear situações infelizes e apressar o processo até que termine em uma experiência desagradável para ambos os lados.

Neste artigo, compartilharei como esse resultado pode ser alterado alterando sua mentalidade durante uma revisão de código:

• Como uma equipe
• Como um autor
• Como revisor

Trabalhando em equipe

Promova uma cultura de colaboração

Antes de começarmos, é fundamental entender o valor do motivo pelo qual o código precisa ser revisado. O compartilhamento de conhecimento e a coesão da equipe são benéficos para todos, no entanto, se feito com uma mentalidade ruim, uma revisão de código pode consumir muito tempo com resultados desagradáveis.

A atitude e o comportamento da equipe devem abraçar o valor de uma colaboração sem julgamento, com o objetivo comum de aprender e compartilhar — independentemente da experiência de outra pessoa.

Incluir revisões de código em suas estimativas

Uma revisão de código completa leva tempo. Se uma alteração levou uma semana para ser feita, não espere que a revisão do código demore menos de um dia. Simplesmente não funciona assim. Não tente apressar uma revisão de código nem veja isso como um gargalo.

As revisões de código são tão importantes quanto escrever o código real. Como equipe, lembre-se de incluir revisões de código em seu fluxo de trabalho e defina expectativas sobre quanto tempo uma revisão de código pode levar, para que todos estejam sincronizados e confiantes em seu trabalho.

Economize tempo com diretrizes e automatização

Uma maneira eficaz de garantir contribuições consistentes é integrar um modelo de Pull Request no projeto. Isso ajudará o autor a enviar um PR saudável com uma descrição completa. Uma descrição de PR deve explicar qual é o propósito da mudança, a razão por trás dela e como reproduzi-la. Capturas de tela e links de referência (problema do Git, arquivo de design e assim por diante) são os toques finais para um envio autoexplicativo.

Fazer tudo isso evitará comentários antecipados de revisores pedindo mais detalhes. Outra maneira de fazer revisões de código parecerem menos meticulosas é usar linters para encontrar problemas de formatação de código e qualidade de código antes mesmo de um revisor se envolver. Sempre que vir um comentário repetitivo durante o processo de revisão, procure formas de minimizá-lo (sendo com melhores orientações ou automatização de código).

Fique um estudante

Qualquer pessoa pode fazer uma revisão de código e todos devem receber uma revisão de código — não importa o nível de experiência. Receba qualquer feedback com gratidão como uma oportunidade de aprender e compartilhar conhecimento. Veja qualquer feedback como uma discussão aberta em vez de uma reação defensiva. Como diz Ryan Holiday:

“Um amador é defensivo. O profissional acha prazeroso aprender (e até, ocasionalmente, aparecer); eles gostam de ser desafiados e humilhados, e se engajam na educação como um processo contínuo e sem fim. (...)”

— Ryan Holiday, Ego é o inimigo

Mantenha-se humilde porque no momento em que você deixa de ser um estudante, seu conhecimento se torna frágil.

A arte de selecionar revisores

Na minha opinião, escolher os revisores é uma das decisões mais importantes para uma revisão de código eficaz e saudável em equipe.

Digamos que seu colega esteja enviando uma revisão de código e decida marcar “todos” porque, inconscientemente, ele pode querer acelerar o processo, entregar o melhor código possível ou garantir que todos saibam sobre a mudança de código. Cada um dos revisores recebe uma notificação, abre o link PR e vê muitas pessoas marcadas como revisores. O pensamento de “alguém fará isso” surge em suas mentes, levando a ignorar a revisão do código e fechar o link.

Como ninguém iniciou a revisão ainda, seu colega lembrará a cada um dos revisores para fazê-lo, ou seja, pressionando-os. Uma vez que os revisores começam a fazê-lo, o processo de revisão leva uma eternidade porque cada um tem sua própria opinião e é um pesadelo chegar a um acordo comum. Enquanto isso, quem decidiu não revisar o código, é então bombardeado com zilhões de notificações por e-mail com todos os comentários de revisão, criando ruído em sua produtividade.

Isso é algo que vejo acontecendo mais do que gostaria: Pull Requests com um monte de pessoas marcadas como revisores e terminando, ironicamente, em uma revisão de código improdutiva.

Existem alguns fluxos eficazes comuns ao selecionar os revisores: Um fluxo possível é escolher dois ou três colegas que estejam familiarizados com o código e pedir que sejam revisores. Outra abordagem, explicada pela equipe do Gitlab, é ter um fluxo de revisão encadeado no qual o autor escolhe um revisor que escolhe outro revisor até que pelo menos dois revisores concordem com o código. Independentemente do fluxo escolhido, evite ter muitos revisores . Ser capaz de confiar no julgamento do código de seus colegas é a chave para conduzir uma revisão de código eficaz e saudável.

Tenha empatia

Identificar partes de código para melhorar é apenas uma parte de uma revisão de código bem-sucedida. Tão importante quanto é comunicar esse feedback de maneira saudável, mostrando empatia com seus colegas.

Antes de escrever um comentário, lembre-se de se colocar no lugar das outras pessoas. É fácil ser mal interpretado ao escrever, então revise suas próprias palavras antes de enviá-las. Mesmo que uma conversa comece a ficar feia, não deixe que isso afete você – sempre seja respeitoso. Falar bem aos outros nunca é uma má decisão.

Saiba como comprometer

Quando uma discussão não for resolvida rapidamente, leve-a para uma chamada ou bate-papo pessoal. Analisem juntos se é um assunto que vale a pena paralisar a solicitação de mudança atual ou se pode ser abordado em outra.

Seja flexível, mas pragmático e saiba equilibrar eficiência (entrega) e eficácia (qualidade). É um compromisso a ser feito em equipe. Nesses momentos, gosto de pensar em uma revisão de código como uma iteração em vez de uma solução final. Sempre há espaço para melhorias na próxima rodada.

Revisões de código pessoalmente

Reunir o autor e o revisor em um estilo de programação em pares pode ser altamente eficaz. Pessoalmente, prefiro essa abordagem quando a revisão de código envolve mudanças complexas ou há uma oportunidade para uma grande quantidade de compartilhamento de conhecimento. Apesar de ser uma revisão de código offline, é um bom hábito deixar comentários online sobre as discussões realizadas, especialmente quando as alterações precisam ser feitas após a reunião. Isso também é útil para manter outros revisores online atualizados.

Aprenda com os resultados da revisão de código

Quando uma revisão de código sofreu muitas alterações, demorou muito ou já teve muitas discussões, reúna sua equipe e analise as causas e quais ações podem ser tomadas a partir dela. Quando a revisão de código é complexa, dividir uma tarefa futura em tarefas menores facilita cada revisão de código.

Quando a lacuna de experiência é grande, adotar a programação em pares é uma estratégia com resultados incríveis – não apenas para compartilhamento de conhecimento, mas também para colaboração e comunicação off-line. Seja qual for o resultado, sempre busque uma equipe dinâmica e saudável com expectativas claras.

Como um autor

Uma das principais preocupações ao trabalhar em uma revisão de código como autor é minimizar a surpresa do revisor ao ler o código pela primeira vez. Esse é o primeiro passo para uma revisão de código previsível e suave. Veja como você pode fazer isso.

Estabeleça uma comunicação antecipada

Nunca é uma má ideia conversar com seus futuros revisores antes de codificar demais. Sempre que for uma contribuição interna ou externa, você pode fazer um refinamento juntos ou um pouco de programação em pares no início do desenvolvimento para discutir soluções.

Não há nada de errado em pedir ajuda como um primeiro passo. Na verdade, trabalhar em conjunto fora da revisão é um primeiro passo importante para evitar erros precoces e garantir um acordo inicial. Ao mesmo tempo, seus revisores ficam sabendo de uma futura revisão de código a ser feita.

Siga as Diretrizes

Ao enviar um Pull Request para revisão, lembre-se de adicionar uma descrição e seguir as diretrizes. Isso evitará que os revisores gastem tempo para entender o contexto do novo código. Mesmo que seus revisores já saibam do que se trata, você também pode aproveitar essa oportunidade como forma de melhorar suas habilidades de escrita e comunicação.

Seja seu primeiro revisor

Ver seu próprio código em um contexto diferente permite encontrar coisas que você perderia em seu editor de código. Faça uma revisão de código do seu próprio código antes de perguntar aos seus colegas. Tenha uma mentalidade de revisor e realmente passe por todas as linhas de código.

Pessoalmente, gosto de anotar minhas próprias revisões de código para melhor orientar meus revisores. O objetivo aqui é evitar comentários relacionados a uma possível falta de atenção e garantir que você seguiu as orientações de contribuição. Procure enviar uma revisão de código da mesma forma que gostaria de receber uma.

Ser paciente

Depois de enviar uma revisão de código, não vá direto para uma nova mensagem privada pedindo aos seus revisores para “dar uma olhada, leva apenas alguns minutos” e indiretamente desejando esse emoji de polegar para cima. Tentar apressar seus colegas para fazer o trabalho deles não é uma mentalidade saudável. Em vez disso, confie no fluxo de trabalho de seus colegas, pois eles confiam em você para enviar uma boa revisão de código. Enquanto isso, espere que eles voltem para você quando estiverem disponíveis. Não veja seus revisores como um gargalo. Lembre-se de ser paciente porque as coisas difíceis levam tempo.

Seja um Ouvinte

Uma vez que uma revisão de código é enviada, comentários virão, perguntas serão feitas e mudanças serão propostas. A regra de ouro aqui é não tomar nenhum feedback como um ataque pessoal. Lembre-se de que qualquer código pode se beneficiar de uma perspectiva externa .

Não olhe para seus revisores como um inimigo. Em vez disso, aproveite este momento para deixar seu ego de lado, aceitar que você comete erros e estar aberto a aprender com seus colegas, para que você possa fazer um trabalho melhor da próxima vez.

Como revisor

Planeje com antecedência

Quando lhe pedirem para ser um revisor, não interrompa as coisas imediatamente. Esse é um erro comum que vejo o tempo todo. A revisão do código exige toda a sua atenção e, cada vez que você muda de contexto de código, está diminuindo sua produtividade ao perder tempo recalibrando seu foco. Em vez disso, planeje com antecedência alocando intervalos de tempo do seu dia para fazer revisões de código.

Pessoalmente, prefiro fazer revisões de código logo de manhã ou depois do almoço antes de escolher qualquer outra das minhas tarefas. Isso é o que funciona melhor para mim porque meu cérebro ainda está fresco sem um contexto de código anterior para desligar. Além disso, quando terminar a revisão, posso me concentrar em minhas próprias tarefas, enquanto o autor pode reavaliar o código com base no feedback.

Seja solidário

Quando um Pull Request não segue as diretrizes de contribuição, seja solidário, especialmente com os recém-chegados. Aproveite esse momento como uma oportunidade para orientar o autor a melhorar sua contribuição. Enquanto isso, tente entender por que o autor não seguiu as diretrizes em primeiro lugar. Talvez haja espaço para melhorias que você não conhecia antes.

Confira a filial e execute-a

Ao revisar o código, faça-o rodar em seu próprio computador – especialmente quando envolve interfaces de usuário. Este hábito irá ajudá-lo a entender melhor o novo código e identificar coisas que você pode perder se você acabou de usar uma ferramenta de comparação padrão no navegador que limita seu escopo de revisão ao código alterado (sem ter o contexto completo como em seu editor de código) .

Pergunte antes de assumir

Quando você não entende algo, não tenha medo de dizer e fazer perguntas. Ao perguntar, lembre-se de primeiro ler o código ao redor e evite fazer suposições.

A maioria das perguntas se encaixa nesses dois tipos de categorias:

1. Perguntas “Como”
   Quando você não entender como algo funciona ou o que ele faz, avalie com o autor se o código está claro o suficiente. Não confunda código simples com ignorância. Há uma diferença entre o código que é difícil de ler e o código que você não conhece. Esteja aberto para aprender e usar um novo recurso de idioma, mesmo que você ainda não o conheça profundamente. No entanto, use-o apenas se simplificar a base de código.
2. Perguntas “Por quê”
   Quando você não entender o “porquê”, não tenha medo de sugerir comentários no código, especialmente se for um caso extremo ou uma correção de bug. O código deve ser autoexplicativo quando se trata de explicar o que ele faz. Os comentários são um complemento para explicar o porquê de uma determinada abordagem. Explicar o contexto é altamente valioso quando se trata de manutenção e evitará que alguém exclua um bloco de código que pensava ser inútil. (Pessoalmente, gosto de comentar sobre o código até me sentir seguro para esquecê-lo mais tarde.)

Crítica construtiva

Ao encontrar um trecho de código que você acredita que deve ser melhorado, lembre-se sempre de reconhecer o esforço do autor em contribuir com o projeto e se expressar de forma receptiva e transparente.

• Discussões abertas.
  Evite formalizar seu feedback como um comando ou acusação como “Você deveria…” ou “Você esqueceu…”. Expresse seu feedback como uma discussão aberta em vez de uma solicitação obrigatória. Lembre-se de comentar o código, não o autor. Se o comentário não for sobre o código, ele não deve pertencer a uma revisão de código. Como disse antes, seja solidário. Usar a voz passiva, falar no plural, expressar dúvidas ou sugestões são boas abordagens para enfatizar a empatia com o autor.
  

Em vez de “Extrair este método daqui…” prefira “Este método deve ser extraído…” ou “O que você acha de extrair este método…”

• Seja claro.
  Um feedback pode ser facilmente mal interpretado, especialmente quando se trata de expressar uma opinião versus compartilhar um fato ou uma diretriz. Lembre-se sempre de limpar isso imediatamente em seu comentário.

Pouco claro: “Este código deve ser…”

Opinião: “Acredito que este código deveria ser…”

Fato: “Seguindo [nossas diretrizes], este código deve ser…”.

• Explique por quê.
  O que é óbvio para você, pode não ser para os outros. Nunca é demais explicar a motivação por trás do seu feedback, para que o autor não apenas entenda como mudar algo, mas também qual é o benefício disso.

Opinião: “Acredito que este código pode ser…”

Explicado: “Acredito que este código poderia ser (…) porque isso melhorará a legibilidade e simplificará os testes de unidade”.

• Dê exemplos.
  Ao compartilhar um recurso de código ou um padrão com o qual o autor não está familiarizado, complemente sua sugestão com uma referência como orientação. Quando possível, vá além dos documentos do MDN e compartilhe um trecho ou um exemplo funcional adaptado ao cenário de código atual. Quando escrever um exemplo for muito complexo, seja solidário e ofereça ajuda pessoalmente ou por videochamada.

Além de dizer algo como “Usar filtro nos ajudará a [motivação]”, diga também: “Nesse caso, poderia ser algo como: [trecho de código]. Você pode verificar [um exemplo em Finder.js]. Qualquer dúvida, sinta-se à vontade para me enviar um ping no Slack.”

• Seja razoável.
  Se o mesmo erro for cometido várias vezes, prefira deixar apenas um comentário sobre ele e lembre-se do autor de revisá-lo nos outros lugares também. Adicionar comentários redundantes apenas cria ruído e pode ser contraproducente.

Mantenha o foco

Evite propor alterações de código não relacionadas ao código atual. Antes de sugerir uma mudança, pergunte-se se ela é estritamente necessária naquele momento. Esse tipo de feedback é especialmente comum em refatorações. É uma das muitas trocas entre eficiência e eficácia que precisamos fazer como equipe.

Quando se trata de refatorações, pessoalmente, costumo preferir melhorias pequenas, mas eficazes . Esses são mais fáceis de revisar e há menos chance de haver conflitos de código ao atualizar a ramificação com a ramificação de destino.

Definir expectativas

Se você deixar uma revisão de código pela metade, informe o autor sobre isso, para que as expectativas de tempo estejam sob controle. No final, informe também o autor se você concorda com o novo código ou se deseja revisá-lo novamente mais tarde.

Antes de aprovar uma revisão de código, pergunte a si mesmo se você se sente confortável com a possibilidade de tocar nesse código no futuro. Se sim, isso é um sinal de que você fez uma revisão de código bem-sucedida!

Aprenda a recusar uma revisão de código

Embora ninguém admita, às vezes você tem que recusar uma revisão de código. No momento em que você decide aceitar uma revisão de código, mas tenta apressar, a qualidade do projeto está sendo comprometida, assim como a mentalidade de sua equipe.

Quando você aceita revisar o código de outra pessoa, essa pessoa está confiando em suas capacidades – é um compromisso. Se você não tiver tempo para ser um revisor, apenas diga não ao(s) seu(s) colega(s). Eu realmente quero dizer isso; não deixe seus colegas esperarem por uma revisão de código que nunca será feita. Lembre-se de comunicar e manter as expectativas claras . Seja honesto com sua equipe e – melhor ainda – consigo mesmo. Seja qual for a sua escolha, faça-o de forma saudável e faça-o bem.

Conclusão

Com tempo e experiência suficientes, fazer revisões de código ensinará muito mais do que apenas conhecimento técnico. Você aprenderá a dar e receber feedback de outras pessoas, bem como a tomar decisões com mais reflexão.

Cada revisão de código é uma oportunidade de crescer como comunidade e individualmente. Mesmo fora das revisões de código, lembre-se de promover uma mentalidade saudável até o dia em que isso acontecer naturalmente para você e seus colegas. Porque compartilhar é o que nos torna melhores!

Leitura adicional no SmashingMag:

• Trabalhando juntos: como designers e desenvolvedores podem se comunicar para criar projetos melhores
• Melhor colaboração ao trazer designers para o processo de revisão de código
• Quais Podcasts Web Designers e Desenvolvedores Devem Ouvir?
• Como criar o currículo de desenvolvedor web perfeito