Neste artigo irá encontrar:
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ê.
