Antes do Pull Request
Esse é um post sobre como criar Pull Requests melhores. Nele, pontuo algumas estratégias relativamente simples, que ajudam muito o seu time a colaborar de forma mais efetiva. Para esclarecer, Pull Requests também são conhecidos como Merge Requests em algumas ferramentas.
Antes mesmo de inciar a criação do seu Pull request, é importante ter algumas coisas em mente.
Testes automatizados
Decidi deixar esse item como primeiro topico desta seção, pois acredito que ela é uma das coisas mais importantes e necessárias que compõem um bom PR.
Colaborar em um projeto com mais desenvolvedores pode se tornar algo muito complexo e desafiador, pois cada pessoa pode exergar o projeto de uma forma diferente, principalmente se a pessoa desenvolvedora acabou de chegar no seu time.
Além dos testes manuais, testes automatizados são uma forma de garantir que o seu código faz exatamente o que ele deveria fazer, e que essas funcionalidades permaneçam fazendo isso mesmo depois de diversas mudanças. Em códigos sem cobertura de testes, é comum nós alterarmos X e quebrar Y em produção, mesmo que em teoria, essas features nem se conectem. Se você já trabalhou em projetos sem testes, deve saber do que eu estou falando.
Commits
Algumas equipes criam diretrizes para mensagens de commit, mas este tópico nem é sobre isso. Eu criei ele neste post para te lembrar de criar bons commits, que mantenham um histórico das suas mudanças e com mensagens que descrevam tais mudanças. Commits são tão importantes quanto o Pull Request em si. Se você tiver interesse em melhorar suas mensagens de commit, eu recomendo esse artigo.
O que deve conter em um PR
Solucione um problema por vez. Se você estiver solucionando uma feature, limite o escopo da mesma, pois isso facilitará a revisão e o histórico de mudanças ficará mais claro.
Diretrizes
É provavel que sua equipe tenha configurado tarefas automatizadas para verificar testes, lint, tipos estáticos, mensagens de commit e outros parâmetros para garantir a qualidade de código do projeto, e claro, manter o mesmo mais organizado.
Por isso, se possível, tente executar os processos de verificação de qualidade antes de executar git push. Mas não se preocupe, se você esquecer, a Pipeline irá avisar.
Tamanho do Pull Request
Muito se questiona sobre o tamanho ideal para um Pull request, mas a verdade, é que depente (como muitos assuntos no desenvolvimento de software).
Você pode ter estratégias diferentes de acordo com o tamanho e nível de maturidade do seu time, ou até com as tecnologias que vocês utilizam. Mas gostaria de adicionar um link para esse artigo, que explica o tamanho ideal para PRs e menciona alguns estudos a respeito desse tema.
Em resumo, esse artigo sugere que algo em torno de 250 LOC seria o ideal para um Pull Request. Lembrando que, de forma alguma isso deve ser uma regra super restrita, pois sabemos que cada caso pode necessitar de uma estratégia diferente.
Revisando seu próprio PR
É comum testarmos diversas possibilidades para solucionar um problema durante o processo de desenvolvimento de uma aplicação. Adicionamos arquivos, escrevemos testes que, no fim, não fazem mais tanto sentido. Muitas vezes, até criamos soluções que poderiam ser bem mais simples.
Aantes de criar o seu Pull Request, realize um processo de revisão nele, mesmo que seja uma revisão super rápida. Desta forma, previnimos mudanças indesejadas e arquivos desnecessários. Caso essas mudanças desnecessárias existam, podemos ajustá-las antes de nossos colegas as capturarem.
Após revisar seu PR, se você visualizar algum ponto do código que possa ser confuso para outros desenvolvedores, você pode adicionar comentários que possam facilitar a revisão, por exemplo:
- Este componente está sendo exportado pois precisamos dele nos testes automatizados;
- Este código não foi removido, ele só foi movido para outro componente, veja o Component.tsx.
Titulo, Descrição e Referências
O seu PR deve conter um título auto-explicativo. Já a descrição deve deixar claro o foi alterado no seu projeto, e deve possibilitar outros desenvolvedores revisarem e testarem suas mudanças.
Exemplos de títulos:
- Adiciona casos de teste para o método X;
- Adiciona melhorias no gerenciamento de erro na criação de usuários com avatar.
Além disso, aqui está um ótimo exemplo de um excelente titulo e descrição em um projeto real.
Para mais, adicionar links para tarefas, outros PRs e issues é muito útil para facilitar a revisão e referências futuras, além de ajudar seu PR a ser aceito mais rapidamente.
