Skip to main content

Pull Request

Nesta sessão esta descrita os combinados para se abrir e revisar uma Pull Request, tanto para Front quanto para Backend.

🔤 Nomenclatura​

É interessante deixar claro qual a task à qual a PR se refere.

⏰ Tempo de vida​

Uma PR que foi aberta há muito tempo acaba perdendo seu valor, pois o código de seu repositório provalvemente já foi alterado inúmeras vezes. Dessa forma, é importante que o tempo de vida de uma PR não ultrapasse 1 semana. Caso isso ocorra, a PR deve ser deletada ou movida para draft. Isso não significa que a branch deva ser deletada, mas que a feature/fix daquela PR não esta mais priorizada, logo fora do nosso campo de visão.

👩‍💻 Responsabilidade​

A Pull Request é de total responsabilidade do desenvolvedor que a abriu ou aquele que a atribuiu, dessa forma, cabe a essa pessoa, cobrar os revisores, e tomar a decisão junto a eles de mergear ou fechar a PR em questão.

Outro ponto importante: para que sua PR seja aprovada com maior qualidade, evite abrir PRs para que sejam aprovadas no mesmo dia. Sempre que possível tente antecipar a abertura da PR mesmo que as especificações técnicas mudem ou não estejam 100%, assim ja é possível verificar possíveis bugs por outros desenvolvedores. Isso não se aplica a bugs críticos ou demandas de última hora.

Lembre-se que os outros devs provavelmente irão reservar o inicio do dia ou final do expediente para ver as PRs, tenha isso como guia para saber quando sua PR será revisada.

👀 Revisores​

É importante incluir todos os membros do time impactado para revisar o código, no entanto não é necessário que todos os adicionados aprovem a PR. Busque que ao menos 2 pessoas revisem o código, e caso ainda não esteja confortável em mergear por falta de revisões, acione as pessoas que gostaria do review de forma direta ou marcando em algum grupo.

Para adicionar revisores a sua PR, basta ver a sessão Reviewers na centro-direita da página do Github.

image

Assim que seus revisores pedirem as correções, e elas forem feitas, não se esqueça de pedir a revisão novamente.

✍️ Descrição​

A descrição da PR provalemente é a parte mais importante na abertura. Dessa forma, deve conter:

  • Qual a motivação/objetivo
  • O que foi feito
  • Como testar (caso aplicável)
  • Imagens de layout antes e depois (aplicável para frontend)
  • Link do preview (aplicável para frontend)
  • Link do Jira

Lembre-se que não necessariamente seus revisores conhecem a natureza da task.

📋 Revisar​

Esta é uma tarefa muito importante e deve fazer parte do cotidiano de todo desenvolvedor sallve.

⏰ Reserve sempre um horário pela manhã e no final de seu expediente para revisar as PRs dos colegas. 30 min em cada período deve ser o suficiente.

Para uma boa revisão, é importante entender minimamente o contexto da PR, dessa forma a descrição se faz importante.

Em ambos os contextos, back e front, é importante que:

  • Os padrões de código estejam de acordo com boas práticas, como código em inglês, nomes de variáveis/constantes inteligíveis. Como não temos formalizado as boas práticas, estando sempre em constantes mudanças, qualquer sugestão de melhoria é super bem vinda.
  • O Github tenha aprovado o Actions e a PR esteja atualizada com a master

Para o caso de front:

  • Entre no preview e teste as mudanças
  • É importante testar no mobile, seja usando a resolução mobile do próprio browser, ou testando pelo seu smartphone
  • Teste em browsers diferentes
  • Utilize a ferramenta LamdbaTest para testar em outros sistemas operacionais/browsers também

Para o caso de backend:

  • Se possível, faça o download da branch em questão e realize testes localmente.

✅ Boas práticas e links úteis​

Sempre que abrir uma PR, avise o time que a mesma foi aberta, deixando o link da PR para que a revisão seja feita.

  • Grupo back no slack: aceita-pr
  • Grupo front no slack: prs-frontend

Deixe salvo os seguintes links para faciliar a busca por PRs que solicitaram sua revisão e PRs de sua autoria: