O tamanho do pull request é mais importante do que você pensa — Rodrigo Miguel

O tamanho do pull request (PR) é mais importante do que você pensa, e descobrir o tamanho ideal aumenta a velocidade e qualidade do trabalho do seu time, segundo Rodrigo Miguel (chamarei apenas de Miguel daqui pra frente), Líder de Engenharia na Resultados Digitais.

Esse foi o tema da palestra realizada por Miguel no dia 16/08/2018 na DemoBeer, evento interno do time de Produto e Engenharia da Resultados Digitais, para compartilhar conhecimento. Esse post traz um resumo da palestra, e no final dele, vídeo na integra.

Essa palestra foi ministrada no evento Code Climate Summit, que ocorreu San Francisco no dia 18/07/2018, e no evento Agile Floripa, que ocorreu dias 07 e 08 e Dezembro, em Florianópolis.

Problema

A Resultados Digitais é uma empresa jovem, com apenas 7 anos de idade. Teve um crescimento muito acelerado, e hoje conta com mais de 100 pessoas na Engenharia. Conforme cresce o produto, a complexidade dele também cresce. Mas a produtividade não aumenta linearmente adicionando mais pessoas no time.

Precisamos ficar mais atentos aos detalhes, refinar os processos, entender como alavancar a produtividade do time. Foi nesse cenário que Miguel iniciou esse estudo e chegou às conclusões abaixo, que fizeram muita diferença na RD, e tenho certeza que farão no seu time.

Foram 4 descobertas nesse estudo, que foram detalhadas na talk:

1. A qualidade das alterações está diretamente relacionada ao tamanho dos PRs.
2. Lead Time está diretamente relacionado ao tamanho dos PRs.
3. É possível descobrir o tamanho ideal do PR.
4. PRs com tamanho ideal aumentam velocidade do time e a qualidade do software.

1. A qualidade das alterações está diretamente relacionada ao tamanho dos pull requests

Code Review é a maneira mais efetiva de se encontrar bugs, segundo Michael Fagan. Ele afirmou isso em 1976, mas desde então muitos outros autores reafirmaram.

O ser humano, no entanto, tem uma capacidade limitada de armazenar uma grande quantidade de informação ao mesmo tempo. Estudo feito por Alastair Dunsmore em 2000 (Dunsmore, A., M. Roper, and M. Wood. 2000. Object-Oriented Inspection in the Face of Delocalisation), mostra que quanto mais tempo alguém investe revisando código, mais problemas irá encontrar. Porém, depois de uma hora de review, a capacidade de encontrar problemas cai. E não é porque acabaram os problemas, mas por nossa capacidade limitada de concentração, que o autor chama de Focus Fatigue.

Outro estudo feito por Cohen mostra que, quanto mais linhas validadas em uma hora, menor a capacidade de se encontrar problema. Nos estudos, Cohen chega a conclusão que Code Review depois de 400 linhas em uma hora, capacidade de encontrar problemas cai.

Com base nesses estudos, podemos afirmar que a qualidade está relacionada ao tamanho do PR. Tanto para quem revisa, quanto para quem desenvolve, pois acaba tendo o mesmo benefício de concentração no momento da revisão.

2. Lead Time está diretamente relacionado ao tamanho dos PR

Para provar que essa afirmação é verdadeira, Miguel trouxe aqui alguns fatos da sua experiência como Líder de Engenharia, e algumas referências bibliográficas.

Alguns fatos com relação a PRs grandes:

• Mais tempo para o revisor encontrar uma janela de tempo para revisar, e mais tempo levará o review, podendo passar de 1 hora.
• Menos chance do PR passar na primeira tentativa, e consequentemente, mais chance que fique ainda maior e precise de mais review.
• Vai ficando cada vez mais chato e entediante re-trabalhar… re-testar… re-revisar… esse código. Há cada vez menos segurança em liberar em produção.
• Mais chance de conflitos de merge, mais chance de bloquear outras tarefas que dependem dessa, e consequentemente, mais demora para colocar em produção.

Na palestra Miguel faz a simulação de um Kanban Board bem interessante, simulando o dia a dia de um time com PRs grandes, fica clara a demora e o quanto é prejudicial trabalhar com lotes grandes, o efeito que causa em todo o processo.

Trabalhar com lotes pequenos reduz o trabalho em andamento e aumenta vazão. Serão menos tarefas em andamento, o processo de cada PR é mais rápido (coding, review, retrabalho, etc), aumenta a velocidade de feedback, diminui a variabilidade e o risco.

Uma dica de leitura como referência, para ajudar a provar o ponto, é o livro “The Principles of Product Development Flow”, de Donald Reinertsen.

3. É possível descobrir o tamanho ideal do PR

Para provar que essa afirmação é verdadeira, Miguel trouxe aqui um problema clássico de otimização de tamanho de lote, enfrentado por outras indústrias. O tamanho de lote perfeito é uma função do custo de transação e o custo de retenção.

• Custo de transação: implementar e colocar em produção. Quebrar em pequenas partes, garantir as dependências, testes, review, merge e deploy. Quanto maior a quantidade de linhas de código, menor o custo de transação, pois você fez tudo isso de uma vez.
• Custo de Retenção: o custo de não colocar em produção o PR, esse bug ou feature que está sendo implementada. Quanto menor o PR, menor o custo de retenção, mais rápido vai para produção.

A intersecção desses dois custos, é o tamanho ótimo de lote. Mas é difícil encontrar um número matematicamente preciso. Não se preocupe com isso, vá diminuindo o tamanho do lote e acompanhando impacto da mudança nas métricas.

Mas que métricas devo olhar? Principalmente o tamanho dos PRs e o Cycle Time. Outras métricas importantes:

• Tempo do primeiro Commit até abrir PR.
• Tempo PR aberto até primeiro Review.
• Tempo PR aberto até o merge.

Então sim, é possível encontrar o tamanho ideal. Esse número tem que ser sempre monitorado, pois a tendência é mudar conforme o contexto do seu time (tamanho da equipe, complexidade do produto, senioridade do time, etc).

4. PRs com tamanho ideal aumentam velocidade do time e a qualidade do software

Para provar que essa afirmação é verdadeira, Miguel usou um método muito simples, basta olhar para as 3 afirmações anteriores:

Se “A qualidade das alterações está diretamente relacionada ao tamanho dos PRs” e “o Lead Time está diretamente relacionado ao tamanho dos PRs” e “é possível descobrir o tamanho ideal do PR”, podemos concluir que sim, PRs com tamanho ideal aumentam a velocidade do time e qualidade do software.

Quer mais detalhes? Dá uma olhada no vídeo da palestra. Essa edição do DemoBeer em especial, foi full remote, ou seja — não reunimos as pessoas no auditório, mas cada um assistiu em sua máquina, onde estava no momento, com a mesma experiência para todos.