[Nota del editor de CSDN] ¿Cuál cree que la longitud de PR es la más adecuada? El autor de este artículo cree que la longitud ideal es de 50 líneas.
Enlace original: https://graphite.dev/blog/the-ideal-pr-is-50-lines-long
¡No redistribuir sin permiso!
Escrito por | GREG FOSTER Traductor | Crescent Moon
Editor a cargo | Xia Meng
Listado | CSDN (ID: CSDNnews)
La mayoría de los proyectos están de acuerdo en que cuanto menor sea el cambio de código, mejor. La razón es simple, cuanto más pequeña sea la solicitud de extracción (Pull Request, PR), más fácil será de revisar, menor será la probabilidad de errores y más rápida será la implementación.
Pero, ¿cuál es la duración ideal de un PR? ¿Habrá algún problema de que el PR es demasiado pequeño? Si un PR pequeño es mejor, ¿qué tan bueno es?
La longitud ideal de un PR debe ser de 50 líneas.
En nuestra opinión, la longitud ideal de un PR debería ser de 50 líneas.
Se revisó y fusionó un cambio de código de 50 líneas aproximadamente un 40 % más rápido que un cambio de 250 líneas. En comparación con un cambio de código de 250 líneas, un cambio de código de 50 líneas tenía un 15 % menos de probabilidades de revertirse y recibía un 40 % más de comentarios de revisión por línea de cambio. Además, si el PR promedio enviado por sus compañeros de equipo es de 200 líneas y su promedio es de 50 líneas, entregará un 40% más de código total.
50 líneas es la mejor opción para garantizar la velocidad de programación, aumentar las opiniones de revisión, reducir las tasas de revocación y aumentar la cantidad total de código enviado. En términos de rango aceptable, recomiendo de 25 a 100 líneas de código por PR. A partir de los datos, encontramos que cuanto más pequeño es el PR, menos tiempo se dedica a revisar, fusionar y comentar cada línea. Pero hay una limitación: si el número de líneas de código modificado es inferior a 25 líneas, la probabilidad de que se deshaga la modificación aumenta y la cantidad total de código entregado también disminuirá.
A continuación, hablamos de por qué y miramos los datos que respaldan esta conclusión.
conjunto de muestra
Todas las declaraciones basadas en datos de este artículo utilizan repositorios y relaciones públicas públicas y privadas sincronizadas a través de Graphite. Para determinar el tamaño ideal de PR, observé las siguientes cuatro métricas principales y su relación con el tamaño de PR:
Tiempo para revisar y fusionar código;
Probabilidad de deshacer modificaciones;
promedio de comentarios;
Cambios de código anuales totales.
Precauciones
Aquí hay algunas cosas a tener en cuenta al sacar conclusiones de los datos que recopilamos:
Al clasificar según el tamaño de PR, el tamaño de la clasificación no es uniforme ni lineal, porque la granularidad de la clasificación de tamaño lineal es demasiado fina y la clasificación del tamaño exponencial perderá muchos detalles.
Utilicé el tamaño mediano de PR en lugar del promedio para evitar que los refactores individuales distorsionaran los datos generales.
El criterio para juzgar que se revoca la modificación es: el PR tiene la palabra "Revertir" en el título, porque git revert agregará automáticamente esta palabra al frente del título.
Descubrimos que los usuarios de Graphite generalmente tienden a crear RP más pequeños, ya que muchas organizaciones usan un estilo de desarrollo basado en troncales (lo que fomenta RP más pequeños).
Cuándo revisar el código frente a cuándo fusionar el código
A continuación, profundicemos en los datos. Primero, observamos el tiempo para revisar el código versus el tiempo para fusionar el código, y encontramos que el PR con la menor cantidad de código es casi 5 veces más rápido que el PR que contiene 2-5k líneas de código. Esto tiene sentido, ya que los PR más pequeños significan menos código, y menos código significa que es menos probable que el cambio se rompa o involucre muchos detalles, por lo que las revisiones son más rápidas.
Sin embargo, cuando la cantidad de código modificado supera las 5k líneas, el PR comienza a acelerar nuevamente. Creo que esto se debe a varias razones, incluidas las refactorizaciones seguras, los paquetes agregados o el código generado, tal vez porque el código es tan grande que ni los autores ni los revisores pueden leer todos los cambios de código en detalle.
Tenga en cuenta que aquí nos preocupa más el tiempo por PR que el tiempo por línea de código. Si solo hablamos de cómo fusionar los PR en la base de código lo antes posible, podemos ver a partir de los datos que cuanto menor sea el tamaño del PR, mejor. Sin embargo, si nuestro objetivo es enviar el código lo más rápido posible, un PR de 2000 líneas se puede fusionar a unas 12 líneas por hora, y un PR de 10 líneas se puede fusionar a unas 0,25~2 líneas por hora.
Tasa de revocación por tamaño de PR
La tasa de revocación refleja la misma conclusión: cuanto menor es el PR, menos se revierte la revisión. El PR con menor tasa de retiro: el monto de modificación de código es entre 25 y 50 líneas. Sin embargo, algunos casos extremos todavía exhiben propiedades muy interesantes. Los PR con menos de 10 líneas de código tienen una tasa de retracción significativamente más alta que los PR con 10-100 líneas de código. Supongo que esto se debe a que los PR por debajo de 10 líneas son en su mayoría cambios de configuración peligrosos, pero supongo que normalizar la cantidad de líneas modificadas debería refutar esa suposición.
La "seguridad" parece mejorar ligeramente después de que el tamaño del PR supera las 10k líneas. Sospecho que se trata de relaciones públicas a gran escala que generalmente implican refactorización, con menos cambios funcionales y, por lo tanto, menos perjudiciales. O porque después de más de 10 000 líneas, los ingenieros podrían estar menos dispuestos a retirar dicho PR debido a la reacción violenta y los conflictos de fusión.
Número promedio de comentarios por tamaño de PR
Según el objetivo de la optimización (mejorar la velocidad de fusión o la revisión de código en profundidad), puede elegir dividir el PR. Si desea obtener más comentarios, puede elegir controlar el tamaño del cambio de código a 1-2 mil líneas de código. Si solo desea fusionar lo más rápido posible, mantenga los cambios de código en menos de 10 líneas. Esta información es útil si le preocupa entregar cambios lo más rápido posible y no quiere perder demasiado tiempo discutiendo sobre ellos.
También vemos que a medida que crece el tamaño de las relaciones públicas, el número promedio de reseñas comienza a disminuir gradualmente. ¿Cuánto código están dispuestos a leer los revisores? En realidad, esto tiene un límite: creo que 2k líneas deberían ser el punto en el que un PR de "lectura" se convierte en un PR de "navegación".
Si su preocupación es maximizar la cantidad de compromiso y comentarios sobre su código a largo plazo, entonces las relaciones públicas deben ser lo más pequeñas posible. Para facilitar la comprensión, debe agregar un comentario cada 39 líneas de código. Por el contrario, si odia escribir comentarios, puede hacer que el PR sea de más de 10 000 líneas, de modo que cada 6000 líneas de cambios de código solo reciban algunos comentarios esporádicos; experimente esto por sí mismo, después de todo, ningún programador envía el último El propósito de PR es obtener retroalimentación o comentarios.
La cantidad total de código entregado
Quizás se pregunte si escribir un pequeño PR afecta la cantidad total de código entregado. Todos queremos velocidad, pero a veces se necesita un alto rendimiento. Escribir constantemente PR de menos de 20 líneas tendrá un impacto significativo en la velocidad de programación, pero curiosamente, escribir PR de más de 100 líneas también tendrá un impacto significativo en la velocidad de programación. Para garantizar el máximo rendimiento, el tamaño medio de PR es de 40 a 80 líneas. Creo que es porque la cantidad de código entregado = tamaño de cambio * velocidad de cambio. Si los cambios son demasiado pequeños, incluso aumentar la velocidad de la fusión no maximizará la salida. Por el contrario, si los cambios son demasiado grandes, el ciclo de revisión de código y fusión de código será más lento.
Resumir
Los desarrolladores deben apuntar a un PR medio: 50. Por supuesto, también debemos considerar algunos casos extremos y ajustar el tamaño de los cambios de código de acuerdo con las necesidades reales. Al mismo tiempo, debe comprender que ajustar el tamaño de PR tendrá un gran impacto en la calidad, la velocidad y el rendimiento de la revisión. la posibilidad de deshacer los cambios.