Cualquier Vibe Coder genera código que una máquina puede ejecutar.
Los buenos programadores escriben código que otros devs —y la propia IA— pueden mantener.
Refactoring SostenibleTécnicas para mantener el Legacy Code bajo controlEsto lo dijo Martin Fowler hace más de 20 años. Bueno, en realidad dijo "cualquier tonto", no "Vibe Coder"... pero bueno, tú me entiendes.
La mayoría de los programadores siguen dejando el código a medias. Y Claude, Codex, Copilot (pon aquí el LLM que quieras) también.
Digo a medias porque aunque la funcionalidad esté completa el trabajo está sin acabar.
Me explico.
Que el código funcione no significa que esté terminado.
Y es que los developers muchas veces nos olvidamos de la otra mitad del trabajo.
La que tiene que ver con hacer el código sostenible.
Con sostenible me refiero a fácil de mantener.
Y con fácil de mantener quiero decir sencillo de cambiar.
Si, cambiar.
Porque hay una verdad absoluta en el software: si un proyecto tiene cierto éxito cambiará.
¿Y cómo se consigue esto?
Pues escribiendo código basado en la simplicidad.
Y es que como decía Steve Jobs: la simplicidad es la máxima sofisticación.
El problema es que escribir código simple es una tarea tremendamente compleja.
Requiere de un nivel de consciencia y pragmatismo a la hora de codificar totalmente fuera de lo común.
Verás.
Cuando programamos desconocemos tantas cosas que vamos acumulando deuda técnica sin darnos cuenta.
A veces porque no nos preocupamos de pensar si la manera en la que estamos desarrollando una funcionalidad es la más simple.
O quizás sea por las prisas y la sensación de urgencia constante.
Otras ni siquiera somos conscientes de que estamos arruinando el código, simplemente ocurre por desconocimiento o falta de entrenamiento.
Desconocimiento unas veces de las necesidades reales del negocio y otras veces de la propia técnica.
La realidad es que nadie escribe el código perfecto a la primera.
Ni tú.
Ni yo.
Ni nadie.
Por más cuidado que pongas (o por muy bueno que seas) cometerás errores de diseño que solamente se pueden subsanar de una manera:
Mediante la refactorización permanente, diaria. No hay otra.
«El product manager no me deja escribir más condicionales»
Esto no lo escucharás nunca salir de la boca de tu jefe.
Lo que sí escucharás es que no hay tiempo para refactorizar, para hacer tests o para dedicar tiempo a un buen diseño.
Es cierto que existe la posibilidad de que cualquiera de nosotros termine dirigido por un micromanager.
Ya sabes, de esos que están todo el día encima mirando cada detalle.
Aunque admito que esto puede ser un problema, descargar la responsabilidad en otras personas no es la solución.
Tenemos que preguntarnos dónde está el límite entre las tareas de las que somos responsables como programadores y las que son trabajo de otro.
¿A qué no le dices al manager cuantos condicionales o cuantas funciones tienes pensado escribir en el próximo sprint?
Sería ridículo hacerlo, ¿verdad?
Entonces, por qué pedimos permiso para refactorizar, hacer tests o dedicar tiempo a un buen diseño, en lugar de seguir haciendo ñapas…
Déjame adivinar, seguro que te dicen todo el rato:
«Ahora no hay tiempo para refactorizar, ya lo haremos cuando se pueda»
Esta frase tendría sentido si no se abusara de ella.
Hay ocasiones en las que esto es así pero está claro que no es la mayor parte del tiempo.
Y es que un producto de calidad no se puede desarrollar en permanente situación de urgencia.
Importante y urgente no son lo mismo.
Y no todo es igual de importante ni de urgente.
La realidad es que cuando tienes soltura refactorizando desarrollas más rápido que sin hacerlo porque ahorras tiempo depurando.
Verás.
El cuello de botella de los proyectos no está en el teclado.
La mayor parte del tiempo se esfuma tratando de entender el código para averiguar dónde hay que introducir los cambios.
Se malgastan mucho más recursos en leer y depurar el código que en escribirlo.
Por esta razón un verdadero Senior NO pide permiso refactorizar.
Un verdadero senior NO pide permiso para mejorar el código cada vez que tiene ocasión (pero si consensúa las decisiones que impactan en el negocio).
En realidad ningún programador que sepa lo que está haciendo debería pedir permiso para refactorizar.
No tiene que ver con ser junior o senior.
Ahora bien, pedir permiso para formarse es otra cosa…
Si no tienes experiencia ni haciendo tests, ni refactorizando y quieres empezar a hacerlo tienes que comunicarlo.
Sobre esto no hay duda al respecto.
Hay que entender que refactorizar es más que una tarea técnica.
Refactorizar tiene valor de negocio porque su función principal es asegurar que el lenguaje y el conocimiento del dominio están reflejados en el código.
Por eso hemos creado Refactoring Sostenible: un programa pensado para que aprendas a mantener el legacy code bajo control con un enfoque pragmático que funciona incluso cuando hay prisas, bugs y deadlines imposibles.
Refactoring SostenibleTécnicas para mantener el Legacy Code bajo control
Una formación organizada en 14 módulos, con más de 100 vídeos teóricos y prácticos para que aprendas paso a paso. Además contarás con soporte, acompañamiento y code reviews por email.
Módulo 1: La degeneración del código
Pocas cosas motivan más a un desarrollador que empezar un proyecto desde cero, un greenfield project.
Un repositorio vacío, el stack que eliges tú y la idea (ingenua) de que esta vez no habrá dolores de cabeza.
Pero esa sensación de frescura no dura mucho.
Las prisas, la rotación de gente, los atajos “solo por ahora”… y poco a poco el código empieza a torcerse.
No porque el problema sea demasiado complejo, sino por la deuda técnica que vamos acumulando sin darnos cuenta.
Y llega un momento en que ese código, que debería ser un activo, se convierte en un freno.
En algo que nadie quiere tocar. En legacy code.
En este módulo verás:
- Por qué el código se degrada con el tiempo incluso cuando lo escribes con buenas prácticas (y cómo anticipar ese proceso).
- Qué distingue a un software complejo por el reto que resuelve… de otro que se vuelve inmanejable por pura complejidad accidental.
- Los pequeños “accidentes” diarios —malos nombres, arquitecturas sobredimensionadas, inconsistencias— que parecen inofensivos hasta que pasan factura.
- Las distintas definiciones de legacy code (de Michael Feathers, J.B. Rainsberger y otros) y cuál es la que realmente marca la diferencia en tu trabajo.
- Cómo reconocer cuándo tu sistema se está convirtiendo en una bola de deuda técnica y qué señales anticipan la avalancha.
- La mentalidad necesaria para mantener un proyecto sostenible en el tiempo sin caer en la tentación de tirarlo todo y reescribirlo desde cero.
Módulo 2: Repaso a las reglas del diseño simple y POLA
“Hay dos maneras de diseñar software: hacerlo tan simple que sea obvio que no hay defectos, o tan complejo que no sea obvio descubrirlos.
Por desgracia, la primera opción es mucho más complicada”.
— Tony Hoare
La simplicidad parece fácil… hasta que intentas aplicarla.
Por eso, este módulo es un repaso a lo básico: las reglas del diseño simple de Kent Beck y el Principio de Menor Sorpresa (POLA).
Dos principios que no brillan por sofisticados, pero que separan al código que resiste el paso del tiempo del que se convierte en un lastre que nadie quiere mantener.
En este módulo verás:
- Las cuatro reglas del diseño simple de Kent Beck y cómo usarlas como brújula en cualquier proyecto.
- Por qué el verdadero objetivo no es la reutilización, sino la capacidad de cambiar el código con confianza.
- Cómo escribir tests que de verdad aporten valor (y qué errores comunes convierten un test suite en lastre).
- Qué significa en la práctica que el código revele su intención y cómo evitar la selva de convenciones arbitrarias.
- La diferencia entre duplicar líneas de código y duplicar conocimiento, y cuándo refactorizar o dejarlo quieto.
- Por qué “no vas a necesitarlo” (YAGNI) y “mantenlo simple” (KISS) son la mejor defensa contra la complejidad accidental.
- Cómo aplicar el Principio de Menor Sorpresa (POLA) para que tu código haga exactamente lo que dice… y nada más.
Módulo 3: Repaso a cohesión y acoplamiento
“La cohesión y el acoplamiento son las leyes de la física del diseño de software.”
— Kent Beck
Si las reglas del diseño simple son la brújula, la cohesión y el acoplamiento son la estrella polar: marcando el rumbo, aunque muchos desarrolladores las pasen por alto.
En teoría, todos repetimos el mantra: “alta cohesión, bajo acoplamiento”.
En la práctica, casi nadie lo aplica de manera deliberada.
En este módulo verás:
- Qué significa de verdad “alta cohesión” y “bajo acoplamiento” más allá del eslogan repetido en conferencias.
- Por qué el acoplamiento no es malo en sí mismo, pero el diseño inconsciente es lo que convierte cualquier sistema en una pesadilla.
- Cómo identificar si tus módulos trabajan como un sistema bien engranado… o como piezas que se entorpecen entre sí.
- La métrica de connascence para medir el nivel de acoplamiento y entender qué dependencias son las que generan más problemas.
- Los tres beneficios directos de la cohesión: menos carga cognitiva, menos efectos secundarios y más libertad para refactorizar.
- Qué code smells como Shotgun Surgery revelan falta de cohesión y cómo detectarlos antes de que tu sistema se vuelva complejo de mantener.
Módulo 4: Theatrical Players Kata
Pocas cosas hay más aburridas que hablar de refactoring en abstracto.
Por eso, en este módulo nos ponemos manos a la obra y empezamos directamente con un ejemplo real: la Theatrical Players Kata, uno de los ejercicios más conocidos de Martin Fowler.
Verás cómo un código aparentemente sencillo se convierte en una maraña de code smells y cómo refactorizarlo paso a paso hasta dejarlo listo para evolucionarlo con seguridad.
En este módulo aprenderás:
- Cómo enfrentarte a una función llena de responsabilidades mezcladas sin perderte en el proceso.
- La importancia de los tests como red de seguridad y qué hacer cuando no son perfectos.
- Estrategias para extraer funciones pequeñas y con responsabilidades bien definidas, apoyándote en refactors automáticos del IDE.
- Cómo eliminar acumuladores y bucles enrevesados transformándolos en código declarativo más expresivo y legible.
- La técnica de Split Phase para separar cálculos de la presentación y evitar duplicidades reales.
- Cómo organizar cálculos, formatos y tipos en módulos distintos para mejorar cohesión y facilitar la evolución del sistema.
- Una forma de extender el sistema sin romper nada, gracias al principio de separation of concerns.
Módulo 5: Fundamentos de refactoring
“La perfección no se alcanza cuando no hay nada más que añadir, sino cuando ya no queda nada que quitar.” — Antoine de Saint-Exupéry
El buen código no nace perfecto, se pule cada día a base de pequeñas mejoras.
Refactorizar es ese proceso de quitar ruido, aclarar la intención y dejar el sistema listo para evolucionar con confianza.
En este módulo verás:
- Qué es refactoring de verdad (y qué no lo es): ni reescritura desde cero, ni arreglar bugs, ni optimizar rendimiento.
- Por qué refactorizar es un acto de ingeniería con impacto directo en el negocio, no un capricho estético.
- Cómo aplicar la regla del boy scout para dejar el código un poco mejor cada vez que lo tocas.
- Cuándo refactorizar y cuándo no: señales claras que indican que merece la pena (y casos en los que es mejor dejarlo quieto).
- La importancia de los baby steps y los tests como red de seguridad para no romper lo que ya funciona.
- Por qué “si funciona y no hay que cambiarlo, no lo toques” es una regla de oro para evitar pérdidas de tiempo y bugs innecesarios.
Módulo 6: Estrategias de refactoring
Refactorizar no es solo cuestión de técnica: también es estrategia.
Saber cómo dar los pasos marca la diferencia entre un cambio controlado que mejora el sistema… y una refactorización que abre más problemas de los que resuelve.
A veces se trata de avanzar en pequeños movimientos seguros, casi invisibles. Otras, de aplicar métodos más estructurados para no perderte en la complejidad.
Y en ocasiones, lo más inteligente es saber poner un límite, reconocer cuándo parar para evitar el sesgo del coste hundido.
En este módulo verás:
- Por qué los tests son tu auténtica red de seguridad y cómo apoyarte en ellos para refactorizar con confianza.
- Los cinco refactors automáticos básicos que todo IDE serio ofrece y cómo usarlos con criterio.
- Cómo aprovechar los refactors contextuales del editor para transformar condicionales, bucles o módulos en alternativas más sostenibles.
- Una técnica para introducir cambios incompatibles sin romper ni el código ni los tests.
- Un método que permite descomponer grandes refactors en pasos pequeños seguros.
- Una estrategia para refactorizar código legacy sin sobrepasar el punto en el que los costes superan los beneficios.
Módulo 7: Técnicas de Refactoring Automático basadas en ROI
Refactorizar no siempre significa lanzarse a cambios profundos y arriesgados.
A menudo, lo que más valor aporta no es una gran reestructuración, sino un cambio tan sencillo como renombrar algo bien.
En este módulo veremos cómo apoyarnos en el refactoring automático para obtener el máximo retorno de inversión (ROI): pequeños pasos con un gran impacto en la claridad y mantenibilidad del código.
Se trata de dejar de ver el refactor como una “macro reforma” y empezar a tratarlo como una rutina ligera, casi como hacer la cama o recoger el escritorio.
Acciones rápidas, seguras y acumulativas que, con el tiempo, marcan la diferencia.
En este módulo verás:
- Cómo aplicar los refactors más rentables del IDE para mejorar el código en segundos y con riesgo mínimo.
- Qué atajos y automatizaciones deberías dominar para multiplicar tu productividad.
- Por qué priorizar los refactors con mayor ROI te ayuda a avanzar más rápido sin comprometer la estabilidad del sistema.
- Estrategias para incluir una rutina diaria de refactorización ligera sin frenar tu avance en nuevas funcionalidades.
- Ejemplos prácticos de cómo un simple rename, inline o extract pueden transformar la legibilidad de tu código.
- Cuándo usar (y cuándo no) abstracciones adicionales como objetos valor o parámetros explícitos para mantener la simplicidad.
- Cómo pasar de bucles y condicionales enrevesados a pipelines declarativos que reflejan la lógica de negocio con menos ruido.
Módulo 8: Refactoring Workshop
En estos últimos módulos hemos visto conceptos, técnicas y estrategias.
Ahora toca la parte divertida, ensuciarte las manos con ejercicios prácticos.
Hoy forma parte de este curso.
La dinámica es sencilla: verás el código, los tests y el problema a resolver.
Pausas el vídeo, intentas tu solución, y luego comparas con la propuesta paso a paso.
En este módulo practicarás:
- El ejercicio “trampa” que parece fácil… pero en el que hasta los desarrolladores senior tropiezan.
- Cómo aplicar Parallel Change para transformar una implementación sin romper ni los clientes ni los tests.
- Change Signature: pasar de firmas pobres en significado a contratos expresivos que comunican mejor lo que el sistema necesita.
- Encapsular lógica esparcida en tipos primitivos y llevarla a tipos de dominio que hablan el lenguaje del negocio.
- Detectar clases que cargan con demasiadas responsabilidades… y dividirlas en piezas más simples y coherentes.
- Consolidar responsabilidades sueltas y transformar un modelo anémico en uno rico en comportamiento.
- Reubicar comportamientos que están fuera de lugar… y devolverlos al módulo que les corresponde.
- Refactorizar bucles hacia pipelines declarativas (map, filter, reduce) para ganar legibilidad y expresividad.
Módulo 9: Code Smells
Malos olores del código.
Tufos.
Hediondez.
Código que huele.
Código que apesta.
Nadie sabe muy bien cómo traducir el término code smell. Pero bueno, eso no es importante. Lo que sí es importante es entender su razón de ser.
El término no es nuevo: apareció en 1999 en el libro Refactoring de Martin Fowler. En aquel capítulo, escrito junto a Kent Beck, describían un catálogo con 22 smells que señalaban posibles problemas de diseño.
El catálogo ofrece ejemplos de código potencialmente problemático, a menudo relacionado con la cohesión y el acoplamiento.
Código que muestra carencias de diseño en cuanto al mantenimiento.
La metáfora viene a decir algo así: “Vaya, hay algo en este código que me huele mal”. Y a cada olor le dan un nombre.
En este módulo aprenderás:
- Cómo detectar funciones, clases o estructuras que han crecido demasiado y se vuelven inmanejables (Bloaters).
- Cuándo la orientación a objetos está mal aplicada o usada a medias (Object-Orientation Abusers).
- Qué señales indican un acoplamiento excesivo entre módulos (Couplers).
- Por qué eliminar elementos que sobran y solo generan ruido mejora el diseño (Dispensables).
- Dónde aparecen los patrones que hacen que cualquier cambio se vuelva doloroso (Change Preventers).
- Y, lo más importante, a aplicar el refactor adecuado para cada olor y transformarlo en un diseño más testable, simple y sostenible.
Módulo 10: Testing Legacy Code
Hay una frase célebre de Michael Feathers que resume el problema en una sola línea:
“El legacy code es simplemente código sin tests”.
Porque sin tests, tu código es una caja negra. Tienes que leerlo, simularlo en tu cabeza, imaginarte escenarios y, al final, cruzar los dedos cuando lo cambias.
Es como lanzarte en paracaídas sin haber revisado si se abre, solo lo descubres cuando ya es demasiado tarde.
Por eso, antes de refactorizar necesitamos construir una red de seguridad.
Tests que nos den confianza, que nos avisen cuando rompemos algo y que nos permitan avanzar sin romper nada.
En este módulo va de eso, aquí verás:
- Los principios básicos de los tests sostenibles y por qué deben cuidarse igual que el código de producción.
- Cómo entender la pirámide de testing… y qué pasa cuando la invertimos.
- La metáfora del iceberg de Seb Rose y su utilidad para mejorar la comunicación entre negocio, testers y developers.
- Las características clave que hacen que un test sea rápido, fiable y valioso.
- Estrategias para crear una red de seguridad paso a paso incluso en sistemas sin pruebas previas.
- La técnica de seams para romper dependencias rígidas y hacer que el código sea testeable.
- Cómo usar los tests de caracterización para capturar lo que el sistema realmente hace antes de cambiarlo.
- El snapshot testing como atajo inicial para cubrir código y ganar confianza al refactorizar.
- El enfoque Approval Testing para validar la salida de sistemas completos y asegurar que los cambios no rompen el comportamiento existente.
Módulo 11: Gilded Rose Refactoring Kata
Un clásico entre clásicos. Un código heredado, lleno de condicionales, reglas cruzadas y nombres crípticos… y lo peor de todo: sin tests.
La kata Gilded Rose es un reto disfrazado de ejercicio.
Te pone delante de un sistema que parece imposible de cambiar sin que algo se rompa.
Justo la situación en la que tarde o temprano te vas a encontrar en un proyecto real.
En este módulo practicarás:
- Cómo enfrentarte a un código espagueti con reglas de negocio confusas sin fracasar en el intento.
- La técnica Golden Master para construir una red de seguridad de tests antes de tocar una sola línea.
- Cómo usar snapshot testing y la cobertura de tests para capturar el comportamiento real de un sistema legado.
- Estrategias de mutation testing para comprobar si tus tests son de verdad fiables.
- La aplicación sistemática de refactors automáticos para ir despejando complejidad paso a paso.
- El uso de lift conditional, extracción de métodos y reemplazo de bucles por construcciones más expresivas.
- La transición de condicionales caóticos a un diseño basado en polimorfismo y composición.
- Y cómo preparar el terreno para añadir nuevas funcionalidades con confianza.
Módulo 12: Refactoring a Arquitectura Hexagonal
Este módulo en sí mismo es una masterclass que podría haber vendido por separado.
Aquí descubrirás cómo aplicar refactoring no solo variables, funciones o clases, sino a toda la arquitectura de un sistema.
Porque la arquitectura no es algo fijo que se diseña al principio y se queda ahí para siempre: es un organismo vivo que evoluciona junto con el software.
Verás cómo pasar de arquitecturas en capas rígidas (que en la práctica se convierten en lasañas imposibles de mantener) a una arquitectura hexagonal flexible, con límites claros entre dominio e infraestructura.
En este módulo aprenderás:
- Qué significa realmente separar el dominio de la infraestructura.
- Cómo aplicar los principios SOLID en el diseño arquitectónico, con foco en la inversión de dependencias.
- Qué son los puertos y adaptadores y cómo usarlos para blindar la lógica de negocio.
- Cómo estructurar casos de uso para que orquesten el dominio sin contaminarse de detalles técnicos.
- Estrategias prácticas para refactorizar arquitecturas heredadas sin tener que reescribir el sistema.
- Los principales architecture smells y cómo resolverlos para ganar sostenibilidad a largo plazo.
- Cómo modelar entidades y value objects ricos en comportamiento y evitar modelos anémicos.
- Técnicas para testear el dominio y la aplicación de forma aislada, sin acoplarte a la infraestructura.
Al terminar, verás la arquitectura como una herramienta que puedes moldear a tu favor, en lugar de una jaula que limita tu código.
Módulo 13: Refactoring Frontend asistido por IA
Otro módulo que podría ser una masterclass a parte.
Aquí trabajarás con un frontend heredado donde toda la lógica de negocio está incrustada en la vista, sin separación de responsabilidades y sin una sola prueba automática que te dé confianza.
El reto es doble, aprenderás a cubrir el sistema con tests antes de tocar nada, y después a ir dividiendo un god component en piezas cohesivas, moviendo la lógica de negocio al dominio y encapsulando la infraestructura en adaptadores.
Además te mostraré cómo apoyarte en la IA para acelerar el proceso de refactorización sin perder el control del diseño.
En este módulo verás como:
- Escribir tests end-to-end con Cypress para caracterizar el comportamiento de la aplicación.
- Extraer componentes especializados para reducir la complejidad de un god component.
- Trasladar validaciones y reglas de negocio desde la vista al modelo.
- Encapsular llamadas a la API en un repositorio y cubrirlo con tests de integración.
- Organizar el frontend con un enfoque hexagonal: dominio, aplicación e infraestructura.
- Introducir casos de uso como orquestadores de la lógica de negocio.
- Aplicar refactors seguros en el frontend con el IDE y con técnicas como parallel change.
- Extraer custom hooks que separen la lógica de la presentación.
- Trabajar con estado inmutable y mejorar la consistencia de los datos.
- Usar la IA como copiloto para acelerar tareas repetitivas y mantener el foco en las decisiones de diseño.
Módulo 14: Estrategias para migrar la arquitectura legada
El código heredado merece respeto, es el que paga las facturas.
Pero también exige paciencia, lo que degeneró durante años no se arregla en unas semanas.
La clave está en migrar sin romper, construyendo alrededor del sistema heredado mientras sigues entregando valor al negocio.
En este módulo aprenderás:
- Patrones para convivir con sistemas heredados mientras sigues desarrollando nuevas funcionalidades.
- Cómo aislar deuda técnica para que no se expanda al código nuevo.
- Cuándo merece la pena refactorizar… y cuándo es más realista envolver y sustituir.
- Cómo aplicar el patrón Strangler Fig para envolver un sistema legado y dejar que el nuevo crezca a su alrededor.
- Cómo usar una capa anticorrupción (ACL) para traducir entre un modelo de datos heredado y uno moderno sin contaminar tu dominio.
- Qué rol juegan las fachadas, puertos y adaptadores en migraciones sostenibles.
- Estrategias prácticas para definir boundaries claros y decidir qué partes migrar primero.
- Cómo gestionar expectativas de negocio cuando hablamos de transformaciones a largo plazo.
Refactoring SostenibleTécnicas para mantener el Legacy Code bajo controlUna colaboración de:
