Se você quer a resposta sem ler, bem, aqui está. Existem muitos propósitos, mas o mais importante é que você e seus revisores identifiquem explicitamente quais deles são importantes para você. Espero que você continue lendo de qualquer maneira.

A revisão de código é uma prática aceita no desenvolvimento de software moderno. Em minha carreira, sempre foi pregado como evangelho, mas cada vez mais descobri que o “porquê” sempre foi nebuloso. Existem muitos motivos excelentes, mas cada vez que pergunto a uma nova pessoa (especialmente se ela tiver experiência em empresas e equipes diferentes), recebo uma resposta um pouco diferente. Vamos mergulhar.

O que é Revisão de Código?

A revisão de código é a prática de ter mais de uma pessoa examinando um trecho de código. Normalmente, uma pessoa escreve o código e outra revisa o código posteriormente. Às vezes, a segunda pessoa assina o código antes que ele chegue à base de código. Às vezes, a segunda pessoa olha para ele mais tarde. Às vezes, duas ou mais pessoas fazem um programa de pares.

Muitas vezes, o revisor é mais experiente que o escritor, mas nem sempre. Às vezes, a pessoa menos experiente revisa.

Por que fazer revisão de código?

Em última análise, todas essas razões se resumem a uma tese “Dois olhos é melhor do que um”. Ou “quatro olhos é melhor do que dois”, suponho… a menos que você seja um ciclope escrevendo código, mas você entendeu. Mas isso vem com um custo. Quatro olhos são mais caros do que dois (tempo/dinheiro/etc). Vamos detalhar exatamente por que quatro olhos são melhores que dois. Estes vêm de minha pesquisa informal com pessoas que conheço no campo.

• Ajuda a espalhar o conhecimento em uma equipe
• Ajuda a evitar pontos únicos de falha
• Ajuda a encontrar bugs de baixo nível em trechos de código arriscados
• Ajuda a validar decisões arquitetônicas de alto nível no código
• Os seres humanos naturalmente fazem um trabalho melhor escrevendo código se souberem que outra pessoa vai olhar para ele e julgá-lo por isso.
• Dá aos engenheiros mais novos a chance de ver como os engenheiros seniores escrevem o código.
• Ajude a evitar que engenheiros mais novos causem problemas por acidente
• Dá aos engenheiros seniores a chance de supervisionar/bloquear o código
• Para passar na auditoria. Muitos padrões de conformidade exigem que várias pessoas aprovem cada parte do software implantado.

Acredito que a parte mais importante da revisão de código é ser explícito sobre qual é o objetivo. Se há um take away, é este.

Não há nada mais frustrante do que receber feedback no nível errado de altitude. Obter uma revisão cheia de detalhes quando a ideia geral é ruim. Por outro lado, obter uma revisão informando que sua arquitetura geral é ruim, quando você já sabe disso e a está escolhendo propositalmente por algum outro motivo (por exemplo, para economizar tempo).

É responsabilidade do revisor e do avaliado garantir que a altitude seja explícita e acordada. Se você não estiver alinhado com isso, quase por definição você não concordará com os resultados e a revisão não irá bem. Não há uma regra rígida e rápida sobre quem deve fazer isso, mas algumas boas regras práticas

• O engenheiro mais experiente tem mais ônus para escolher a altitude
• A pessoa com mais conhecimento sobre esta parte da base de código deve escolher a altitude
• A pessoa com mais responsabilidade pelas consequências deve escolher a altitude (o proprietário)

Como aquele que revisa o código, tente ser explícito sobre o nível de altitude que deseja alterar. Observe que pode ser difícil responder a isso até que você conclua a revisão. É uma boa prática redigir uma revisão, depois decidir a altitude e, em seguida, editar o rascunho da revisão. Por exemplo, livre-se de seus comentários nit se a abordagem estiver errada.

Se você ainda achar que a revisão é frustrante, vire a cadeira ou pegue o telefone e fique na mesma página sobre altitude!

Melhorando na engenharia por meio da revisão

Em um relacionamento de revisão sênior/júnior (em qualquer direção), pode ser uma maneira realmente valiosa de melhorar a engenharia! Essas revisões não são apenas sobre o código em questão, mas também sobre habilidades de aprendizado. Nesses cenários, se você puder fazer o desvio, geralmente vale a pena dedicar um pouco mais de tempo apenas para aprender.

Também descobri quando estava no início de minha carreira, que era realmente valioso colocar mais esforço do que o necessário em minhas descrições de relações públicas e minha configuração de altitude - resumindo muito bem mesmo em revisões onde provavelmente não era necessário. Eu estava mal calibrado em quais partes importavam, e o esforço extra realmente ajudou meus colegas de trabalho mais antigos (que também estavam ocupados) e me ajudou a melhorar.

Pular revisão

Se nenhum dos motivos acima parecer realmente atraente, pode ser bom ignorar a revisão em sua organização. Talvez todos sejam iguais, pontos únicos de falha são toleráveis ​​ou as apostas são baixas e a velocidade é fundamental. Há casos em que isso é útil, então é definitivamente uma opção na mesa.

Adorei trabalhar em organizações com revisão de código opcional, onde quem escreve o código é responsável por tomar a decisão. Se eu decidir pular a revisão e isso causar um problema sério, sinto que decepcionei todo mundo, o que honestamente é um grande motivador para fazer um bom trabalho. Isso me permite decidir o quanto estou confiante em um PR, que é uma habilidade importante do inglês.

Continue lançando código!