Afirmação: o PR ideal tem 50 linhas
Uma afirmação de que o pull request “ideal” tem cerca de 50 linhas de código, baseada em métricas como merges mais rápidos e menos reversões, gerou debate sobre como mudanças de software devem ser estruturadas e revisadas. Muitos engenheiros argumentam que a contagem de linhas é um mau proxy de qualidade, observando que funcionalidades reais, refatorações e testes frequentemente exigem centenas ou milhares de linhas e que PRs minúsculos podem fragmentar o contexto, aumentar a sobrecarga de coordenação e incentivar discussões triviais. O consenso emergente é que um bom PR representa uma unidade de trabalho coerente e revisável que pode ser implantada com segurança, tratando o tamanho como uma orientação flexível, e não como uma meta rígida a ser otimizada ou imposta.
Reação geral à afirmação do “ideal de 50 linhas”
- Muitos veem a afirmação como excessivamente generalizada ou até “boba” sem contexto.
- Outros acham que a ideia central — PRs menores e focados são mais fáceis de entender e mais seguros — é amplamente verdadeira, mas deve ser tratada como uma orientação, não como uma regra.
- Vários observam que o artigo vem de uma empresa que se beneficia de PRs menores/encadeados, e o veem em parte como propaganda do produto.
Argumentos a favor de PRs menores
- Mais fáceis de revisar de forma minuciosa; menor chance de aprovação automática sem análise.
- Frequentemente se correlacionam com menos reversões e tempos de merge mais rápidos nos dados citados.
- Menor carga cognitiva para autor e revisor; mais fácil encaixar revisões rápidas em pequenas janelas de tempo.
- Melhor para isolar mudanças de comportamento, tornando reversões e depuração mais simples.
- Ajudam a evitar “PRs monstros”, que frequentemente deixam bugs passarem e são difíceis de raciocinar sobre.
Argumentos contra metas rígidas de contagem de linhas
- Linhas de código são vistas como um mau proxy para complexidade ou valor.
- Limites arbitrários (por exemplo, tetos de 5 ou 50 linhas) podem destruir contexto, forçar cortes estranhos, incentivar a omissão de testes e tornar recursos mais difíceis de revisar como um todo.
- PRs muito pequenos podem causar troca excessiva de contexto, compreensão fragmentada e “morte por mil PRs”.
- Refatorações, redesenhos, novos subsistemas, mudanças de schema ou grandes acréscimos de testes muitas vezes legitimamente abrangem centenas ou milhares de linhas.
Contexto, conteúdo e “unidade de trabalho”
- Muitos argumentam que o verdadeiro “ideal” é: uma unidade coerente e implantável de comportamento por PR, independentemente de quantas linhas isso represente.
- Commits vs PRs: vários preferem commits pequenos e lógicos dentro de um PR maior, com um histórico limpo para reversões e arqueologia.
- Alguns enfatizam que o código de teste deve frequentemente estar no mesmo PR; outros sugerem PRs separados para adições de testes não críticas.
Métricas, causalidade e processo
- Vários comentaristas destacam que correlação ≠ causalidade; PRs pequenos podem simplesmente ser trabalho inerentemente mais simples/menos arriscado.
- Há preocupação de que gestores transformem isso em Goodhart, com metas (“PRs devem ter cerca de 50 linhas”) desconectadas da qualidade real.
- As experiências variam amplamente: algumas equipes melhoraram a confiabilidade ao impor PRs menores; outras acharam que limites rígidos retardaram a entrega e pioraram as revisões.