O guia de revisão de código.

As revisões de código são uma prática comum na indústria de tecnologia. Quando você faz um Pull Request / Merge Request, alguém tem que revisar, comentar e aprovar quando estiver pronto para fazer parte do branch master, se esse for o branch que o RP está almejando, é claro.

Quando você for um revisor pela primeira vez, talvez já tenha aprendido um pouco com o feedback que recebeu. Não tenha medo, não é grande coisa. As revisões de código também são feitas para o aprendizado. Você não está atacando seus companheiros de equipe, não é pessoal. Você está questionando o código deles, procurando maneiras de melhorá-lo.

Lembre-se de que as revisões de código não são usadas apenas para saber o que está errado, mas também para aprender com os erros.

Com essa mentalidade, vamos ver como fazer isso:

Tenha contexto

Cada PR tem um propósito. Pode ser parte de uma proposta, uma correção de bug, um novo recurso, etc. Certifique-se de ler e compreender o título do RP antes de examinar o código. Isso lhe dará uma noção  melhor do que irá revisar e pode ajudá-lo a ver quais arquivos foram modificados para fornecer mais contexto de seu escopo.

Certifique-se de que os arquivos modificados fazem parte do que o RP deve fazer (as vezes um arquivo pode ser carregado por engano )

Você também pode ler: Competências transversais que fazem a diferença

Ok, já sabemos o que o PR deve fazer. Vamos ver o código. Você pode revisá-lo usando duas abordagens: legibilidade e funcionalidade.

Independentemente de qual abordagem você escolher, sempre tenha estas duas perguntas em mente:

• Como  poderia melhorar isso?
• O que poderia dar errado?

Revendo por  legibilidade

Talvez esta seja a maneira mais superficial de começar a revisá-lo, mas garante que o código será facilmente mantido ao longo do tempo. Caso  não consiga entender esse código agora, em um ano também não conseguirá entendê-lo.

Cada código escrito tem um preço: manutenção. Faça um favor aos outros e verifique com atenção.

Estas são algumas das coisas que você pode verificar:

• Procure por erros tipográficos, eles acontecem o tempo todo, nos nomes das variáveis ​​e funções, nas descrições dos comentários ou mesmo nos nomes dos arquivos;
• Que a classe e as funções sejam bem nomeadas. A responsabilidade pelo papel é conhecida;
• Comentários descritivos e bem escritos. Isso não significa que deva ser longo, mas sim assertivo;
• Consistência. O código não é escrito como uma parte isolada no repositório. Certifique-se de que é consistente com as práticas. Tente se certificar de que o código que você está revisando está alinhado com o todo.

Por exemplo, isso acontece com estes tipos de casos:

Veja que todo o código tem harmonia e que a peça que você vai adicionar não faz barulho.

• Não imprima declarações. Talvez  tenham sido esquecidasdurante a depuração.
• Evite instruções aninhadas desnecessárias.
• Retorne o feedback o mais rápido possível.

Se você vir um código como este:

Puedes refactorizar haciendo esto:

Sugira o que você achar necessário para que o código seja melhor compreendido.

Analise a funcionalidade

Como revisor, você também é responsável pela qualidade do código que a empresa envia para produção. Preste atenção aos detalhes, escalabilidade e principalmente segurança.

• O fluxo faz sentido?
• Existem validações desnecessárias, loops ou algum outro detalhe?
• Responsabilidade exclusiva pelos métodos e aulas. Portanto, os testes podem ser mais atômicos.
• É suscetível a falhas? Por exemplo, certifique-se de verificar o comprimento do array antes de acessá-lo. Ou pelo menos certifique-se de que não terminará em erro -NullPointer alert-
• Como eu teria feito isso? É melhor do meu jeito? Essa lógica poderia melhorar a atual?
• Os testes não mudam sem motivo. Por exemplo, se o teste foi usado para validar que a função não retorna um erro, mas depois válida que a função retorna um erro, pergunte-se o porquê. Podem haver mudanças importantes que afetam a operação.
• Não apague provas sem motivo. Pergunte-se o porquê , se você não entende por qual motivo  o teste foi removido. Já não é necessário? Por que?
• A evidência é suficiente para atender ao impacto da mudança. E também, verifique se os testes estão dizendo o que devem.

Você também pode ler: Você que é empreendedor, já ouviu falar sobre o Business Email Compromise?

O que devo fazer se não souber o idioma do código?

Este é um clássico: Você não conhece uma determinada linguagem de codificação ou tecnologia mas precisa revisá-la.

Primeiro, não tenha medo. Certifique-se de que os outros revisores conheçam o idioma, pois  podem detectar coisas que você não pode. E tire dúvidas,  se necessário.

Um bom ponto de partida é uma revisão superficial - procure erros de digitação e nomes de variáveis.

Se quiser,  poderá procurar outro código no repositório da mesma linguagem e tentar descobrir padrões. Lembre-se sempre,  você pode perguntar se algo não estiver claro.

--------------------

E a dica mais importante: não siga as "Melhores Práticas" cegamente. Sempre pense primeiro. Cada parte do código tenta agregar valor ao produto. Portanto pense em como isso poderia agregar valor e tornar a vida mais fácil para o desenvolvedor que manterá esse código mais tarde. Talvez seja você.