Pull/Merge Requests: seguindo boas práticas
Um Pull/Merge Request (dependendo da ferramenta utilizada) é uma forma colaborativa de compartilhar criação ou mudanças de código no repositório, de forma que facilite ser revisado e/ou discutido entre todos os membros do time.
Este é um recurso extremamente importante para compartilhamento de código entre pessoas que permite:
- Membros da equipe conhecerem melhor o projeto que estão revisando;
- Compartilhar melhorias de arquitetura do código;
- Melhorias na escrita do código inerente à sintaxe da linguagem;
- Identificar bugs antes do código entrar na master.
Porém muitas vezes, acabamos por escrever mais coisas do que deveríamos em um Pull/Merge Request.
Alguns exemplos clássicos que ocorrem em um único PR/MR:
- Resolver mais de um bug;
- Implementar mais de uma funcionalidade;
- Não quebrar uma issue/tarefa maior em mais de um PR/MR.
Mas qual o problema em acabar escrevendo um pouco mais de código?
Apesar da primeira vista não parecer algo que vá impactar o resultado final, visto que à nível de funcionalidade a entrega será a mesma no fim do dia. Conforme exemplos abaixo, poderemos notar alguns problemas que isso pode levar.
E se algo não der certo, o que você faria?
Seguindo o gitflow, ao realizar o merge de um Pull/Merge Request na branch master, versionamos com uma nova tag para gerar uma nova release e por fim, enviarmos o software para produção.
Imagine que por qualquer motivo, é introduzido algum bug quando este PR/MR entrar de fato em produção. Ao investigar, identificamos que a causa foi uma das features que foi desenvolvida em Pull/Merge Request.
A ação imediata é fazer o rollback para a versão da tag anterior, ou seja, a última versão estável, até que você identifique o porquê o problema ocorreu.
O problema é que "perdemos" boa parte de features que não estavam relacionadas ao bug em si e poderiam já estar gerando valor em produção.
Viu como apesar de parecer algo trivial pode acabar impactando diretamente o negócio?
Abaixo, há algumas sugestões para exercitar como é possível melhorar a qualidade de um PR/MR.
Pensar no contexto
Em nossa equipe, temos uma regra (obviamente com algumas exceções) que um PR/MR não pode ter mais que 100 linhas.
É claro que não seguimos isso rigorosamente, mas isso ajuda a refletir muito melhor no contexto que estamos entregando, de forma a nos obrigar a pensar: "O que estou entregando poderia ser quebrado em mais partes para facilitar a vida dos amiguinhos que revisarão?".
Pensar no contexto da feature também nos faz descrever melhor no Pull/Merge Request o motivo daquele trecho de código existir. Com isso, membros da equipe e até mesmo você poderão ter mais contexto do que está sendo desenvolvido.
Tenha empatia
Quando estiver escrevendo ou até mesmo antes do desenvolvimento, pense numa forma de deixar o trecho de código que deseja entregar o mais enxuto possível. Em outras palavras: faça o possível para que aquele Pull/Merge Request seja o menor possível.
Para ajudar um pouco, reflita: quais seriam as características que você gostaria de ver em um PR/MR que fosse revisar?
No caso de uma feature maior, tente quebrar em partes menores ou na própria arquitetura do projeto que está desenvolvendo.
Os amiguinhos de equipe, que terão que revisar posteriormente seu código, irão te agradecer e poderão fazer isso sem se cansarem. Isso fará com que:
- Revisem o código mais rapidamente;
- Menos conflitos relacionados à git rebase;
- Menos correções a serem aplicadas durante a revisão;
- O código entre mais rapidamente em produção;
- Maior probabilidade de revisores identificarem possíveis bugs ou melhorias a serem feitas;
Por exemplo, caso vá entregar uma feature nova e disponibilizar via API. Se fizer sentido, você poderia quebrar em:
- Documentação;
- Endpoint;
- Funcionalidade;
- Testes de integração.
Neste exemplo, temos quatro Pull/Merge requests diferentes. É claro que dependendo da funcionalidade a ser realizada poderia ser quebrada em partes menores. Contudo, a ideia foi só demonstrar como uma funcionalidade pode ser subdividida, se refletirmos um pouco melhor no que estamos entregando.
Aceite críticas
É normal quando estamos focados na fase de desenvolvimento, alguns pontos passem desapercebidos, por mais que tentemos entregar com a melhor qualidade possível.
Então durante a fase de revisão, é comum surgirem sugestões de melhoria por outras pessoas que avaliarem o código.
Não veja isso como algo ruim ou pessoal. Aceite como algo normal ou até um aprendizado: lembre-se que o projeto é compartilhado entre várias pessoas e manter padrões e o codebase com qualidade é extremamente importante.
Se a sugestão não for relacionada ao escopo, negocie para abrir novos pull requests ou ser priorizada posteriormente.
TL;DR
- PRs/MRs são excelentes formas de compartilhar o código e dar visão à equipe do que entrará no repositório;
- Seja descritivo quando explicar o porquê daquele trecho de código ter sido desenvolvido;
- Antes ou no começo de desenvolvimento reflita: “esse é o menor trecho de código que consigo fazer em um Pull/Merge Request para gerar valor e facilitar a revisão dos membros de equipe?”;
- Se estiver desenvolvendo uma funcionalidade maior, tente quebrá-la em partes respeitando a arquitetura do projeto;
- Críticas relacionadas ao código sendo desenvolvido são sempre bem vindas e não devem ser levadas para o lado pessoal. Caso a sugestão não seja relacionada ao escopo do que possa ser desenvolvido, negocie para ser desenvolvida em novos Pull/Merge Requests ou serem priorizados em outras sprints
