Pull request / Melhores práticas
Tags: pullrequest, git, codereview
Published: 2022-10-31 20:03:48

## Por que se importar com bons pull requests?

* Aumentar a produtividade do time
* Minimizar a frustração

Também:

* Um bom pull request tende a ser revisado rapidamente;
* Reduz introdução de bugs na base de código;
* Facilita a integração de novos desenvolvedores;
* Não bloqueia o trabalho de outros devs;
* Acelera o processo de revisão de código e consequentemente o desenvolvimento do produto.


## Boas práticas:

### Anatomia na criação de PRs

* **_Target_ e _source_ branches**
feature/x --> development --> master
_source_ㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤㅤ_target_

* **Tamanho**
Evite PRs extensos. Procure abrir um pull request com poucos arquivos e linhas de código

* **Título e descrição**
Forneça uma visão geral do seu trabalho juntamente com os links relevantes de forma que uma pessoa que acabou de entrar no time entenda.

### Tenha em mente quando estiver recebendo ou dando feedback:

* **Um mesmo problema pode ter mais que uma boa solução**. Discuta os _tradeoffs_ (pros e contras), riscos, impacto e chegue à um consenso rapidamente.

* Faça boas perguntas, **não crie demandas**. Boas perguntas **evitam julgar** a perspectiva do autor.

* Não faça suposições, peça esclarecimentos.

* Evite propriedade seletiva de código. ("meu", "não é meu", "seu" código)

* **Seja humilde e respeitoso** para manter o ambiente real e profissional. De modo geral, evite termos que podem ser levados pro lado pessoal. Se emoji, GIFs ou humor não fazem o teu estilo, não force. Se fazem, use ~~e abuse~~.

* **Fale sincronamente** (chat, compartilhando tela, pessoalmente) se você tem muitas dúvidas ou sugestões. Depois, faça um comentário resumindo a discussão.

* Mencione colegas ou times que você queira envolver na discussão e mencione o porquê. (@fulano, tem alguma sugestão quanto à essa abordagem?)


### Dando feedback:

* **Respeite o tempo da pessoa**. Revise o mais rápido que puder. Seu colega pode iniciar outra tarefa e pode ser difícil para ele voltar à _task_ do PR se você incluir alguns comentários.

* Fique atento ao **viés negativo** (se o conteúdo é neutro, assumimos que o tom é negativo) na comunicação online. Sempre conceda **feedbacks positivos**. Evite linguagem negativa/neutra e prefira a positiva.

```
✅ Prefira:
"Eu sugiro X" ou "Você pode melhorar X fazendo Y"

❌ Evite: 
"Faz X" ou "X é errado, por que você não faz Z?"
```

* **Não mude o código** enquanto estiver revisando.

* **Use uma checklist** para tentar capturar algum deslize, erro, violação de convenção, risco de performance e etc.

* Se você discorda fortemente, considere tirar alguns minutos para **refletir antes de responder**.

* **Explique os motivos** pelo qual você acredita que o código deve ser alterado. Por exemplo: o código não está de acordo com o _style guide_ ou até com uma preferência pessoal.

* Forneça maneiras de simplificar ou aprimorar o código.

* Se as discussões ficarem muito filosóficas ou acadêmicas, mova a discussão para uma **reunião técnica** relacionada ao assunto. Então, deixe o autor tomar a decisão final sobre as soluções alternativas.

* **Foque em desenvolver _skills_ profissionais**, conhecimento do grupo e a qualidade do produto, através da crítica coletiva.

* **Use emojis** para esclarecer o tom. Compare "Parece bom :)" ou "Parece bom! 👍" com "Tá bom."


### Respondendo feebacks:

* **Agradeça** as sugestões. "Valeu! Vou alterar isso."

* "**Não leve pro pessoal**. O que está sendo revisado é o seu código, não você". Assuma que o revisor teve a melhor intenção em seus comentários e tenha em mente o quão difícil é transmitir emoções online. 

* **Explique a razão do código existir.** "Fiz desse jeito, por causa disso, disso e disso. Seria mais claro se eu renomeasse essa classe/arquivo/método/variável?".

* Caso encontre possibilidade de mudança ou refatoração, **registre-as em _tasks_ futuras** e histórias.

* Tente responder todos os comentários.

* Se perceber alguma confusão ou debate começando, **se pergunte se o que você escreveu foi escrito da melhor maneira**. Converse (virtualmente) face a face, então considerem criar um comentário para resumir o que conversaram.

* Faça o _merge_ somente quando você tiver **confiante** e o seu sistema de integração contínua mostrar que os **testes e _builds_ estão OK**.


### Resolvendo conflitos

* Exija ao menos **2 revisores de código**.

Eventualmente o autor do PR e o revisor poderão discordar. Isso é **perfeitamente normal** e na verdade é um sinal de uma **boa dinâmica de time**. Entretando, o que não é normal é ter discussões intermináveis ou um desenvolvedor passar por cima do outro por preferências pessoais, senioridade, acessos, etc.

É bom se prevenir dessas situações e ter uma **estratégia para resolver conflitos**. Um bom método é ter pelo menos 2 revisores. Nesses casos, é simplesmente a solução do voto da maioria que será aderida.

Traduzido e adaptado de:

[Best practices for reviewing pull requests](https://rewind.com/blog/best-practices-for-reviewing-pull-requests-in-github/)
[Pull request best practices](https://leoneperdigao.medium.com/pull-request-best-practices-fa20f7daeb3c)