Un equipo hereda un módulo de facturación que nadie comprende del todo. No cuenta con pruebas que garanticen su correcto funcionamiento. Se propone un sprint para optimizarlo, y el plan consiste en reescribir el núcleo con una nueva estructura. Nadie sabe cómo garantizar que la nueva versión siga facturando correctamente a los clientes.
Este es un escenario ilustrativo, no un incidente documentado. Describe la brecha que debe cerrar un proyecto de capacitación en refactorización: ingenieros que pueden ver que el código es desordenado, pero que aún no pueden planificar una mejora delimitada y demostrar que se conservó el comportamiento esperado.
Esta guía está dirigida a responsables de capacitación en ingeniería y gerentes de ingeniería. Cubre cómo describir el problema de rendimiento, diagnosticar las deficiencias, diseñar la preparación y la práctica, analizar un caso práctico y evaluar si la habilidad se transfiere al trabajo real. Se centra en el diseño de la capacitación. El código, las pruebas y las reglas de su programa deben ser validados por ingenieros sénior en su propio entorno.
¿Qué es un proyecto de formación en refactorización?
Un proyecto de capacitación en refactorización es un trabajo estructurado sobre código heredado, cuyo objetivo es desarrollar habilidades y, al mismo tiempo, mejorar el código. Los participantes planifican un cambio pequeño y delimitado, protegen el comportamiento existente con pruebas, mejoran el diseño gradualmente y demuestran que no se produjo ningún fallo. El código mejora y, lo que es más importante, los ingenieros practican el criterio que necesitarán para abordar problemas técnicos reales.
Datos Rápidos
| Pregunta | Respuesta corta |
|---|---|
| ¿Cuál es la tarea? | Planificar y validar una mejora limitada del código heredado. |
| ¿Qué puntuación obtienes? | Análisis de riesgos y evidencia de que se conservó el comportamiento existente. |
| ¿Una revisión exhaustiva del texto es un buen proyecto de formación? | Normalmente no. Oculta la habilidad que se está practicando y dificulta demostrar el comportamiento conservado. |
| ¿Es suficiente un cuestionario sobre patrones de refactorización? | No. Confirma los requisitos previos, pero no si un ingeniero puede planificar y validar un cambio. |
| ¿Quién valida el contenido? | Un gerente de ingeniería y un ingeniero sénior que conozca el código fuente. |
| ¿Qué no puede solucionar la formación? | Falta de herramientas de prueba, presión de liberación, propiedad poco clara y falta de tiempo para trabajos de mantenimiento. |
| ¿Cómo sabes que funcionó? | Un nuevo caso de código heredado, nunca antes visto, evaluado según criterios acordados, con seguimiento en el trabajo real. |
1. Describa el problema de rendimiento.
Comencemos con la tarea: planificar y validar una mejora limitada del código heredado. La palabra clave es "limitada". El alumno elige un cambio lo suficientemente pequeño como para completarlo y puede definir qué está dentro y fuera del alcance.
Es útil ser preciso con los términos. Martin Fowler describe la refactorización como una técnica controlada para mejorar el diseño de una base de código existente , compuesta por pequeñas transformaciones que preservan el comportamiento. La frase "preservar el comportamiento" es lo que distingue la refactorización de una reescritura, y es lo que la formación debe dejar claro. La metáfora de la deuda técnica fue acuñada por Ward Cunningham , y la explicación de Fowler nos recuerda que la deuda puede asumirse de forma deliberada y prudente, por lo que no todos los módulos desordenados son errores que deban corregirse.
El libro de Michael Feathers sobre código heredado adopta la misma postura práctica. La descripción de su editorial indica que enseña a los desarrolladores a escribir pruebas que garanticen que no están modificando la aplicación de forma involuntaria y a controlar el software existente sin necesidad de reescribirlo por completo.
Redacte la declaración de rendimiento en una sola frase y pídale a un gerente de ingeniería que la revise: “Dado un módulo heredado y un objetivo definido, el ingeniero propone un cambio limitado, agrega pruebas que determinan el comportamiento actual, realiza el cambio en pequeños pasos y demuestra que el comportamiento se conserva”.
2. Diagnosticar las deficiencias de aprendizaje y contexto.
Antes de construir nada, compara la tarea requerida con lo que practicas y evalúas en tus actividades actuales. Generalmente, tres preguntas permiten distinguir una deficiencia en la capacitación de otra cosa:
- ¿La práctica actual utiliza la tarea real? Si la capacitación incluye patrones de refactorización en diapositivas, pero nadie modifica código sin probar, nadie ha practicado comportamientos seguros. Si la evaluación consiste en una prueba de opción múltiple sobre malas prácticas de programación, mide la capacidad de recordar.
- ¿Cuál es la demanda cognitiva? En la taxonomía revisada de Bloom, juzgar si un cambio es seguro se sitúa en los niveles de análisis y evaluación, y diseñar el plan y las pruebas alcanza el nivel de creación. La correspondencia de las actividades con esos niveles se trata en nuestra guía para relacionar las actividades de aprendizaje con la taxonomía de Bloom..
- ¿Hay algo más que la habilidad que esté interfiriendo? Revisa el personal, las herramientas y los procedimientos. Si la compilación tarda una hora, nadie realizará pruebas con frecuencia. Si nunca se programan tareas de mantenimiento, los ingenieros solo refactorizarán en secreto. Informa de las causas ajenas a la capacitación a las personas que pueden solucionarlas.
3. Diseñar una preparación y práctica con un propósito definido.
Una vez que sepas qué carencias puede subsanar la formación, asigna una función específica a cada etapa.
Preparación. Compruebe los requisitos previos con un breve diagnóstico: cómo funciona su marco de pruebas, qué es una prueba de caracterización y cómo su equipo realiza las revisiones y fusiones. El estudio a su propio ritmo es adecuado para esta etapa. Una revisión de conocimientos solo confirma los requisitos previos.
Practica. Utiliza proyectos de refactorización sistemáticos con una estructura clara. Empieza con una muestra pequeña y segura, luego pasa a una parte real pero delimitada de tu propio código. El kata de Gilded Rose es un punto de partida conocido para el primer paso. Su archivo README, mantenido por Emily Bache, recomienda escribir pruebas antes de modificar el código y plantea el ejercicio como una práctica para dar pequeños pasos, ejecutar las pruebas con frecuencia y mejorar el diseño poco a poco. Una secuencia sensata para cada proyecto es: definir el objetivo y el alcance, escribir pruebas que capturen el funcionamiento actual del código, modificar una cosa a la vez, ejecutar las pruebas después de cada paso y anotar lo aprendido.
Comentarios. Vincula los comentarios a las decisiones, no a la puntuación total. "Extrajiste la lógica del descuento, pero tus pruebas solo cubrieron el escenario ideal, por lo que no pudiste haber notado el cambio de redondeo" es más útil que "3 de 5".
¿Intervención en directo del instructor o revisión asíncrona? La intervención en directo aporta mayor valor cuando la decisión es ambigua, por ejemplo, si detenerse y añadir una prueba que falta o continuar. La revisión asíncrona es suficiente cuando los alumnos comparan su plan y sus pruebas con una versión comentada por un experto. Muchos equipos utilizan ambas opciones: primero, preparación a ritmo propio, y después, una sesión guiada para los casos más difíciles.
4. Analice un ejemplo realista.
A modo de ejemplo, un gerente de ingeniería debe validar el caso y los criterios de respuesta antes de su uso.
El caso. Una función heredada calcula el total de un pedido, incluyendo un descuento, impuestos y una regla de envío. No tiene pruebas. Un equipo propone reestructurar todo el módulo de facturación para hacerlo más "limpio".
La tarea. El alumno explica qué haría, cita las pruebas que reuniría e indica qué información o apoyo adicional necesita.
Un primer intento. «Dividiría el módulo en tres servicios y trasladaría la lógica, para luego comprobar los números en el entorno de pruebas». El estudiante ha optado por un cambio importante y una verificación manual tardía. No hay forma de saber si las versiones antigua y nueva coinciden en los casos límite.
Retroalimentación y reintento. El revisor pregunta qué hace la función actualmente con una cesta vacía, un descuento que hace que el total sea negativo y un caso de redondeo. El reintento pide al alumno que se centre en un solo comportamiento y que explique cómo demostraría que no ha cambiado.
Un intento más contundente. «Por ahora, dejaría la estructura del módulo intacta. Capturaría el valor que devuelve la función de total del pedido para un conjunto de entradas, incluyendo los casos límite, a modo de prueba. Luego, extraería el cálculo del descuento a una función independiente, ejecutaría las pruebas tras ese único paso y me detendría. Tomaría nota de que la regla de envío presenta un comportamiento que desconozco y consultaría con un colega antes de modificarla». Nótese que esta respuesta delimita el cambio, prioriza la protección del comportamiento y especifica lo que se desconoce.
Explica por qué cada respuesta es defendible o incompleta. Cada una debe evaluarse según criterios aprobados, no según la preferencia del revisor. El primer intento puede ser una dirección sensata a largo plazo, pero es incompleto como plan, ya que no presenta evidencia de un comportamiento preservado. El intento más sólido es pequeño, verificable y honesto respecto a la incertidumbre.
5. Evaluar la capacidad y planificar la transferencia
La evidencia de capacidad se manifiesta en el desempeño en un nuevo caso de código heredado que el aprendiz no ha visto. Califique el análisis de riesgos y la evidencia de que el comportamiento se mantuvo. Una rúbrica simple utiliza una escala de 0 a 2 por criterio:
| Criterio | Evidencia observable |
|---|---|
| Ejecución de tareas | Planifica y valida una mejora delimitada del código heredado, y registra la acción realizada y las pruebas que la respaldan. |
| Razonamiento | Explica las limitaciones, las alternativas y la incertidumbre, y verifica los riesgos y las pruebas de que el comportamiento se mantuvo. |
| Límites | Utiliza los procedimientos aprobados y solicita ayuda cuando la información o la autoridad son insuficientes. |
Anclajes: 0 indica ausencia o falta de apoyo, 1 indica parcialidad con omisiones relevantes y 2 indica completitud y justificación según criterios acordados. Defina los errores críticos por separado, como cambios de comportamiento sin que ninguna prueba los haya detectado, para que la puntuación general no los oculte. Esta rúbrica es una propuesta, no un estándar de preparación validado: adáptela con un gerente de ingeniería y póngala a prueba. Nuestra guía para diseñar prácticas interactivas con retroalimentación útil muestra cómo redactar comentarios que se vinculen con las decisiones.
Planifique la transferencia con detenimiento. Tras el ejercicio, asigne a cada ingeniero una pequeña tarea real que deberá abordar con un revisor, o realice una breve retrospectiva sobre un cambio reciente que haya causado algún problema. Verifique la transferencia después de una exposición adecuada al trabajo real, no inmediatamente después del taller.
Donde la entrega interactiva ayuda
Los formatos interactivos ayudan cuando todos deben comprometerse antes de ver al grupo. En una sesión en vivo, un facilitador puede mostrar un breve fragmento de código heredado, pedir a cada ingeniero que envíe el primer cambio que haría y cómo lo demostraría seguro, y luego revelar la distribución antes de la discusión. La misma pregunta puede ejecutarse a ritmo propio para la preparación. AhaSlides admite el aprendizaje interactivo y la alternancia entre la entrega en vivo y a ritmo propio. Es una herramienta de presentación y aprendizaje, no un lugar para ejecutar o analizar código, así que ejecute la refactorización en su propio entorno. Verifique cualquier función específica de autoría, retroalimentación o informes que planee utilizar con su propio flujo de trabajo. Para obtener orientación sobre la elección de formatos, consulte nuestro artículo sobre cuándo usar el aprendizaje adaptativo, interactivo y en vivo.
Mide lo que cambió
Decida de antemano qué demostraría que los ingenieros son capaces de realizar la tarea. Compare la calidad del análisis de riesgos y la evidencia de un comportamiento preservado en un caso no visto, con respecto a una referencia. Defina quiénes participan, el denominador y el plazo. Si los resultados mejoran, verifique qué otros cambios se produjeron durante el mismo período, como nuevas herramientas de prueba, una construcción más rápida o un cambio de propietario, antes de atribuir el mérito a la capacitación.
Restricciones que pueden persistir
- Es hora de realizar trabajos de mantenimiento. Si nunca se programan trabajos para saldar deudas, los ingenieros capacitados seguirán sin tener dónde utilizar sus habilidades.
- Herramientas de prueba. Sin un entorno de prueba útil o un proceso de construcción rápido, resulta difícil mantener pequeños pasos y comprobaciones frecuentes.
- Cobertura del caso. Un caso histórico ilustra varios tipos de riesgo. Una puntuación no refleja el criterio general de un ingeniero.
- Saber cuándo no refactorizar. Algunos códigos es mejor dejarlos como están, reemplazarlos o retirarlos, y esa decisión implica algo más que habilidad.
- Transferencia El rendimiento en un kata no es lo mismo que el rendimiento en un módulo de producción bajo presión de entrega.
Comuniquen estos problemas a los patrocinadores con anticipación y planifiquen soluciones específicas. La capacitación mejora la capacidad de planificación y demostración de un ingeniero, pero no genera el tiempo ni las herramientas necesarias.
Preguntas frecuentes
¿Qué es un proyecto de formación en refactorización?
Se trata de una práctica estructurada sobre código heredado en la que los ingenieros planifican un pequeño cambio, protegen el comportamiento existente con pruebas, modifican el diseño en pequeños pasos y demuestran que nada se ha roto.
¿Es una buena manera de aprender sobre la deuda técnica reescribir el texto completo?
Por lo general, no. Reescribir el código es un proceso extenso, difícil de validar y que oculta la habilidad que se desea desarrollar. Un cambio controlado, con pruebas que registren el comportamiento actual, permite visualizar el razonamiento.
¿Cómo se evalúa si los ingenieros pueden refactorizar de forma segura?
Proporcione un nuevo caso de código heredado y evalúe el análisis de riesgos y la evidencia de que el comportamiento se mantuvo según los criterios acordados. Un cuestionario sobre patrones de refactorización solo confirma los requisitos previos.
¿Necesitas un código fuente de ejemplo para la formación?
Necesitas un lugar seguro para practicar. Muchos equipos comienzan con un kata público y luego pasan a una sección delimitada de su propio código. Tu jefe de ingeniería debe confirmar que el código sea adecuado.
Por dónde empezar
Seleccione un cambio pequeño y recurrente en su código fuente. Redacte la declaración de rendimiento, pida a un gerente de ingeniería que valide el caso y las pruebas que demuestren que el comportamiento se mantiene, y elabore una rúbrica de tres criterios con una escala de 0 a 2 y una lista de errores críticos. Realice una prueba piloto con un grupo pequeño antes de implementarlo.
Para ver cómo un ejercicio de toma de decisiones sobre refactorización podría llevarse a cabo en directo con tu propio equipo y reutilizarse posteriormente a tu propio ritmo, explora AhaSlides.
