Saltar al contenido

7 Código Revisar las mejores prácticas y dinámicas que se pueden identificar y sobre las que se puede actuar

Una perspectiva tradicional es que la revisión del código permite a los equipos de desarrollo encontrar errores antes de que lleguen a la producción. Aunque no es del todo erróneo, creemos que es una visión estrecha y que hay mucho más valor por realizar dentro del proceso de revisión.

Sin embargo, si hay una oportunidad de capturar más valor, entonces debe haber algo que nos inhiba de capturar ese valor. En la revisión de código (usamos las palabras PR, solicitud de extracción y revisión de código indistintamente), lo ideal es que un equipo progrese a través de interacciones fluidas que conduzcan a la incorporación de retroalimentación y todo es estupendo. No hay problema!

7 Código Revisar las mejores prácticas y dinámicas que se pueden identificar y sobre las que se puede actuar
7 Código Revisar las mejores prácticas y dinámicas que se pueden identificar y sobre las que se puede actuar

Pero en la práctica, no siempre es así.

Debido a que los ingenieros son seres humanos, cada revisión de código tiene tensión incorporada. Los ingenieros tienen sus propias maneras de hacer las cosas, y el punto de las revisiones de códigos es que alguien más está interviniendo con sus propias (a veces diferentes) opiniones. A veces esa tensión puede beneficiarse de la ayuda de un tercero.

El problema es que los dirigentes y administradores no suelen formar parte del proceso de examen en una escala significativa.

Para participar de manera significativa, los líderes necesitaban un conjunto de señales en esta corriente ininterrumpida de solicitudes de extracción que les ayudara a identificar en qué revisiones participar y cómo participar mejor.

En nuestra misión de elevar el liderazgo de la ingeniería con datos objetivos, nuestro equipo de ciencia de los datos estudió más de 100 señales en los datos para hacer mejores relaciones públicas, mejores ingenieros y, en última instancia, mejores productos. (Más sobre el nuevo producto de revisión de código y colaboración de GitPrime aquí).

Este post de varias partes cubre siete dinámicas que puede reconocer en los datos, y actuar para mejorar la efectividad de su equipo a través de la revisión de códigos. Al enfatizar la forma en que los equipos de seres humanos trabajan juntos, puede excavar en las oportunidades fértiles para una mejora tangible.

Hemos organizado las siete dinámicas de solicitud de atracción en dos grupos: procesos y personas.

Procesos

En este primer post, examinaremos cómo puedes construir la eficacia centrándote primero en el proceso de tu equipo, antes de pasar a la gente de tu equipo. Así que vamos a sumergirnos en cuatro señales que indican que puedes mejorar los procesos que tu equipo tiene en marcha.

1. Código no revisado y solicitudes de extracción

Las solicitudes de extracción no revisadas se producen cuando los ingenieros abren una revisión del código y se aprueba sin ningún comentario, a menudo por los propios remitentes. Como regla general, los ingenieros nunca deben fusionar su propio código, y de hecho, la mayoría de las empresas no les permiten hacerlo. Las solicitudes de extracción no revisadas evitan cualquier forma de revisión del código, así como la oportunidad de mejorar y aprender.

Si vale la pena poner el código en la rama principal del código, vale la pena que alguien lo revise. Sin embargo, en la práctica, las solicitudes de extracción no revisadas suceden a menudo, por cualquier número de razones.

Con las herramientas actuales, las solicitudes de extracción no revisadas son típicamente difíciles de detectar, en un equipo grande con cientos de solicitudes de extracción que fluyen de forma regular y con plazos en el horizonte. Los datos de GitPrime pueden ayudar a identificar estas instancias para ti.

Solicitud de extracción no revisada, como se ve en GitPrime

En esta vista, se pueden ver todas las solicitudes de atracción que este equipo abrió en un solo sprint. Seis de ellas, en amarillo, aún no han sido revisadas. Tres no han sido revisadas pero siguen abiertas (instancias que cubriremos en las próximas dos secciones más abajo), pero tres ya han sido fusionadas en la principal.

Esas son las solicitudes de extracción no revisadas que quieres ver más de cerca. Escanéalas cada vez que ocurran.

Puedes evaluarlos caso por caso. Aunque los estés revisando después de que se hayan fusionado, quieres asegurarte de que ningún problema se va a descontrolar. Cuanto antes los compruebe, más fácil será intervenir. A veces, si se trata de un compromiso trivial, puedes avisar a QA para que eche un vistazo de cerca. A veces, esas peticiones de extracción no revisadas no son triviales. Vuelve a revisarlas si puedes.

En cualquier caso, quieres reducir la cantidad y la frecuencia de las solicitudes de extracción no revisadas como mejor práctica. Si ciertos ingenieros son reincidentes, tenga una conversación informal con ellos sobre la importancia del proceso de revisión del código. Típicamente no es necesario ser muy severo con ellos. Enfoca tu conversación en una mejor planificación, más que en políticas y reglas. La mayoría de los ingenieros entenderán su razonamiento y harán su parte para reducir las solicitudes de revisión de códigos en el futuro.

2. Tire de los puntos calientes de la solicitud

Parte del desafío de gestionar el proceso de solicitud de extracción es que la gran mayoría de las solicitudes de extracción son rutinarias. Se abren, alguien hace algunos comentarios, tal vez el ingeniero comete algunos cambios, y luego se aprueban y se fusionan.

Las peticiones de atracción que no van en esa dirección pueden causar una perturbación bastante seria. Llamamos a esos disruptores «puntos calientes» de solicitud de extracción, y son más o menos lo opuesto a las relaciones públicas no revisadas.

Los puntos calientes ocurren cuando los ingenieros hacen muchos más comentarios de lo normal, con muchas idas y venidas, especialmente cuando se trata de un código muy pequeño. También se puede buscar un número inusual de compromisos de seguimiento que arrastran el proceso de revisión durante días. En cualquier caso, buscas una actividad excesiva que no llegue a ninguna conclusión. Estos puntos calientes a menudo señalan incertidumbre o desacuerdo.

Por supuesto, los comentarios excesivos y problemáticos dependen de la línea de base de su equipo. Lo primero que quieres hacer es entender cuál es el comportamiento normal de tu equipo.

Dinámica de la Solicitud de Extracción, como se ve en GitPrime

Estos gráficos indican el comportamiento normal de este equipo de ejemplo. Según los datos, este equipo suele resolver sus relaciones públicas rápidamente, en poco más de una hora. Pero también podemos ver, mirando los valores atípicos, que a pesar de un proceso bastante bueno, no todo va como se planeó. Estos círculos indican algunos puntos calientes potenciales.

Valores atípicos en el proceso de solicitud de extracción, como se ve en GitPrime

Se puede indagar en esos valores atípicos para comprender mejor la actividad que se está llevando a cabo y por qué esas peticiones particulares de extracción requieren tantos comentarios y compromisos de seguimiento sin ninguna resolución.

Perforación de las métricas de revisión de códigos en GitPrime

Clasificando por la actividad más alta, y trabajando de arriba hacia abajo, esta revisión de código tiene una cantidad anormal de actividad, como lo indican las barras y los círculos del cursor. Se abrió hace siete días, y no es grande, pero ya tiene dos compromisos de seguimiento, ocho comentarios, y ninguna aprobación. Considerando que este equipo normalmente aprueba un PR en una hora, un PR de siete días puede estar fuera de control. Es hora de que intervengas.

Puedes escanear la conversación para tener una idea de la revisión. En este caso, la conversación es cíclica y no se está resolviendo. Eso significa que es hora de que pongas a estos ingenieros en una habitación (o por teléfono, si el equipo está distribuido) para resolverlo. En casi cualquier caso, pasar treinta minutos en una pizarra probablemente evitará varios días más de giro. Además, dará dividendos en el intercambio de conocimientos.

Sea cual sea el enfoque que tomes, quieres que los ingenieros se comprometan y hablen de los problemas. ¿Cuál es el contexto del desacuerdo del punto caliente, o el diálogo saludable? Usa esa perspicacia para formar tu respuesta.

Además, anima a los ingenieros a resolver y cerrar esas relaciones públicas, porque las peticiones de atracción abiertas pueden generar incertidumbre en un equipo. Por otra parte, los compromisos de seguimiento excesivos pueden indicar que el trabajo no está listo para su revisión, en cuyo caso puede ser mejor retirar esa solicitud de extracción hasta que el ingeniero pueda tenerlo mejor preparado para el proceso de revisión.

3. Revisiones de códigos y relaciones públicas de larga duración

Las solicitudes de atracción de larga duración pueden parecer similares a los puntos calientes, pero realmente puedes mejorar tu proceso perforando en ellos de forma diferente. Las revisiones de código de larga duración pueden no ser un problema en sí mismas, a diferencia de los puntos calientes, pero tienden a señalar otros problemas subyacentes, como el desacuerdo o la incertidumbre entre los ingenieros. Tal incertidumbre puede ser el resultado de requerimientos faltantes, cambios de última hora en las especificaciones de diseño, componentes faltantes o simplemente inercia.

Indicado en los datos de abajo muestra una solicitud de extracción que potencialmente se está pasando por alto. Se abrió hace más de un mes. Tres personas comentaron una línea de código de inmediato, y luego eso se convirtió en silencio de radio.

Revisión de código descuidado o pasado por alto, como se ve en GitPrime

Esta revisión del código está atascada. Tal vez se ha caído. Tal vez una guerra está a punto de estallar por un desacuerdo y todo el mundo está tratando de evitar la puesta en marcha del polvorín. En cualquier caso, tienes un atasco y nadie sabe cómo resolverlo. En lugar de saltar al lodo, todos se han retirado.

Como líder, puedes echar un vistazo a los comentarios para ver si puedes obtener una lectura de la situación. Averiguar si los ingenieros están lidiando con desacuerdos o incertidumbres. Y luego, habiendo identificado al menos parte del problema detrás de las relaciones públicas de largo plazo, aprovecha el momento para intervenir y traer una resolución a la revisión.

Le recomendamos que empiece por hablar con el remitente. En última instancia, concluir que la revisión del código es responsabilidad del remitente, y no quieres tomar esa responsabilidad a la ligera. Revisa para ver cómo entienden el problema y ofréceles ayuda para navegar por las aguas con sus compañeros.

Tal vez todo el mundo necesita pasar de la conversación escrita a la verbal. Tal vez necesitan media hora en la pizarra. Tal vez sólo necesitan tu estímulo para seguir adelante y resolver la petición de atracción por sí mismos.

En cualquier caso, estás dando el cierre a una revisión del código y a tu equipo. Una solicitud de extracción a largo plazo es como una piedra en el zapato de tu equipo. Identificar estos irritantes con los datos puede hacer una diferencia significativa para ayudar a los ingenieros a trabajar bien juntos y avanzar como equipo.

4. Solicitudes de extracción bloqueadas

Las solicitudes de extracción bloqueada son costosas y frustrantes. Sus ingenieros quieren ser productivos, pero en el proceso de revisión, necesitan retroalimentación para ser productivos. Y una solicitud de extracción bloqueada ocurre cuando los ingenieros están atascados esperando esa retroalimentación.

Cuando los ingenieros presentan las relaciones públicas, están en la mentalidad de ese código. Están pensando en ello, y está fresco en sus mentes. Después de unas pocas horas, sin embargo, su concentración es por necesidad en otro lugar. Y su recuerdo de ese código tiende a ser más borroso y más vago cada día. Así que si los revisores del código son lentos para comentar, ese retraso puede perjudicar la capacidad de sus compañeros para ser productivos.

En otras palabras, es fundamental que los revisores proporcionen sus comentarios con prontitud para asegurar su pleno impacto.

Como líder, claro, puedes regañar a tu equipo para que sus críticas lleguen más rápido. Pero regañar no eleva exactamente la moral. Es útil cuando puedes aportar datos a la conversación.

Solicitud de movimiento lento o bloqueo de la atracción, como se ve en GitPrime

Aquí, Sarah abrió una solicitud de extracción y esperó seis días hasta que un revisor hizo un comentario. Tenía que hacer cuatro compromisos de seguimiento, lo cual logró bastante rápido, y luego su RP fue finalmente aprobado siete días después.

Eso significa que tomó casi dos semanas desde que escribió el código hasta que finalmente llegó a QA. Eso es menos que ideal en casi cualquier ambiente. Pero el retraso en el código de Sarah no se debió a la actuación de Sarah. Su revisor no respondió a sus relaciones públicas de manera oportuna y responsable.

«Tiempo de reacción» como se ve en GitPrime

Su crítico, Bodhan, tiene sus estadísticas relevantes resaltadas en esta pantalla. Parece que su tiempo de respuesta en este escenario es un patrón demostrable. En promedio, tarda un día en responder, y tarda incluso más tiempo con Chris que con Sarah.

Este tipo de patrón se vuelve tóxico porque habla del respeto a los compañeros de equipo de un ingeniero. Aunque no se pretenda faltar al respeto, mantener a los compañeros de equipo bloqueados es desconsiderar su tiempo y productividad.

En este ejemplo, Bodhan agrupa todo su trabajo de revisión hasta el final de sus días y luego lo mete todo. Eso es eficiente para él, porque está ocupado con su propio trabajo como ingeniero superior. Pero tiene un costo para el resto del equipo.

Afortunadamente, estos patrones tienden a ser bastante fáciles de manejar. Es importante establecer expectativas claras con los ingenieros de bloqueo, y puedes enfocar la discusión en el impacto a otros. Muchas veces, los ingenieros de bloqueo no se dan cuenta de las repercusiones de sus patrones. Están concentrados en su propio trabajo y ni siquiera han considerado que otras personas los están esperando.

En los datos, se puede identificar la capacidad de respuesta y el tiempo de reacción de un ingeniero, por lo que un lugar fácil para empezar es estableciendo algunos objetivos. Recomendamos establecer un máximo de 4 a 8 horas como tiempo de reacción objetivo. Normalmente, en cuatro horas, los ingenieros tienen un descanso en su almuerzo de trabajo, o una reunión, o cualquier hueco que sea normal en su cultura de trabajo. Esos descansos son un buen momento para animarles a hacer sus revisiones. Al concentrarse en ese tiempo para el primer comentario, se obtiene una petición de retirada para un comienzo fuerte y se establece el tono para todo el proceso.

Normalmente, una charla informal con un ingeniero de bloqueo hará toda la diferencia en el mundo. Cuando la gente se da cuenta de que sus compañeros de equipo dependen de ellos, casi siempre corrigen el rumbo correcto. De vez en cuando, puede que se encuentre con un problema recurrente, pero encontramos que casi nunca ocurre con este patrón.

El siguiente: El lado de la gente y la colaboración de las revisiones de código

Eso abarca las cuatro dinámicas basadas en el proceso de examen de códigos de las mejores prácticas que se pueden identificar con los datos y adoptar medidas al respecto. En el próximo post, continuaremos nuestra exploración de las dinámicas basadas en la gente de las revisiones de códigos.