Saltar al contenido

Blog técnico | Revisiones continuas del código

Las revisiones de códigos son generalmente aceptadas como algo bueno en el desarrollo de software. Algunos de los beneficios incluyen la mejora de la calidad, el intercambio de conocimientos de un sistema y la promoción de la propiedad colectiva de códigos.

Pero la forma en que se lleva a cabo una revisión del código es importante. Amontonar a varias personas en una habitación individual donde el código se proyecta en una pantalla puede ser un proceso aburrido (y costoso). Las herramientas para administrar las revisiones de código han mejorado las cosas dramáticamente. Ahora podemos revisar el código asincrónicamente. Las herramientas de análisis de código estático pueden eliminar los problemas más comunes o las violaciones del estilo de la empresa. Podemos seguir el progreso de las revisiones e incluso combinarlas con nuestro flujo de trabajo (como con las solicitudes de extracción).

Blog técnico | Revisiones continuas del código
Blog técnico | Revisiones continuas del código

¿Pero podemos hacerlo mejor?

Saltar en el vagón de la banda continua

Hoy en día oímos hablar mucho de hacer cosas continuamente. Integración continua. Despliegues continuos. Incluso retrospectivas continuas. ¿Pero por qué “continuamente”? En algunos casos es para minimizar el dolor (como con la IC). En otros casos, es para incorporar más cosas buenas en nuestras rutinas.

Entonces, ¿es posible hacer una revisión continua del código? ¡Sí! Simplemente tienes a alguien revisando tu código mientras trabajas en él. Revisar el código es definitivamente un trabajo, y hay un nombre para cuando tenemos dos desarrolladores trabajando en el mismo código al mismo tiempo: programación en parejas.

“Espera”, te imagino diciendo, “¡me has engañado para que lea un artículo sobre emparejamientos cuando creía que estaba leyendo sobre revisiones de códigos!”

Es verdad. La programación en parejas (y su hermana, la programación de la mafia) son definitivamente temas que yo defiendo mucho. Pero en este artículo, quiero enfocarme en cómo el emparejamiento puede ser una forma mejorada de revisión de código.

Entonces, ¿qué beneficios obtienes de una “revisión continua del código”?

Ciclos cortos de retroalimentación

Uno de los mayores problemas de una revisión típica de un código es el retraso entre la escritura del código y la obtención de retroalimentación. Para cuando te enteras de los cambios recomendados, ya has pasado a otra cosa. (El tiempo de un codificador es muy valioso después de todo; probablemente no puedes permitirte el lujo de sentarte sin hacer nada mientras esperas a que Lisa salga de esa reunión y haga la revisión). Así que tienes que dejar la otra cosa que estabas haciendo y volver al problema que creías que ya habías resuelto… hiciste que el código funcionara antes de presentar la revisión del código, ¿no?

El cambio de contexto conlleva muchos gastos generales. Y es posible que tenga que hacerlo más de una vez si hay varios revisores o si sus cambios requieren una nueva presentación. Y este cambio no sólo afecta al autor, sino también a los revisores que están cambiando de contexto de su otro trabajo.

En una revisión continua del código no tienes este problema. Tu pareja tiene razón en que te da retroalimentación a medida que avanzas. Desde pequeñas cosas como el nombre de una variable hasta cosas como notar un bicho o contarte sobre una clase existente que deberías usar. El código se actualiza en tiempo real.

Comprensión compartida

Cuando trabajas con una pareja, esa otra persona te ayuda con las tareas mientras vas. Ellos entienden las decisiones que se toman mientras tú codificas y pueden darte mejores consejos. Y conocen ese código mucho mejor si tienen que volver a él más tarde. Incluso pueden terminar algo cuando no estás disponible.

Contrasta eso con una revisión habitual del código en la que el revisor tiene que entender primero el objetivo del cambio, y luego leer el código para determinar si es correcto. ¿Cuántas veces se le da un vistazo rápido al código que se está revisando? ¿Con qué frecuencia el revisor realmente ejecuta ese código? ¿El revisor entiende esta parte del código muy bien?

Se requiere un gran esfuerzo para que un revisor a posteriori ofrezca la misma calidad de información que alguien con quien se trabaja activamente. Y con demasiada frecuencia, esas revisiones de códigos se hacen apresuradamente o con poco cuidado.

Evitar las revisiones dolorosas

A veces las críticas duelen. En el peor de los casos, los críticos reprenden o degradan al autor. Me avergüenza decir que he escrito algunas críticas como esta en mi pasado. E incluso cuando los críticos se comportan, puede ser desalentador recibir comentarios que sugieran revisiones masivas o una gran cantidad de pequeños cambios.

Pero cuando la revisión es continua, rara vez duele. Las personas son menos propensas a decir algo malo cuando están trabajando juntos porque es “nosotros” en vez de “ellos”. El proceso es inherentemente menos conflictivo. Todos esos pequeños cambios son discutidos y arreglados inmediatamente. Se evitan las trampas y las mejoras se pueden corregir antes de perder mucho tiempo.

Cuando alguien siempre está revisando tu código, comienzas a desarrollar un estilo de código compartido. Esto reduce la necesidad de que tu equipo defina las pautas. O, si tienes una guía de estilo para toda la empresa, el revisor puede ayudarte a recordar que la sigas porque al hacerlo les ayuda a leer lo que estás escribiendo.

Esto puede reducir (o en algunos casos eliminar) su necesidad de analistas de código estático. Eso significa que no necesitas sentarte en una gran reunión para discutir la configuración. Y ya que su revisión está ocurriendo continuamente, no hay necesidad de herramientas específicas de revisión de código tampoco!

Pruébalo

Si estos beneficios te suenan bien, ¿por qué no probar las continuas revisiones de código? También hay otros grandes beneficios en la programación de parejas o de la mafia.

Por supuesto, siempre hay algunas advertencias. Algunos compañeros de trabajo son simplemente gruñones y desagradables. Otros sólo tienen personalidades enfrentadas. Puede que no quieras trabajar con ellos todo el día todos los días.

A menudo puede ser más fácil emparejarse cuando se está en un mismo lugar, pero el emparejamiento remoto es más fácil para los equipos distribuidos. Si eso no funciona para tu equipo, entonces tal vez las herramientas asincrónicas como las solicitudes de extracción pueden ser mejores.

Algunas personas podrían decir que el emparejamiento no es una revisión de código. Es difícil permanecer como revisor anónimo cuando no estás manejando el código, así que te conviertes en más de un co-autor. En ese momento, ¿estás demasiado cerca del trabajo que no puedes ver tus errores (la misma razón por la que la gente necesita correctores de textos)?

Estas preocupaciones son muy reales y pueden significar que las continuas revisiones del código pueden no funcionar para algunos equipos. En mi experiencia, los beneficios del emparejamiento superan con creces los inconvenientes. Se ha convertido en mi forma preferida de trabajar y es como la mayoría de nuestros equipos trabajan aquí en .

Categorías: prácticasTags: emparejamiento, mobbing