Llevo escribiendo código profesionalmente más de cinco años. Durante los primeros cuatro años, nunca me preocupé por el tamaño de mis solicitudes de incorporación de cambios (PR). Sin embargo, el año pasado pasé de enviar solicitudes de incorporación de cambios masivas con miles de líneas de cambios a dividirlas en solicitudes más pequeñas y manejables. Los beneficios de este cambio han sido inmensos y, en este blog, compartiré esas ventajas. Según , una solicitud de extracción es: GitHub Una solicitud de incorporación de cambios es una propuesta para fusionar un conjunto de cambios de una rama en otra. En una solicitud de incorporación de cambios, los colaboradores pueden revisar y debatir el conjunto de cambios propuesto antes de integrarlos en el código base principal. En esencia, una solicitud de incorporación de cambios es una forma de colaborar; debemos hacer todo lo posible para mejorar esta colaboración. Un método eficaz para mejorar esta colaboración es mantener solicitudes de incorporación de cambios pequeñas. No existe una definición universal para diferenciar entre un PR pequeño y uno grande. Confiar únicamente en la cantidad de líneas modificadas no es suficiente, ya que el código y las pruebas generadas automáticamente pueden inflar el recuento de líneas. Cuando me refiero a PR pequeños en este artículo, me refiero a dividir un PR más grande en varios PR más pequeños y lógicamente coherentes. Cada PR más pequeño debe ser independiente, fusionable e implementable. No recomiendo una división artificial como dividir un PR en dos, uno que contenga todo el código y otro solo las pruebas, ya que este enfoque no produce ninguno de los beneficios que comparto a continuación. Reseñas eficientes: Pídele a un programador que revise 10 líneas de código y encontrará 10 problemas. Pídele que revise 500 líneas y dirá que todo está bien. Si bien esta cita es graciosa, encierra una verdad. Todos estamos ocupados con nuestro propio trabajo y, cuando le pides a alguien que revise un PR, básicamente le estás pidiendo su tiempo. Revisar un PR requiere que el revisor cambie de contexto y deje de lado su propio trabajo, y si la revisión lleva una cantidad considerable de tiempo, puede resultarle difícil volver a su trabajo, lo que podría afectar su motivación y compromiso con la revisión. Los PR más pequeños, cuya revisión solo lleva entre 20 y 30 minutos, son mucho más fáciles de abordar en comparación con aquellos que pueden llevar entre 2 y 3 horas. Además, los PR más grandes a menudo conducen a descuidos porque nuestra capacidad de atención solo puede abarcar una cantidad limitada de cosas, y saltar entre muchos cambios en un solo PR puede resultar confuso. Según mi experiencia, los PR más pequeños tienden a obtener mejores comentarios y conducen a conversaciones de diseño más significativas. Reseñas más rápidas: En este punto, estoy pensando en agregar mi PR a mi testamento en caso de que todavía esté en revisión después de que me haya ido. Los PR más largos requieren un compromiso de tiempo significativo por parte de los revisores, lo que hace que sea menos probable que reciban atención, especialmente si no están vinculados a características de alto impacto. Por otro lado, los PR pequeños se revisan rápidamente, ya que exigen menos tiempo del revisor y son menos intrusivos. Esta velocidad de revisiones puede ser crucial para cumplir con los plazos del proyecto; he visto proyectos retrasarse porque los revisores senior no pudieron asignar tiempo para revisiones masivas (aunque esto puede suceder con revisiones pequeñas, el riesgo es inherentemente mayor con las grandes). Reelaboración menor: Reelaborar un gran PR después de realizar cambios de diseño es como reorganizar las sillas de cubierta de un barco que acabas de terminar de construir... y luego hundirlo. Todos hemos experimentado situaciones en las que alguien se da cuenta durante la revisión de PR de que un diseño diferente habría sido más fácil de mantener y a prueba de futuro, y necesitamos dedicar tiempo adicional a volver a trabajar en el PR en función del nuevo diseño (no quiero decir que estaban completamente de acuerdo con el diseño que se implementó inicialmente :p). Esto es muy natural porque a veces las cosas se vuelven más claras una vez que las ves escritas en código y comienzas a notar aspectos que podrías haber pasado por alto durante la fase de diseño. En el caso de los PR de gran tamaño, esto puede ser un problema importante porque hay que rehacer muchos elementos, pero en el caso de los PR más pequeños, es más fácil hacer cambios. Y lo que es más importante, hay menos posibilidades de tener que rehacer el trabajo porque es más probable que los revisores identifiquen los problemas desde el principio y los aborden en los PR iniciales, lo que permite que los PR posteriores se basen en los nuevos diseños. Mejores pruebas: Las PR más pequeñas también te benefician como autor de la PR. Te ayudan a probar cambios más pequeños de forma incremental en lugar de probar todo el proyecto de una sola vez. Probar cambios más pequeños da como resultado pruebas más exhaustivas de cada componente del sistema, lo que genera menos errores de producción. Esto se aplica tanto a las pruebas automatizadas como a las pruebas manuales realizadas por ti o por ingenieros de control de calidad dedicados. Además, las relaciones públicas más pequeñas reducen la probabilidad de que se pierdan casos de prueba, ya que puede centrarse en un alcance limitado en lugar de en todo el sistema. ¿Escribir exámenes? Eso parece ser un problema para mi yo del futuro. He visto a desarrolladores (incluyéndome a mí en el pasado) dudar a la hora de escribir pruebas de automatización debido a la percepción de que se invierte tiempo en ellas sin un valor inmediato y “visible” para la función o el producto. Las pruebas de automatización más pequeñas reducen esta fricción al limitar la cantidad de pruebas necesarias y el tiempo que se dedica a escribirlas. Depuración más sencilla: No importa cuán exhaustivas sean las pruebas, ¡se producirán errores en la producción! Poder depurar un error en la producción es crucial, ya que los errores de producción afectan directamente a los usuarios, al negocio o a ambos. Con PR grandes, la superficie de cambio también es grande, lo que hace que sea difícil y lleve mucho tiempo encontrar la causa raíz de los problemas. Por otro lado, las PR más pequeñas contienen menos código y, por lo tanto, hacen que la depuración sea mucho más rápida. Depurar pequeños cambios es como encontrar un error tipográfico; depurar grandes cambios es como corregir una enciclopedia. Implementación de funciones por fases: Por último, pero no por ello menos importante, las PR más pequeñas también son útiles para el gerente de producto y los usuarios. Al utilizar PR pequeñas, puede enviar continuamente partes del sistema a producción, lo que ayuda a obtener comentarios tempranos de los usuarios y permite realizar correcciones tempranas en caso de ser necesario. Saltarse la retroalimentación temprana es como cocinar una comida de cinco platos sin probar nada: solo esperas que no sea un desastre. Los beneficios de las pequeñas relaciones públicas son numerosos, y los puntos que he descrito anteriormente se encuentran entre los que más impacto han tenido en mi experiencia personal. Si has encontrado otras ventajas de las pequeñas relaciones públicas o desafíos con las más grandes que no he mencionado, comenta con tus opiniones. Espero que este artículo te motive a adoptar relaciones públicas más pequeñas. Si ya estás en el camino, espero que refuerce el valor de esta práctica. Gracias por leer, hasta la próxima, ¡sigue codificando y mantente curioso!
