👼 👨🏿‍🌾 🤱🏿 Revisão de código Terminator. Revisão pela qual você será agradecido 🐯 🚶🏿 🏦

^{Ginger me ajuda a revisar o código. E quando ele não gosta de algo - também um verdadeiro Terminator,}

"Code review Terminator", um colega me chamou uma vez após uma revisão particularmente produtiva. Por um lado, entreteve a República Tcheca e foi agradável. Por outro lado, um colega realmente aprendeu algo novo, e isso lhe permitiu escrever um código melhor. Então, ganha-ganha.

Após a mudança de trabalho, os colegas também mudaram. Mas em um novo local também começaram a agradecer pela revisão. Decidi descobrir o porquê e colocá-lo nas prateleiras. Descobriu-se 11 recomendações.

1. Trate a revisão como uma das principais atividades

Deixar alguns comentários como "E então não há verificação nula suficiente" não é suficiente. É necessário:

Descobrir o que precisava ser feito
Entenda como foi feito
. ( , , )?
, , . — , .

2.

Uma coisa é sentar ao lado de um colega e discutir algo, olhando para uma tela. Outra coisa é revisar o código no github ou bitbucket. É fácil entender mal as intenções de um colega quando a comunicação ocorre em texto. Pegue a frase "Há um erro nesta linha". Sim, é claro que a frase diz que o artigo tem um bug. Mas ela podia ser contada com emoções diferentes: raiva, surpresa, alegria por o bug ter sido pego e não ter entrado em produção. Ou talvez com indiferença.

Seu colega pode entender mal suas intenções - e isso leva a ressentimento, tensão na equipe e geralmente é uma porcaria.

Facilite sua vida: suavize a frase, transforme-a em uma pergunta ou talvez adicione uma carinha sorridente.

3. Aloque tempo

Para garantir que o código funcione corretamente e corretamente, você precisa entendê-lo completamente. E isso leva tempo; certifique-se de destacá-lo o suficiente. Lembre-se de que revisar partes do aplicativo que você não conhece levará ainda mais tempo.

Em geral, esse é o outro lado das boas críticas: é demorado. Se você não tiver tempo para fazê-lo bem, tente adiar ou nomear outra pessoa (soa como o conselho de um procrastinador, mas as situações são diferentes). Se isso não for uma opção, mas você precisar fazer uma revisão - lembre-se de sacrificar a qualidade. Embora necessário, mas um compromisso. Se você transformá-lo em um hábito, receberá mais dívidas técnicas no futuro.

4. Não faça suposições; perguntar

Quando você encontrar um código estranho ou uma solução excessivamente complexa para uma tarefa aparentemente simples, não assuma por padrão que um colega cometeu um erro ou uma má escolha. Talvez ele esteja ciente de algumas circunstâncias que você não conhece. Você pode simplesmente esclarecer e evitar o risco de situações desconfortáveis e estressantes se culpar injustamente alguém. Por exemplo: “Talvez você possa usar essa classe aqui? Pelo que entendi, ele seria um bom ajuste aqui e isso seria mais fácil do que a implementação proposta. ”

5. Capture situações em que você precisa entrar em contato diretamente

Normalmente, as revisões são executadas de forma assíncrona. Assim, você pode mergulhar no código e distrair menos seu colega. Mas, em algumas situações, é melhor entrar em contato diretamente (subindo ou ligando):

Quando os prazos estão se esgotando. O feedback rápido acelera as decisões. Mas ordenadamente: com prazos e tudo o mais, tudo está armado, e as distrações vão incomodar e reduzir a concentração.
Erros grosseiros. Discuti-los publicamente pode ser muito embaraçoso e frustrante para alguém. É melhor conversar pessoalmente e explicar o problema. Talvez seja apenas um descuido ou talvez uma lacuna de conhecimento - que agora está preenchida.
Abordagem completamente errada selecionada. Para dizer a uma pessoa que você precisa jogar fora seu trabalho, você precisa ter cuidado. É melhor usar a linguagem corporal e a entonação para transmitir esclarecimentos sem ofensas.

Bem, é uma boa ideia adicionar um resumo da conversa ao sistema de revisão.

6. Leia o ticket primeiro

Alguns dos requisitos podem não estar cobertos por uma solicitação de recebimento aparentemente correta. Para evitar isso, basta ler a declaração do problema primeiro. Ao mesmo tempo, isso ajudará a entender o que geralmente está acontecendo nas mudanças.

7. Justifique suas sugestões

Alguns erros (erros de digitação, por exemplo) não precisam de explicação. Mas se você oferecer uma solução arquitetônica alternativa ou outro nome - explique as vantagens e desvantagens de ambas as opções. O que parece óbvio para você pode não ser completamente óbvio para outras pessoas.

Além disso, há um provérbio: “Dê a um homem um peixe e você o alimentará por dia. Ensine-o a pescar e você o alimentará por toda a vida. Quando você ensinou a um colega uma nova abordagem, ele poderá usá-la no futuro e escrever melhor o código. Ao mesmo tempo, a qualidade do projeto também melhorará como um bônus.

8. Elogie boas decisões

Uma revisão não precisa ser uma lista de erros. Se você viu um bom lugar, uma solução interessante, um método útil - conte-me. Um breve comentário "Decisão legal" pode melhorar o humor de uma pessoa durante todo o dia. Sim, e não elogie as solicitações ruins: é tenso e destrói o significado da ideia.

9. Seja educado

Dica: uma frase como " Podemos nos livrar do estilo estúpido de sintaxe de comentário em rede danificado pelo cérebro? " um certo tipo de comentário, por uma questão de cortesia, adicionando "por favor").

10. Ajuda

Se durante o processo de revisão você analisou vários arquivos e, como resultado, encontrou uma solução alternativa - descarte os links do colega para esses arquivos. Você pode até com números de linha, é ainda mais conveniente. Não será necessário muito esforço, mas um colega pode economizar muito tempo.

11. Sugira, não indique

Quando você propõe uma abordagem diferente para a revisão - não peça ao seu colega, por ordem, para usar sua opção. Argumente e deixe seu colega decidir. Muito provavelmente, ele seguirá o seu conselho. E se não, qual poderia ser o motivo?

Ambas as abordagens são praticamente as mesmas. Se não houver motivos objetivos para a escolha de uma nova abordagem, não haverá motivo para perder tempo e aplicá-la. Isenção de responsabilidade: a uniformidade do código é uma razão objetiva.
Há uma razão objetiva pela qual sua abordagem é melhor. Mas, por alguma razão, o autor do código não o entende. Revise seu argumento, explique novamente - e ao mesmo tempo verifique se você está enganado.
Conflitos pessoais. Este é um gelo escorregadio e você precisa agir aqui com cuidado. E isso já está além do escopo do tópico de revisão.

Isso é tudo. Resumindo:

faça o mundo ao seu redor um pouco melhor. Faça boas críticas.

UPD. Este artigo é uma tradução gratuita do meu original em inglês . Convertido de "tradução" para "artigo" para não confundir os leitores.

Revisão de código Terminator. Revisão pela qual você será agradecido