Realização do CR/Teste integrado

Hora de trabalhar.

É aqui que o trabalho de CR começa.

Um processo de CR completo, é composto de duas partes:

• O Code Review em si:

  • O código em si deve ser analisado com bastante carinho e cuidado, sempre se guiando pelo guia de boas práticas do projeto. Qualquer desvio das práticas acordadas, deve ser comentado na PR, indicando para o autor esse ponto de atenção, para que o mesmo seja corrigido;

  • Além disso, as boas práticas da stack/tecnologia/framework devem ser avaliadas também, garantindo assim a qualidade e a padronização dos códigos;

  • Caso a PR contenha muitos itens fora de conformidade, o melhor caminho a ser tomado é rejeitar a PR, comentando alguns casos, e chamar o autor da mesma em particular, passando sua percepção a ele, assim vocês podem debater juntos as soluções, e isso pode virar um momento de troca de experiências bem bacana para o time como um todo.

• Os testes integrados:

  • Uma vez superada a fase da revisão de código, é hora de testarmos o que nossos colegas fizeram e querem subir;

  • O processo recomendado aqui é:

    • Baixe a branch do PR em sua máquina;

    • Execute as orientações contidas nela, por exemplo: rodar migrations, criar entradas no .env, rodar "npm i", etc;

    • Caso existam, e sempre devem existir, rode os testes unitários. Caso estes falhem, já pode rejeitar a PR, sinalizando isso na mesma, como comentário;

    • Com tudo rodando como deveria, se guie pelo card anexo/indicado na PR, e teste realmente a feature/fix contido nele, como se fosse um usuário, ou um analista de QA;

    • Estando tudo correto, aprove a PR e notifique o autor. Caso negativo, sinalize na PR, como comentários, rejeite a PR e notifique o autor também, para que os problemas possam ser corrigidos;

    • Prints, mensagens de erro e outras evidências sempre são bem vindas em todos os casos, de aprovação e de rejeição.

Com este etapa vencida, temos agora apenas dois caminhos possíveis: aprovação ou rejeição da PR.