Afirmación: el PR ideal tiene 50 líneas
Una afirmación de que el “PR ideal” tiene alrededor de 50 líneas de código, basada en métricas como integraciones más rápidas y menos reversiones, ha desatado el debate sobre cómo deben estructurarse y revisarse los cambios de software. Muchos ingenieros sostienen que el conteo de líneas es un mal indicador de calidad, y señalan que las funciones, refactorizaciones y pruebas reales suelen requerir cientos o miles de líneas, y que los PR diminutos pueden fragmentar el contexto, aumentar la sobrecarga de coordinación e invitar a discusiones triviales. El consenso emergente es que un buen PR representa una unidad de trabajo coherente y revisable que puede desplegarse con seguridad, tratando el tamaño como una guía flexible en lugar de un objetivo rígido que optimizar o imponer.
Reacción general ante la afirmación del “ideal de 50 líneas”
- Muchos consideran que la afirmación es demasiado generalizada o incluso “ridícula” sin contexto.
- Otros creen que la idea central —los PR más pequeños y enfocados son más fáciles de entender y más seguros— es ampliamente cierta, pero debe tratarse como una guía, no como una regla.
- Varios señalan que el artículo procede de una empresa que se beneficia de PR más pequeños o apilados, y lo ven en parte como publicidad del producto.
Argumentos a favor de PR más pequeños
- Más fáciles de revisar a fondo; menos riesgo de aprobar sin analizar.
- A menudo se correlacionan con menos reversiones y tiempos de integración más rápidos en los datos citados.
- Menor carga cognitiva tanto para quien lo escribe como para quien lo revisa; más fácil programar revisiones rápidas en pequeños huecos de tiempo.
- Mejor para aislar cambios de comportamiento, lo que simplifica las reversiones y la depuración.
- Ayudan a evitar los “PR monstruosos”, que con frecuencia introducen errores y son difíciles de razonar.
Argumentos en contra de objetivos estrictos por conteo de líneas
- Las líneas de código se consideran un mal indicador de complejidad o valor.
- Los límites arbitrarios (por ejemplo, topes de 5 o 50 líneas) pueden destruir el contexto, forzar divisiones incómodas, incentivar omitir pruebas y dificultar que las funciones se revisen como un todo.
- Los PR muy pequeños pueden provocar demasiados cambios de contexto, comprensión fragmentada y “muerte por mil PR”.
- Las refactorizaciones, rediseños, nuevos subsistemas, cambios de esquema o grandes añadidos de pruebas a menudo legítimamente abarcan cientos o miles de líneas.
Contexto, contenido y “unidad de trabajo”
- Muchos sostienen que el verdadero “ideal” es: una unidad coherente y desplegable de comportamiento por PR, sean las líneas que sean.
- Commits vs PR: varios prefieren commits pequeños y lógicos dentro de un PR más grande, con un historial limpio para reversiones y arqueología.
- Algunos subrayan que el código de pruebas debería estar a menudo en el mismo PR; otros sugieren PR separados para añadidos de pruebas no críticas.
Métricas, causalidad y proceso
- Varios comentaristas enfatizan que correlación ≠ causalidad; los PR pequeños podrían ser simplemente trabajo inherentemente más simple o de menor riesgo.
- Preocupa que los managers conviertan esto en un objetivo de Goodhart (“los PR deben tener ~50 líneas”) desconectado de la calidad real.
- Las experiencias varían mucho: algunos equipos mejoraron la fiabilidad al imponer PR más pequeños; otros encontraron que los límites estrictos ralentizaban la entrega y empeoraban las revisiones.