Puesto
Desarrollador de software
¿Cuánto tarda una persona nueva del equipo en hacer su primer cambio con sentido? Esa cifra dice más de vuestro código y vuestra documentación que cualquier métrica de calidad.
Conversación inicial
Cuatro preguntas por las que empezaríamos
¿Cuánto tarda una persona nueva en hacer su primer cambio?
Si son semanas, pagáis el coste de incorporación en cada rotación, y la rotación en esta profesión es un hecho.
¿Qué aplazáis primero cuando una fecha aprieta?
Normalmente las pruebas y ordenar el código, que es lo que se convierte en la deuda que paga el trimestre siguiente.
¿Adónde va el conocimiento de por qué algo se hizo así?
Si va a una conversación en la revisión de código, dentro de seis meses nadie sabrá si fue una elección o un accidente.
¿Qué tipo de tarea se repite más a menudo?
Normalmente tres o cuatro patrones, y normalmente nadie los ha contado.
Nos quedamos con el trabajo repetitivo, vosotros con el diseño y el criterio
Entender el contexto del código, preparar cambios repetitivos, preparar pruebas y una primera pasada de revisión se pueden quitar del escritorio. Las decisiones de diseño y el juicio final sobre el código se quedan con una persona.
- El contexto llega más rápido que leyendo. - Qué hace este módulo, quién lo cambió y qué cambios están relacionados con él, antes de que el desarrollador empiece a leer línea a línea.
- La revisión empieza por lo que el linter y la integración continua no detectan. - El formato y las pruebas casi con seguridad los tenéis bajo control desde hace tiempo. Esta es la capa de encima: si el cambio toca lugares que el autor pudo no notar y si repite una solución rechazada hace seis meses.
- La deuda se ve en lugar de sentirse. - Los lugares que más se cambian y los de mayor complejidad están señalados, así que la conversación sobre refactorizar tiene base.
Alcance
Qué se puede quitar de un equipo de desarrollo
Diecinueve tareas de ejemplo. Cada una tiene un punto de aprobación humana. Abajo una selección, y el alcance lo ajustamos a vuestro stack y vuestro proceso.
Comprensión del código y su contexto
- Una descripción de qué hace un módulo, a partir del código (verificación: el desarrollador)
- Señalar los lugares relacionados con el fragmento que se cambia
- El historial de cambios en el área con sus motivos
- Señalar la documentación que cubre el área
Escritura del cambio
- Un borrador de cambio para patrones repetitivos (criterio y corrección: el desarrollador)
- Una propuesta de pruebas para el cambio escrito
- Señalar los lugares que hay que actualizar tras el cambio
- Una señal cuando un cambio rompe las convenciones acordadas
Revisión de código
- Una primera pasada de revisión antes de la revisión humana
- Señalar las pruebas que faltan
- Señalar los cambios que tocan lugares relacionados que el autor pudo no conocer
- Cambios a revisar ordenados por riesgo (decisión: el revisor)
- Un recordatorio sobre una revisión que está esperando
Pruebas y entrega
- Una propuesta de casos que las pruebas existentes no cubren
- Señalar las pruebas que dejaron de pasar y el motivo del cambio de comportamiento
- Enlazar el cambio con la tarea y la entrega
Deuda técnica
- Señalar las áreas que más se cambian
- Un resumen de los lugares de mayor complejidad
- Enlazar los fallos de producción con áreas del código
Un día de trabajo
Hoy
- Antes de un cambio leéis el módulo para entender siquiera qué hace
- Encontráis los lugares relacionados buscando y con la memoria del equipo
- Escribís el trabajo repetitivo a mano, aunque siempre tiene el mismo aspecto
- El revisor deduce por su cuenta qué más toca este cambio
- Una revisión espera un día o dos, porque nadie sabe que está esperando
- Habláis de deuda técnica en la retrospectiva, sin datos
Con asistencia de IA
- Tenéis la descripción del módulo y los lugares relacionados antes de leer el código
- Un cambio repetitivo tiene borrador, vosotros lo juzgáis y lo corregís
- Las pruebas del cambio tienen propuesta
- Los lugares relacionados se señalan junto al cambio en lugar de buscarse
- Una revisión que espera avisa de sí misma
- La deuda técnica se señala con cifras y no con una impresión
- Tiempo hasta un primer cambio
una persona nueva entra antes en el código
el contexto de un módulo está disponible sin leerlo entero
- Tiempo de espera de una revisión
los cambios no se quedan en la cola sin que nadie los vea
recordatorios y un orden basado en el riesgo
- Calidad de la revisión
el revisor ve el alcance del cambio y no solo el diff
los lugares relacionados y el historial de decisiones están junto al cambio
- Deuda visible
la conversación sobre refactorizar tiene base en cifras
las áreas que más se cambian y las complejas están señaladas
Empezamos por el contexto y la revisión, porque es lo menos arriesgado y lo que antes se nota.
- Paso 1
Contexto del código y relaciones
Descripciones de módulos, historial de cambios, lugares relacionados.
- Paso 2
Primera pasada de revisión y pruebas antes de la revisión humana
Convenciones, pruebas que faltan, errores evidentes antes del ojo de una persona.
- Paso 3
Borradores de cambios repetitivos
Solo los patrones que se repiten de verdad, y siempre con el criterio del desarrollador.
- Paso 4
Deuda visible
Las áreas que más se cambian, enlazadas con los fallos de producción. Al final, porque requiere historia.
Preguntas frecuentes
Preguntas que surgen en la primera reunión
¿Y el código que no podemos enviar a ninguna parte?
Es una condición habitual y se resuelve en la fase de arquitectura, no en el contenido. Las soluciones que corren dentro de vuestra propia infraestructura son reales; si no lo son, el alcance se estrecha a lo que se puede hacer sin enviar código fuera. Esa conversación conviene tenerla antes y no después.
Esta es la pregunta que hoy se hace todo el mercado: ¿sustituirá la IA a los programadores?
La respuesta honesta: no dentro del alcance descrito aquí, y no pretendemos tener respuesta a la pregunta entera. Lo que proponemos se refiere al contexto del código, a los patrones repetitivos y a la primera pasada de revisión, que de todos modos es el trabajo que un desarrollador considera menos interesante. Las decisiones de diseño, juzgar las compensaciones y la responsabilidad por lo que llega a producción se quedan con el equipo. Si asumimos más que eso, perdéis vosotros y no nosotros, y por eso la línea conviene fijarla con el equipo y no por él.
¿Esto entra en el ámbito del Reglamento de IA?
Producir software no es un uso de alto riesgo. El único punto que requiere cuidado es que los datos sobre cambios de código no se usen para comparar la productividad de desarrolladores concretos: llevamos los resúmenes por área de código y no por autor.
¿Os queda alguna pregunta que no esté aquí? Reservad una llamada
Siguiente paso
¿Cuánto tiempo dedica vuestro equipo a leer código antes de cambiarlo?
Os enseñaremos cómo es el trabajo de un equipo cuando el contexto llega antes y la revisión de código empieza por las decisiones de diseño.