O Real Motivo de Seus PRs Ficarem Grandes
Eu trabalhei uma vez em uma empresa que enviava pull requests massivos por hábito. Um PR podia ficar aberto por semanas. Revisá-lo exigia manter todo um subsistema na cabeça. Os bugs se acumulavam. Os prazos estouravam. Eventualmente, tivemos que reconstruir uma parte enorme do sistema porque ninguém mais conseguia alterá-lo com segurança.
Os engenheiros não eram ruins. Eles eram inteligentes e trabalhavam duro. Os PRs cresciam por um motivo entediante.
Ninguém os ensinou a decompor o trabalho.
Frequentemente tratamos PRs grandes como um problema de disciplina. Dizemos: "Apenas faça PRs menores". Agimos como se a força de vontade fosse a única diferença entre 1.500 alterações e 150 alterações.
Não se trata de força de vontade. Decompor um trabalho grande em partes pequenas e independentes é uma habilidade. A maioria das pessoas nunca é ensinada a isso. Quando um ticket diz "adicionar faturamento", parece uma tarefa única. Ver onde um PR termina e o próximo começa é a parte difícil.
Eu também costumava enviar PRs grandes. Eu achava que "concluído" significava resolver todo o problema de uma vez e enviá-lo para revisão. Levei anos para aprender que o menor é melhor.
PRs pequenos mudaram tudo para mim:
- Revisores encontram mais bugs. Um humano consegue raciocinar sobre 200 alterações. Eles não conseguem raciocinar sobre 2.000. Eles apenas dão uma olhada rápida e aprovam.
- Os merges acontecem mais rápido. Os PRs param de ficar parados na fila.
- Parei de me sentir sobrecarregado. Eu foquei em uma peça de cada vez.
- Tornei-me um planejador melhor. Você deve entender a forma do seu trabalho para conseguir decompô-lo.
Comecei a ver sistemas como peças de Lego. São peças pequenas que se encaixam. Assim que você enxerga as peças, reduzir o trabalho parece algo natural.
Minha equipe atual envia PRs pequenos. Os resultados são claros:
- Nosso tempo médio de merge é de 1,5 dias.
- Encontramos e corrigimos bugs rapidamente porque as alterações são legíveis.
- Nosso tempo de entrega é consistente.
Decompor o trabalho é uma habilidade que você deve treinar. Você não consegue corrigir PRs grandes com uma regra. Você os corrige ensinando as pessoas a enxergar as peças.
A IA torna essa habilidade ainda mais vital.
No passado, escrever 2.000 linhas de código exigia muito esforço. Esse atrito mantinha os PRs menores. A IA removeu esse atrito. Você pode gerar alterações massivas com um único prompt.
O esforço não desapareceu. Ele apenas se deslocou para o revisor. O autor não paga nada, mas o revisor paga o preço total.
Se o tamanho não sinaliza mais quanto trabalho um autor realizou, o tamanho diz muito pouco sobre o risco. Você deve decidir quais partes merecem sua atenção mais cuidadosa.
Ensine sua equipe a enxergar os tijolos. É o hábito de maior alavancagem na engenharia.
Como sua equipe decide quais PRs precisam de uma revisão profunda e quais podem passar rapidamente?
Fonte: https://dev.to/pixel-wraith/the-real-reason-your-prs-get-big-5cm3
Comunidade de aprendizado opcional: https://t.me/GyaanSetuAi