Este rápido bucle de retroalimentación código-construcción-prueba suele denominarse el bucle interno del desarrollo de software. No requiere la intervención de otras personas, y el tiempo de un bucle completo puede ser tan corto como el tiempo que tarda en ejecutarse el análisis estático, que puede ser de sólo unos cientos de milisegundos. Los únicos obstáculos en el bucle interno son la velocidad del compilador o intérprete y la velocidad a la que el desarrollador puede programar.
El bucle externopor el contrario, suele referirse al proceso de despliegue del código en un entorno real y la iteración basada en la integración con el sistema más amplio, las pruebas de aceptación, las pruebas de rendimiento, etc. (aunque diferentes fuentes discrepan sobre qué pasos deben incluirse en el bucle externo). Este bucle es mucho más complejo y, en consecuencia, se tarda mucho más tiempo en proporcionar información al desarrollador. Dependiendo de la velocidad a la que se ejecute su canal de CI / CD, y de si sus pruebas de control de calidad son automatizadas o manuales, podría llevar desde minutos hasta días.
Pero yo propongo que haya un bucle intermedioque a menudo se engloba incorrectamente en el bucle externo: el bucle de revisión del código.
El bucle intermedio
El bucle de desarrollo intermedio implica recibir comentarios de los desarrolladores y otras partes interesadas, ajustar el código en función de esos comentarios y, a continuación, solicitar comentarios adicionales. Es distinto del bucle interno, que es trazado por un único desarrollador en una única base de código en un único entorno, así como del bucle externo, que es trazado por muchos desarrolladores en muchos entornos. La diferencia clave es que es la primera vez que varias partes interesadas examinan el mismo fragmento de código.
Esto suele ocurrir durante la revisión del código, pero la retroalimentación puede darse de muchas formas: programación en parejas, programación en grupo, revisión sincrónica del códigoasí como la tradicional revisión asíncrona del código. Esta última es, en muchos lugares de trabajo, la norma: creas un RP, añades algunos revisores y te vas a hacer otra cosa mientras esperas los comentarios.
Esto suele estar bien, siempre y cuando tengas muchas tareas en las que trabajar y puedas pasar fácilmente de una a otra mientras esperas las revisiones. Y aunque a menudo es así, según mi experiencia, lo contrario ocurre con la misma frecuencia: estás construyendo una función a través de varias bases de código, o en varios pasos, y necesitas revisiones y aprobaciones en cada etapa. En este caso, cada vez que se requiere una revisión, se convierte en un bloqueador.
Los desarrolladores pueden sentirse frustrados esperando revisiones y agrupar varias correcciones en un único PR para reducir el número de revisiones necesarias, o pueden enviar un mensaje directamente a otros desarrolladores para solicitar revisiones. Aquellos a los que se envíe un ping pueden ser sacados de su estado de flujoo incluso sentirse acosados, si se les contacta una y otra vez.
Para todas las partes implicadas, puede ser una experiencia muy frustrante.
Si tienes el poder de hacerlo en tu organización, presiona para que se realicen revisiones síncronas del códigoque reducen en gran medida el tamaño del bucle intermedio, o la sincronizadacomo la programación en parejas o en grupo, que elimina por completo el bucle intermedio. Sin embargo, sé que muchos de los que están leyendo esto no tienen esta opción. Tienes revisiones de código asíncrono y estás atascado con ellas. En ese caso, vamos a intentar sacar lo mejor de una situación poco ideal: ¿qué es lo que hace que la revisión asíncrona sea frustrante?
El problema con la revisión de código asíncrona es que a menudo infla innecesariamente la duración del bucle intermedio.
La revisión de código puede ser un trabajo ingrato. ¿Cuándo fue la última vez que oíste que ascendieran a alguien por ser el revisor más minucioso de un equipo? Además, es fácil esconderse entre la multitud, y si 10 desarrolladores son añadidos como revisores a un PR que sólo necesita 2 aprobaciones, pueden ignorar la solicitud, asumiendo que sus compañeros de equipo se harán cargo. Incluso cuando un desarrollador lo hace un desarrollador revise algo de código, puede que se retrase en hacerlo. Esperar hasta terminar su tarea actual, o hasta después de comer, o incluso hasta después de su próxima reunión, para revisar un RP puede no parecerle un retraso. De hecho, puede parecerle muy rápido. Pero para el desarrollador que espera una revisión para continuar su trabajo, está bloqueado.
La próxima vez usted ponga un RP, usted también necesitará revisiones. Y al igual que tus compañeros, las querrás lo antes posible. Así que recuerda que cuando alguien solicita una revisión del código, lo cortés es Déjalo todo y revisa (DEAR).
Minimice el bucle intermedio, querido
Después de gestionar cualquier incidente de producción activo, lo primero que debe hacer un desarrollador es // TODO de un desarrollador siempre siempre debería ser revisar el código.
Si te acabas de sentar en tu escritorio y estás buscando algo en lo que trabajar, comprobar a qué pull requests has sido asignado debería convertirse en un reflejo.
No empieces esa pequeña corrección de errores, no leas esa próxima entrada del blog (a menos que sea esta), no compruebes tu bandeja de entrada.
Recuerda DEAR y haz lo cortés: Déjalo todo y revisa.
