Siempre Junior. Nunca Senior.
Developers que multiplican vs los que no, gracias a combinar la IA con una habilidad muy escasa y valiosa.
Diseño SostenibleIngeniería y Artesanía del Software con TypeScriptHoy la IA ya genera la mayor parte del código que se sube a producción.
Muchos developers han dejado de escribir código para generarlo mediante prompts.
Y no sabemos cuánto tardaremos en dejar de escribir incluso esos prompts.
Tampoco sabemos si las máquinas acabarán interpretándonos sin que tengamos que pedirles nada.
Y quizás, en ese momento, ya no harán falta más desarrolladores.
El futuro es incierto, ahora más que nunca, pero aún no estamos ahí.
Lo único real es el presente, en el que sigue habiendo muchísimo trabajo para los developers con criterio.
Verás.
La generación de código que llevan a cabo herramientas como Claude Code, Codex, Cursor o Copilot son predicciones en base al código con el que han sido entrenadas.
Y la realidad es que la mayoría del código que está en Github o en cualquier otro repositorio de internet, no es código sostenible para humanos, es más bien pasto para las máquinas.
En la corta historia de la programación, son pocos los developers que se han dado cuenta de la diferencia que marca programar para las personas. Por tanto, el código que genera la máquina sigue siendo insufrible en la mayoría de los casos.
Con estas herramientas incluso hay más riesgo de crear grandes repositorios de código legacy en menos tiempo.
Ahora tenemos la capacidad de generar toneladas de código que mata la moral de cualquiera en cuestión de minutos.
Dominando esta habilidad no te faltará trabajo en los próximos años
Existe una habilidad muy muy escasa y valiosa, que solo unas pocas personas que hayamos conocido, tienen:
La habilidad de escribir código deliberadamente explícito y simple. Que refleje claramente su intención como para que cualquier persona lo entienda.
Se trata de un nivel de consciencia y sensibilidad a la hora de codificar, totalmente fuera de lo común. Verdaderos artesanos de software.
Si además añadimos la variable pragmatismo a la ecuación, el número de personas que hemos conocido se reduce a un puñado.
Conciencia, sensibilidad, pero sin fanatismo, sin dogmatismo, con el foco puesto en los objetivos del equipo. Esto es como encontrar una aguja en un pajar.
A este puñado de personas les sobra el trabajo.
Son developers que tienen montones de ofertas para elegir y por supuesto con excelentes salarios. Esta gente ha entendido que programan para las personas, no para las máquinas.
Cuando sabes programar para las personas, los agentes de IA aumentan tu potencial.
La IA es capaz de replicar tu estilo de programación, de manera que se multiplica tu productividad, sin que el código degenere. Estás tú ahí para supervisar, controlar y corregir.
Y hay algo más.
El código que mejor entendemos los humanos es también el que mejor entiende la IA.
No solo porque se entrenó con código humano. Sobre todo porque se entrenó con lenguaje natural.
La IA es un modelo de lenguaje antes que un modelo de código.
Esto ya está ampliando la brecha de valor entregado entre unos programadores y otros. Developers que multiplican vs los que no.
Si saber escribir código sostenible se valoró cada vez más en los últimos años, ahora se ha vuelto innegociable.
Diseño SostenibleIngeniería y Artesanía del Software con TypeScriptEl proyecto que costó 10 veces más (por una mala decisión de diseño)
Podría contarte muchos casos de proyectos que, con el tiempo, se volvieron inmanejables.
Pero pocos ilustran tan bien lo que pasa cuando se toman decisiones sin pensar en la sostenibilidad del código como lo que le ocurrió a Carlos Blé —mi socio en esta formación— con dos empresas del mismo sector.
Dos casos muy similares. Dos enfoques completamente distintos. Y dos resultados que no podrían haber sido más diferentes.
Una historia con final feliz.
La otra, con una factura enorme.
“Hace años trabajé ayudando a una joven empresa que estaba empezando a desarrollar su propio software de gestión del negocio.
Ya tenían un volumen de facturación considerable y era insostenible seguir trabajando solamente con hojas de cálculo y procesos manuales.
Para seguir creciendo necesitaban automatizar más.
Decidieron hacer un sistema minimalista adaptado a las necesidades del momento y totalmente a la medida, con muy poco software de terceros.
Tan solo algunas librerías y un framework conocido.
Mi trabajo consistió en enseñarles a hacer test en todas las partes del sistema y en desarrollar un frontal web (la intranet de clientes), que conectaba a su back-end.
Lo hicimos practicando Test-driven development (TDD) y la cobertura superó el 90%.
El director técnico quedó muy contento con el trabajo, el equipo (cuatro personas) acordó que escribir test era indispensable y se comprometieron a seguir haciéndolo.
Por lo que me pude marchar a otro proyecto.
Cuatro años más tarde, volvieron a llamarnos para pedir ayuda.
Habían multiplicado su facturación a lo largo de los años, con el mismo equipo.
Pero el software se les estaba quedando corto para tantas peticiones.
La escalabilidad del sistema era insuficiente para alcanzar el siguiente nivel de facturación.
Estuvimos trabajando en la optimización de algunos procesos, introduciendo cambios en el código y en la arquitectura del sistema.
Manteniendo siempre una sensación de estar en un greenfield project.
El resultado fue un éxito en tiempo y forma.
Curiosamente, a la vez que hacíamos esta mejora, nos contrató otra empresa del mismo sector, que operaba de manera muy similar.
Pero con un equipo de desarrollo de cuarenta personas (10 veces más).
Esta empresa en sus inicios decidió contratar la licencia de un software propietario genérico.
Un software que supuestamente era fácilmente adaptable a sus procesos de negocio.
Pero nada más lejos de la realidad.
Lo que nos encontramos fue un infierno.
El software era un lastre para la compañía, no les permitía avanzar al ritmo que el negocio necesitaba y por supuesto el coste era salvaje en cuanto a salarios.
Tuvieron que contratar a expertos en soporte y mantenimiento de ese software propietario, para ayudar al resto del equipo de desarrollo.
Nos llamaron para domar a la bestia que les tenía secuestrados.
Una faena que costaría varios años.
¡Qué gran diferencia comparada con la primera empresa!
Nunca antes había podido comparar dos casos tan parecidos y a la vez tan diferentes.
La diferencia en términos de costes económicos era como mínimo de diez veces y todo por un código indomable, insolente y catastrófico.”
¿Se puede reconducir un proyecto cuando ya hemos perdido el control?
La respuesta corta es sí, algo se puede hacer.
Perder el control significa no tener ni idea de lo que vamos a tardar en hacer cambios. Ni en lo que va a dejar de funcionar cuando los hagamos o tan siquiera dónde hay que aplicarlos.
Ahora bien, lo que se convirtió en un monstruo con los años, no se va a convertir en oro de la noche a la mañana, sino que también tomará años de trabajo.
Diseño SostenibleIngeniería y Artesanía del Software con TypeScript
Carlos Blé y yo llevábamos años viendo cómo se repetía el mismo patrón...
Software hecho con prisas, difícil de testear y de mantener, imposible de escalar.
Equipos atrapados en decisiones que parecían buenas… hasta que dejaban de serlo.
Equipos secuestrados por la complejidad de su propio código.
Y por eso nació esta formación.
Un curso online dividido en 16 módulos donde condensamos lo más importante que hemos aprendido diseñando software real durante más de dos décadas.
Módulo 1: Introducción & Mentalidad
Programar no es solo escribir instrucciones para una máquina.
Es escribir código para humanos.
Y lo más irónico de esto es que los LLMs detrás de Cursor o ChatGPT entienden mejor ese tipo de código que ningún otro.
Precisamente porque están diseñados para entender el lenguaje humano.
Lo que me obliga a hacerte una pregunta incómoda:
¿Estás aportando valor… o dejando deuda técnica?
En este módulo entenderás:
- Por qué escribir “código que funciona” ya no es suficiente (y hace años que dejó de serlo).
- Cómo la IA está amplificando los errores humanos más comunes a una velocidad brutal.
- Qué significa en serio programar para personas, sin caer en dogmas ni en postureo técnico.
- Por qué escribir código sostenible no es una cuestión de estilo, sino de estrategia de equipo.
- Cómo evitar que tu trabajo de hoy se convierta en el bloqueo de mañana.
- Qué distingue al programador que tiene ofertas constantes… del que simplemente sigue picando código de cualquier manera.
Módulo 2: Principios del Diseño Simple
La mayoría del código es innecesariamente complejo.
No por mala intención. Por urgencia. Por desconocimiento. Por falta de criterio.
El resultado: código que funciona, pero nadie quiere tocar.
Este módulo no te trae fórmulas mágicas.
Te da 4 principios que —cuando los aplicas en serio— transforman tu forma de diseñar software.
No para que el código sea más “clean”. Sino para que sea fácil de mantener con el paso del tiempo.
Aquí aprenderás:
- Las 4 reglas de Kent Beck que distinguen el código que mejora con el paso del tiempo del que envejece mal.
- Por qué escribir tests es condición necesaria, pero no suficiente, para tener buen diseño.
- Qué significa realmente “revelar la intención” en el código (y cómo se entrena esa habilidad).
- Cuándo abstraer y cuándo repetir: el matiz entre duplicidad de líneas y duplicidad de ideas.
- Por qué la sobreingeniería no es sofisticación sino deuda técnica anticipada.
- Cómo aplicar KISS y YAGNI sin caer en simplismos ni atajos baratos.
- Qué priorizar antes de obsesionarte con SOLID, patrones de diseño o arquitectura hexagonal.
Módulo 3: Código Sostenible
Los developers tenemos el grave problema de que le prestamos muy poca atención a los pequeños detalles.
El código no se arruina en una tarde.
Sino que lo vamos empeorando poco a poco cada día, porque ignoramos o infravaloramos que cada línea importa.
Cuando empezamos a darnos cuenta de que el código se ha vuelto inmanejable ya cuesta mucho reparar el daño.
En este módulo verás:
- Una evolución de las reglas del diseño simple que no busca hacer código más bonito, sino más resistente al paso del tiempo.
- Por qué los tests de mala calidad son casi tan inútiles como no tener ninguno.
- Cómo no engañarte pensando que cumplir requisitos significa haber hecho un buen trabajo.
- Qué tipo de abstracciones matan la expresividad y cómo sustituirlas por tipos que sí hablen el lenguaje del negocio.
- Por qué abusar de booleanos es una señal de que el modelo está mal planteado.
- Cómo evitar la trampa de crear abstracciones genéricas que nadie entiende… ni quiere mantener.
- Qué significa programar con intención explícita, y por qué es una de las habilidades más escasas entre la mayoría de los desarrolladores.
Módulo 4: Kata Bowling
Entender un concepto no es lo mismo que poder aplicarlo bajo presión.
Y en programación, solo hay una forma de llegar ahí: practicar con intención.
Las katas están para eso. Para entrenar heurísticas y afinar tu criterio.
Como en artes marciales: no practicas para que se vea bonito. Practicas para que salga cuando hace falta.
Este módulo es tu primer dojo.
En el que aprenderás:
- Qué es exactamente una kata de código y cómo sacarle el máximo partido a través de la repetición espaciada.
- Cómo crear un entorno de trabajo que favorezca el refactor constante y el aprendizaje continuo.
- Qué atajos y automatismos del IDE te ayudan a escribir mejor y más rápido.
- Cómo aplicar TDD con un enfoque práctico (no dogmático) usando el clásico de Bowling Game.
- Cómo descomponer un problema en pequeñas piezas testables.
- Qué decisiones tomar para mantener los tests simples, expresivos y sin complejidad ciclomática.
- Cómo detectar problemas de diseño antes de que se conviertan en un code smell.
- Por qué hacer refactor en paralelo es una de las técnicas más útiles… y a su vez menos conocidas por los programadores.
Módulo 5: Principio POLA
Una buena API no te sorprende.
Hace lo que esperas. Ni más. Ni menos.
Eso es lo que busca el principio de menor sorpresa (POLA):
Que el código se comporte como cualquiera esperaría.
Sin trampas. Sin efectos colaterales. Sin tener que leer cinco archivos para entender una línea.
Este principio no es estético. Es estratégico.
Porque cuando tu código sorprende… alguien paga el precio más adelante.
Antes podías pasar la patata caliente al desarrollador que viniera después.
Ahora que la IA acelera todo… el código vuelve a ti antes de que dé tiempo a que el marrón se lo coma otro.
En este módulo aprenderás:
- Qué es el principio POLA y por qué es la brújula del diseño sostenible.
- Cómo detectar y evitar los efectos colaterales que erosionan la confianza en tu código.
- Por qué priorizar funciones puras es la forma más simple de mantener el control sobre el sistema.
- Qué errores de diseño convierten una función aparentemente inocente en una caja de sorpresas.
- Por qué los comentarios nunca compensan una abstracción mal planteada.
- Cómo el uso inconsistente de tipos de retorno aumenta la complejidad accidental sin que te des cuenta.
- Qué diferencia hay entre proteger los límites del sistema… y escribir código a la defensiva.
- Cuándo tiene sentido usar monkey patching o métodos de extensión y cuándo son una trampa disfrazada de atajo.
Módulo 6: Naming y Contexto
“El código tiene que ser simple y directo. Debería leerse con la misma facilidad que un texto bien escrito” — Grady Booch.
Pero sin buenos nombres, esa idea de Grady es simplemente inalcanzable.
Y lo peor no es eso.
Lo peor es que elegir nombres sigue siendo una de las habilidades más infravaloradas en el mundo del desarrollo.
Y sin embargo pocas cosas tienen un impacto tan grande en la calidad del código.
Cuando programas, cada palabra que eliges para nombrar una función, una clase o una variable… es un concepto que introduces en la cabeza de quien te lee (que casi siempre eres tú mismo dentro de seis meses).
No tienes poder sobre las palabras reservadas del lenguaje.
Ni sobre los símbolos.
Pero sí sobre los nombres que eliges.
Y esos nombres son abstracciones.
Igual que la palabra “interruptor” no es un interruptor, sino una imagen mental que aparece en tu cabeza con una pieza de plástico, una pared blanca y el clic que enciende la luz…
Un nombre en tu código activa un modelo mental. Bueno o malo.
De ahí que nombrar no sea un detalle técnico sino un gesto de diseño.
Y por eso es tan difícil.
De ahí esa frase tan repetida: “Solo hay dos problemas difíciles en programación, la invalidación de la caché y nombrar cosas”.
Este módulo va de lo segundo.
Aquí aprenderás:
- El arte de escribir buenos nombres que reflejen el dominio del negocio y comuniquen claramente la intención del código.
- Por qué nombrar no es una tarea de juniors… sino una de las decisiones de diseño más condicionan la evolución del sistema.
- Qué errores sutiles (como usar alias, prefijos técnicos o nombres genéricos) hacen que tu código suene bien pero realmente no exprese nada.
- Cómo elegir nombres que fluyan como una frase natural, sin fricciones innecesarias.
- Por qué el contexto es tu mejor aliado para escribir código autoexplicativo sin necesidad de ser verboso.
- Qué nombres matan la expresividad sin que nadie los cuestione (porque “siempre se ha hecho así”).
- Cómo detectar si un nombre está ocultando un mal diseño (y qué hacer al respecto).
- Cuándo conviene nombrar… y cuándo es mejor dejarlo en una línea sin variables intermedias.
- Por qué los nombres son una herramienta de comunicación más potente que cualquier comentario.
Módulo 7: Kata Game of Life
Hay ejercicios que no solo sirven para practicar sino que ayudan a desarrollar el pensamiento computacional.
Game of Life, del gran matemático John Conway, es uno de ellos.
Esta es mi kata preferida, no solo por lo que enseña… sino por todo lo que revela.
A simple vista parece un juego matemático trivial. Pero en realidad, es una excusa perfecta para poner a prueba tu criterio de diseño.
Porque aquí no hay un framework que te diga qué hacer.
Ni una arquitectura que seguir.
No hay clases heredadas. Ni convenciones impuestas. Solo un conjunto de reglas simples… y las decisiones que tomas al implementarlas.
En este módulo aprenderás:
- Cómo modelar la lógica de negocio un sistema sin acoplarla a los detalles de implementación.
- Qué pequeñas decisiones técnicas terminan condicionando todo lo que viene después.
- Por qué un sistema simple puede sacar a la luz todos tus vicios como developer.
- Cómo modelar lógica de negocio expresiva sin caer en la sobreingeniería.
- Qué señales indican que necesitas una abstracción… y cuándo estás introduciendo una innecesaria.
- Cómo usar el refactor automático para reescribir sin romper lo que ya funciona.
- Por qué la forma en que escribes los tests revela cómo entiendes el problema (y el modelo).
- Cómo practicar TDD de forma realista con un ejercicio que te obliga a pensar antes de programar.
Módulo 8: Formato y comentarios
“El buen código siempre parece estar escrito por alguien a quien le importa”. – Michael Feathers
Y eso se nota en los pequeños detalles:
Indentación consistente, uso apropiado del espacio vertical, coherencia visual, simetría… Pequeñas decisiones que ayudan a que el código se entienda mejor.
No se trata de gustos personales. Ni de modas.
Se trata de comunicar mejor.
¿Te imaginas un libro mal indentado, con espacios arbitrarios y comentarios al margen explicando lo que el autor no supo decir bien?
Y sin embargo, eso es lo que hacemos todo el tiempo en nuestro código.
Este módulo va de pulir esos pequeños detalles.
Aquí aprenderás:
- Por qué el formato no es solo una cuestión estética… sino una decisión de diseño.
- Qué reglas mínimas de estilo evitan malentendidos sin caer en debates inútiles.
- Cómo detectar código que pide una abstracción solo por la forma en que está estructurado.
- Qué señales indican que necesitas una función… y no otra línea en blanco.
- Por qué abusar de líneas vacías suele ser un síntoma de responsabilidades mezcladas.
- Qué tipo de comentarios envejecen mal y acaban confundiendo más que ayudando.
- Cómo decidir qué comentar (y qué debería decir el código por sí solo).
- Por qué los comentarios útiles no explican “qué hace” el código, sino “por qué” lo hace.
- Qué deberías documentar en una API pública… y qué puedes dejar fuera si eliges bien los nombres.
Módulo 9: Diseño de Funciones
“Sabemos que estamos desarrollando buen código cuando cada función hace exactamente lo que su nombre indica”. – Ward Cunningham
Hay dos tipos de funciones: las que te hacen dudar cada vez que las miras… y las que entiendes al vuelo.
La diferencia no está en el lenguaje.
Está en cómo están planteadas.
Una función mal diseñada no solo complica el código. Rompe el flujo mental, te obliga a poner comentarios innecesarios y a revisar cosas que deberían ser obvias.
Hace que todo lo que construyas encima sea más difícil de mantener.
Porque una función no es solo una secuencia de instrucciones. Es una decisión de diseño. Y, en muchos casos, el lugar donde empieza la simplicidad… o donde nace la deuda técnica.
En este módulo verás:
- Que significa diseñar funciones cohesivas y con una responsabilidad bien definida. Pero no como muchos aplican “Clean Code”... esto no va de escribir funciones de una sola línea.
- Cómo evitar la trampa de la sobreingeniería: encontrar el equilibrio entre optimización y legibilidad.
- Por qué reducir la aridad es una de las formas más efectivas de reducir complejidad accidental.
- Qué problemas introduce usar parámetros booleanos y cómo reemplazarlos por funciones explícitas.
- Cómo simplificar condiciones complejas con nombres expresivos y lógica más legible.
- Cuándo usar cláusulas guarda para salir antes de una función y por qué no son lo mismo que un early return.
- Por qué separar control de flujo y lógica de negocio hace tu código más robusto y sostenible.
- Qué beneficios aporta escribir en estilo declarativo… y cuándo compensa volver a lo imperativo.
- Por qué las funciones puras son tan potentes para reducir errores y limitar el acoplamiento.
- Cómo aplicar el principio CQS, qué problema resuelve… y en qué se relaciona (y se diferencia) de CQRS.
- Qué relación hay entre legibilidad, rendimiento y complejidad algorítmica… y cómo decidir qué sacrificar según el contexto.
Módulo 10: Kata Template Engine
La kata del motor de plantillas es un clásico.
Una función que reemplaza variables en un texto. Sencillo… al menos en apariencia.
Pero cuando lo implementas desde cero, empiezan a salir a la luz todas esas decisiones de diseño que normalmente ignoras.
¿Cómo decides qué hacer cuando falta algún campo?
¿Cómo notificas los errores sin llenar el código de excepciones?
¿Cómo evitas que tu API se convierta en un obstáculo para el cliente que la consume?
Además de las respuestas a esas preguntas, en este módulo pondrás en práctica:
- Cómo pasar de un algoritmo trivial a una solución reutilizable, extensible y fácil de testear.
- Qué señales indican que una función necesita convertirse en clase para mejorar su cohesión.
- Cómo saber que tu función está haciendo demasiado… y cómo dividirla sin romper el diseño.
- Por qué lanzar errores no siempre es la mejor forma de proteger tu código (y qué hacer en su lugar).
- Cuándo merece la pena abstraer tipos de dominio en lugar de seguir usando strings o booleanos.
- Qué patrones permiten manejar los casos edge sin ensuciar la lógica principal.
- Cómo encapsular errores sin depender de excepciones (y cuándo eso te da más control).
- Qué técnicas te permiten detectar fallos sin interrumpir el flujo… ni esconder el problema.
- Por qué refactorizar transforma no solo la implementación, sino tu comprensión del dominio.
Módulo 11: Diseño de Clases y Módulos
“La programación orientada a objetos hace el código comprensible encapsulando las partes móviles. La programación funcional lo hace minimizándolas.” – Michael Feathers
La programación orientada a objetos está muerta.
O eso dicen cada dos por tres en Twitter.
Y, sin embargo, ahí sigue. Resolviendo problemas como cualquier otro paradigma.
El problema no es usar clases. Es no saber cómo diseñarlas.
Te lo dice un fan de la programación funcional.
Y es que saber diseñar buenas clases no es solo útil cuando haces POO.
Es útil cuando diseñas módulos, closures y hasta custom hooks de React…
Porque en el fondo, todo diseño modular se apoya en los mismos principios: encapsular lo que cambia, exponer lo esencial y reducir las dependencias innecesarias.
Aprender a diseñar buenas clases te obliga a pensar en términos de responsabilidad, cohesión y acoplamiento.
Y eso no cambia aunque programes en TypeScript, en Haskell o en Java.
En este módulo verás:
- Por qué el debate no es “clases sí o clases no”, sino “clases cómo”.
- Cómo reducir el ámbito de variables y métodos para ganar cohesión y evitar acoplamientos innecesarios.
- Qué errores evitar al escribir constructores… y por qué es interesante delegar la lógica de creación en métodos factoría.
- Cómo organizar las clases y los módulos para que el diseño hable por sí solo, sin necesidad de comentarios.
- Qué modificadores de acceso usar (y cuándo), para que tu API pública no se convierta en una invitación a romper el encapsulamiento.
- Por qué los modelos anémicos complican tu dominio, y te obligan a repartir la lógica en servicios que acaban haciendo de todo.
- Cómo aplicar “Tell, don’t ask” y la Ley de Demeter para reducir el acoplamiento sin perder expresividad.
- Cuándo conviene heredar… y cuándo la herencia solo añade rigidez en el diseño.
- Por qué priorizar la composición frente a la herencia (y cómo hacerlo sin complicarte).
- Cuándo usar value objects… y cuándo necesitas entidades con identidad propia.
- Cómo diseñar tipos de dominio ricos en comportamiento que encapsulan reglas, validaciones y decisiones.
Módulo 12: Kata Mars Rover
Hay ejercicios que no se diseñaron para enseñarte un concepto.
Están pensados para enfrentarte a tu forma de programar.
Este es uno de ellos.
Uno de mis favoritos, de hecho (después de Game of Life).
No solo porque parece fácil y no lo es.
Sino porque expone tu manera de pensar sin que puedas esconderte detrás de frameworks y librerías.
La kata Mars Rover se usaba a menudo como prueba técnica en entrevistas de Google.
Y no por casualidad.
Sino porque revela cosas que otros ejercicios no muestran:
Qué responsabilidades asignas, cómo separas el comportamiento del estado, hasta dónde llega tu obsesión por los detalles…
En este módulo pondrás en práctica:
- Cómo diseñar desde el dominio en vez de desde los tipos primitivos (y por qué eso cambia todo).
- Qué señales indican que una clase debería ser un value object… y cómo encapsular la lógica sin romper la simplicidad.
- Por qué abusar de condicionales revela falta de diseño… y cómo evitarlos con polimorfismo sin caer en el sobrediseño.
- Cómo usar el patrón State para representar comportamientos que cambian sin aumentar la complejidad accidental.
- Qué decisiones tomar para que tus tests expresen reglas de negocio y no solo validen resultados.
- Cómo diseñar APIs públicas que anticipen errores sin obligar al cliente a gestionar excepciones.
- Cuándo aplicar el patrón Comando para ejecutar acciones dinámicamente… sin llenar el código de if-else, switch-cases ni magic strings.
- Cómo usar TDD para que el diseño emerja, en lugar de imponerlo desde el principio.
- Por qué los tests no son solo una red de seguridad, sino una brújula de diseño.
Módulo 13: Principios de Diseño Avanzado
Todo el mundo habla de SOLID.
Pero pocos lo entienden.
Y aún menos lo aplican bien.
Porque no se trata de recordar cinco siglas.
Se trata de tomar mejores decisiones de diseño para maximizar la cohesión y minimizar el acoplamiento.
Este módulo no pretende convencerte de que sigas principios por fe.
Porque los principios de diseño no son dogmas.
Son herramientas.
Y como toda herramienta, pueden ayudarte o estorbarte, según cómo y cuándo las uses.
En este módulo aprenderás:
- Qué significa realmente diseñar con alta cohesión… y cómo detectarla más allá de definiciones vagas.
- Por qué el acoplamiento no es malo per sé, pero sí lo es cuando aparece donde no toca (y cómo reducir su impacto).
- Cómo usar la estrategia “connascence” para medir acoplamientos ocultos que los compiladores y linters no detectan.
- Por qué dividir una responsabilidad no siempre mejora el diseño (y cuándo sí lo hace).
- Cómo escribir funciones privadas tan puras que podrían vivir solas en otro módulo.
- Cómo evitar diseños con acoplamientos “románticos”: dos clases o módulos que no pueden vivir el uno sin el otro.
- Cuándo conviene dejar tu código abierto a extensión… y cuándo lo único que haces es complicarte por anticipado.
- Cómo aplicar el patrón estrategia, el decorador o la composición… sin que parezca que estás programando para impresionar en una charla de Meetup.
- Cómo distinguir herencia útil de herencia tóxica, con ejemplos reales que violan (y salvan) el principio de Liskov.
- Cuándo vale la pena extraer una interfaz… y cuándo es solo burocracia innecesaria.
- Cómo aplicar el principio de inversión de dependencias sin necesidad de un framework y por qué casi siempre usar un IoC container suele ser mala idea.
Módulo 14: Kata Markdown Transformer
Este ejercicio surgió resolviendo un problema real en Savvily, la editorial de Carlos Blé.
Mientras preparaban libros en markdown, se dieron cuenta de algo obvio pero fácil de pasar por alto: los enlaces no sirven en papel.
Un link funciona en un PDF o en un ePub. Pero en un libro impreso es invisible.
La solución fue convertir los enlaces en notas al pie. Y esa transformación, que parecía trivial, resultó ser un reto de diseño más interesante de lo esperado.
En este módulo verás:
- Cómo resolver un problema real aplicando TDD, paso a paso, y sin seguir un guión prefabricado.
- Por qué los casos edge no se parchean sino que se tienen en cuenta desde el principio.
- Cómo encapsular la lógica de negocio sin romper la cohesión ni abrir métodos solo “porque el test lo necesita”.
- Por qué refactorizar no es solo reordenar código, sino entender mejor el problema que estás resolviendo.
- Cuándo eliminar tests auxiliares… y por qué hacerlo es una señal de un buen diseño.
- Qué beneficios aporta modelar tus propios tipos incluso en problemas aparentemente sencillos.
- Cómo evitar que el código se convierta en un infierno de condiciones y mutaciones.
- Por qué maximizar la cohesión, definir bien las responsabilidades y mantener el acoplamiento al mínimo es lo que evita que un diseño simple se convierta en un problema complejo.
Módulo 15: Gestión y Prevención de Errores
“Si depurar código es el proceso de eliminar los errores de software, entonces programar debe ser el proceso de introducirlos” — Edsger Dijkstra
A estas alturas ya no hace falta decirlo, pero lo diré igual: programar sin errores es imposible.
Ni los tests automáticos, ni el coverage, ni el compilador, ni los linters, ni las buenas intenciones bastan.
La única defensa real es escribir código que reduzca al mínimo el riesgo de accidente.
Este módulo no va solo de dónde y cómo gestionar los errores.
Va de entender dónde se rompen las cosas, por qué, y qué decisiones de diseño las están provocando.
Aquí aprenderás a identificar los tramos de código donde los errores no son una posibilidad, sino una certeza. Y qué hacer para anticiparte a ellos.
Verás también:
- Por qué entender cómo se evalúan las expresiones y cómo funciona tu lenguaje evita errores que no se ven ni en test.
- Qué implicaciones reales tiene trabajar con valores, referencias y objetos… y por qué muchos bugs surgen al no entender esta diferencia.
- Cuáles son los tramos de código donde más fallos se concentran y qué patrones de diseño ayudan a mitigarlos.
- Cuándo y cómo lanzar excepciones… y cuándo es mejor no hacerlo.
- Cómo funciona el patrón notificación y por qué puede hacer tu código más robusto en ciertos casos.
- Por qué entender cómo se ejecutan las operaciones asincrónicas puede ahorrarte bugs imposibles de depurar.
- Qué errores cometen incluso los desarrolladores senior al capturar (o silenciar) excepciones.
Módulo 16: Kata Final – Backend con DDD y Arquitectura Hexagonal
Llega el momento de cerrar el círculo.
Este módulo no va de aprender algo nuevo.
Va de poner en práctica lo que ya sabes.
La idea no es escribir un backend perfecto, ni aplicar todos los patrones posibles.
Es resolver un caso realista con sentido común, cuidando el diseño desde el principio.
La idea es que compares tu solución con la nuestra, sin buscar la “respuesta correcta”, sino entendiendo las decisiones detrás del diseño.
Aquí pondrás en práctica:
- Cómo implementar un backend de registro de usuarios con principios de Domain Driven Design (sin caer en ceremonias innecesarias).
- Por qué usar la Arquitectura hexagonal para aislar el dominio de las dependencias externas.
- Cuándo y dónde gestionar los errores… y por qué hacerlo demasiado pronto (o demasiado tarde) puede comprometer tu diseño.
- Cómo crear tipos específicos de dominio que encapsulan las reglas de negocio… sin perder de vista la simplicidad.
- Qué papel juega el patrón repositorio en un diseño orientado al dominio… y en qué se diferencia de un simple DAO.
- Por qué el orden en que escribes el código condiciona el tipo de acoplamiento que vas a sufrir después.
- Qué cubren los tests de integración que los unitarios no pueden… y cómo combinarlos junto a las pruebas e2e para tener confianza real en el sistema.
Diseño SostenibleIngeniería y Artesanía del Software con TypeScriptUna colaboración de:
