Guia de boas práticas para revisão de código

Guia de boas práticas para revisão de código. Inspirado, entre outros, no guia da thoughtbot.

Benefícios

Antecipação de bugs
Maior manutenibilidade do código
Legibilidade do código
Compartilhamento de conhecimento
- Tanto em relação à feature que está sendo implementada quanto às técnicas que foram usadas

Aceite que muitas decisões de programação são opiniões. Discuta as opções, as preferências e cheguem em um consenso rapidamente.
Questione, não exija. ("O que você pensa sobre chamar esse campo de user_id?")
Se você não entender o que está lendo, pergunte. ("Não entendi, você poderia explicar?").
Evite palavras que sugiram culpa ou responsabilidade pelo código. ("seu", "meu", "não é meu").
Não seja grosseiro ou ofensivo.
Seja explícito e claro. Nem sempre as pessoas entenderão o que você quis dizer.
Seja descritivo sobre as suas intenções. Descreva as mudanças propostas e faça comentários claros.
Forneça referências para ajudar a esclarecer as decisões tomadas. ("Acredito que seja melhor alterar a ordem desses middlewares (https://docs.djangoproject.com/en/1.8/topics/http/middleware/#hooks-and-application-order)")
Seja humilde e sincero. ("Não tenho certeza, vou conferir").
Não use hipérbole. ("sempre", "nunca", "interminavelmente", "nenhum").
Não seja sarcástico.
Não force a barra. Se emojis, gifs ou piadinhas não fazem o estilo, não tente forçar. Caso contrário, use-os com bom senso.
Se a discussão não avançar, converse pessoalmente. Coloque nos pull requests um resumo do que foi conversado e decidido.
Siga as guidelines existentes. Siga a ordem de importância do mais próximo ao mais geral (equipe -> projeto -> organização).

Antes de revisar, entenda porque o código escrito é necessário (_bug, feature ou refactor).
Verifique se o código faz o que foi proposto na descrição do pull request.
Verifique se o pull request possui um link a algum ticket ou issue. Verifique também se o código resolve o problema que está no ticket ou issue.
Comente quaisquer problemas/questões que forem encontradas, por mais simples ou bobos que pareçam. Isso incentiva outros desenvolvedores a fazerem o mesmo.
Comente os pontos que você discorda (ou mesmo os que você concorda fortemente).
Identifique formas de simplificar o código e ainda assim continuar resolvendo o problema.
Se as discussões se tornarem muito filosóficas ou acadêmicas, move a discussão para outro lugar (talvez uma sexta-feira em um bar). Nesse meio tempo, cheguem a um consenso sobre a solução.
Ofereça alternativas aos problemas encontrados. ("O que você acha de usar um validador próprio nessa classe?").
Tente entender a perspectiva do autor.
Use o bom senso.
Comente no pull request com um 👍 quando tiver finalizado.

Certifique-se que seu código está de acordo com as guidelines do projeto (geralmente especificadas no arquivo CONTRIBUTING.md), caso não esteja, proponha melhorias nas guidelines, não force o aceite do código caso não esteja de acordo.
Seja grato pelas sugestões dadas. ("Boa, vou alterar" ou mesmo um simples 👍).
Não tome a revisão como pessoal. A revisão é sobre o código, não sobre você.
Explique porque o código existe. Dê os motivos para as decisões tomadas e discuta as soluções e sugestões.
Extraia mudanças, refatorações e dívidas técnicas grandes em futuros tickets ou issues.
Coloque links para tickets ou issues relacionados.
Faça commits separadamente se baseando nas soluções obtidas através da revisão. Não faça nenhum squash até que o pull request esteja revisado e pronto para merge.
Tente entender a perspectiva do revisor.
Responda a todos os comentários.
Só faça merge após a revisão e após as ferramentas de CI (TravisCI, por exemplo) sinalizarem que está tudo ok com o pull request.
Faça merge quando houver confiança sobre o código e o seu impacto no projeto.

Recomendamos fortemente a leitura dos artigos de referência.