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 diferencia la refactorización de la reescritura, y es lo que la capacitación debe hacer visible. La metáfora de la deuda técnica en sí misma El término fue acuñado por Ward Cunningham.Además, la reflexión de Fowler nos recuerda que la deuda puede contraerse 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 línea en cuanto a la práctica. La descripción de su editorial dice que enseña a los desarrolladores a escribir pruebas que garanticen No están cambiando la aplicación de forma involuntaria.y para 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. Comprueba los requisitos previos con un breve diagnóstico: cómo funciona tu marco de pruebas, qué es una prueba de caracterización y cómo tu equipo realiza las revisiones y fusiones. El estudio a tu propio ritmo es adecuado para esta etapa. Una comprobación de conocimientos solo confirma los requisitos previos.
Práctica. Utilice proyectos de refactorización sistemáticos con una estructura clara. Comience con una muestra pequeña y segura, luego pase a una parte real pero delimitada de su propio código. El kata Gilded Rose es un punto de partida bien conocido para el primer paso. Su README, mantenido por Emily Bache, Recomienda escribir pruebas antes de cambiar 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 la retroalimentación 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 del instructor en directo o revisión asíncrona? La retroalimentación en tiempo real aporta mayor valor cuando la decisión es ambigua, por ejemplo, si detenerse y agregar una prueba faltante o continuar. La revisión asíncrona es suficiente cuando los estudiantes comparan su plan y pruebas con una versión experta comentada. Muchos equipos utilizan ambos métodos: primero, preparación a ritmo propio, y luego 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 del pedido, incluyendo el descuento, los impuestos y la política de envío. No tiene pruebas. Un equipo propone reestructurar todo el módulo de facturación para hacerlo más eficiente.
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 verificar 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.
Comentarios 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. En el segundo intento, se le pide al alumno que limite el alcance a un solo comportamiento y que explique cómo demostraría que no ha cambiado.
Un intento más enérgico. “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 daría por concluido el proceso. 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.
Explicar por qué cada respuesta es defendible o incompleta. Evalúe cada opción según criterios aprobados, no según la preferencia del revisor. El primer intento puede ser una dirección sensata a largo plazo, pero resulta incompleto como plan, ya que no presenta evidencia de un comportamiento preservado. El intento más sólido es modesto, 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 significa ausente o sin respaldo, 1 significa parcial con omisiones relevantes y 2 significa completo y justificado según los criterios acordados. Defina los errores críticos por separado, como el cambio de comportamiento sin ninguna prueba que lo hubiera detectado, para que una puntuación general no pueda ocultar uno. 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 estén vinculados a 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 a que todos se comprometan 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 como seguro, y luego revelar la distribución antes de la discusión. La misma pregunta se puede ejecutar a ritmo propio para la preparación. AhaSlides admite el aprendizaje interactivo y la alternancia entre la presentación 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 en la que planee confiar con su propio flujo de trabajo. Para obtener orientación sobre cómo elegir formatos, consulte nuestro artículo sobre cuándo utilizar el aprendizaje adaptativo, interactivo y en directo.
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.
