Dijkstra y la programación estructurada: disciplina que escala

Por qué Dijkstra sigue importando cuando el software crece

El software rara vez falla porque no pueda escribirse. Falla porque, un año después, nadie puede cambiarlo de forma segura.

A medida que las bases de código crecen, cada ajuste “pequeño” empieza a ramificarse: una corrección rompe una funcionalidad lejana, un nuevo requisito fuerza reescrituras, y un simple refactor se convierte en una semana de coordinación cuidadosa. La parte difícil no es añadir código: es mantener el comportamiento predecible mientras todo lo demás cambia.

La promesa: corrección y simplicidad reducen el coste a largo plazo

Edsger Dijkstra defendía que la corrección y la simplicidad deberían ser objetivos de primera clase, no lujos. La ganancia no es académica. Cuando un sistema es más fácil de razonar, los equipos pasan menos tiempo apagando incendios y más tiempo construyendo.

• La corrección reduce el coste de los errores: menos incidentes, menos regresiones, menos código “no tocar”.
• La simplicidad reduce el coste del cambio: menos supuestos ocultos, menos casos especiales, menos sorpresas en las revisiones.

Qué significa realmente “escala”

Cuando la gente dice que el software debe “escalar”, a menudo se refieren al rendimiento. El punto de Dijkstra es distinto: la complejidad también escala.

La escala aparece como:

• Más funcionalidades: nuevos flujos, casos límite y expectativas de usuarios.
• Más personas: traspasos, estilos distintos y contextos variables.
• Más integraciones: APIs externas, fuentes de datos y modos de fallo.
• Más tiempo: decisiones heredadas, requisitos cambiantes y reescrituras parciales.

La idea central: la estructura facilita predecir el comportamiento

La programación estructurada no se trata de ser estricto por sí misma. Se trata de elegir el flujo de control y la descomposición que faciliten responder dos preguntas:

• “¿Qué sucede después?”
• “¿Bajo qué condiciones?”

Cuando el comportamiento es predecible, cambiar deja de ser arriesgado y pasa a ser rutinario. Por eso Dijkstra sigue siendo relevante: su disciplina apunta al verdadero cuello de botella del software en crecimiento: entenderlo lo suficiente como para mejorarlo.

Una breve introducción a Edsger Dijkstra y su objetivo

Edsger W. Dijkstra (1930–2002) fue un científico de la computación neerlandés que ayudó a moldear cómo los programadores piensan sobre construir software fiable. Trabajó en sistemas operativos tempranos, contribuyó a algoritmos (incluido el algoritmo de ruta más corta que lleva su nombre) y—lo más importante para los desarrolladores cotidianos—promovió la idea de que programar debería ser algo sobre lo que podamos razonar, no solo algo que intentemos hasta que parece funcionar.

Su foco central: razonar por encima de “funciona en mi máquina”

A Dijkstra le importaba menos si un programa podía producir la salida correcta para algunos ejemplos y más si podíamos explicar por qué es correcto para los casos que importan.

Si puedes enunciar lo que una porción de código debe hacer, deberías poder argumentar (paso a paso) que realmente lo hace. Esa mentalidad conduce de forma natural a código más fácil de seguir, revisar y menos dependiente de depuraciones heroicas.

Por qué puede sonar estricto—y por qué eso ayuda

Algunos de los escritos de Dijkstra suenan implacables. Criticaba los trucos “ingeniosos”, los flujos de control descuidados y las costumbres de codificación que dificultan el razonamiento. La rigidez no busca imponer estilo; busca reducir la ambigüedad. Cuando el significado del código es claro, se pierde menos tiempo debatiendo intenciones y se gana tiempo validando comportamientos.

Qué significa “programación estructurada” (a alto nivel)

La programación estructurada es la práctica de construir programas a partir de un pequeño conjunto de estructuras de control claras—secuencia, selección (if/else) y iteración (bucles)—en vez de saltos enmarañados en el flujo. La meta es simple: hacer que el camino a través del programa sea comprensible para que puedas explicarlo, mantenerlo y cambiarlo con confianza.

Corrección: la característica oculta de la que dependen tus usuarios

La gente suele describir la calidad del software como “rápido”, “bonito” o “rico en funcionalidades”. Los usuarios experimentan la corrección de otra forma: como la confianza tranquila de que la app no les sorprenderá. Cuando la corrección está presente, nadie la nota. Cuando falta, todo lo demás deja de importar.

“Funciona ahora” vs “sigue funcionando”

“Funciona ahora” suele significar que probaste algunos caminos y obtuviste el resultado esperado. “Sigue funcionando” significa que se comporta como se pretende a lo largo del tiempo, ante casos límite y cambios—después de refactors, nuevas integraciones, mayor tráfico y nuevos miembros del equipo que tocan el código.

Una funcionalidad puede “funcionar ahora” y aun así ser frágil:

• Depende de que la entrada esté siempre limpia.
• Asume que una llamada de red siempre responde rápido.
• Pasa pruebas que solo cubren la ruta feliz.

La corrección trata de eliminar esos supuestos ocultos—o hacerlos explícitos.

Cómo los pequeños bugs se multiplican en sistemas grandes

Un bug menor rara vez se mantiene menor cuando el software crece. Un estado incorrecto, un límite off-by-one o una regla de manejo de errores poco clara se copia en nuevos módulos, se envuelve por otros servicios, se cachea, se reintenta o se “parchea”. Con el tiempo, los equipos dejan de preguntar “¿qué es verdadero?” y empiezan a preguntar “¿qué suele pasar?” Ahí es cuando la respuesta a incidentes se convierte en arqueología.

El multiplicador es la dependencia: un pequeño mal comportamiento se convierte en muchos comportamientos descendentes, cada uno con su parche parcial.

La claridad es una herramienta de corrección (no solo una elección de estilo)

El código claro mejora la corrección porque mejora la comunicación:

• Las revisiones de código detectan problemas reales cuando la intención es obvia.
• La incorporación es más rápida cuando las reglas son legibles y no conocimiento tribal.
• Los incidentes se resuelven antes cuando el flujo de control y los modos de fallo son fáciles de rastrear.

Una definición práctica de corrección para equipos de producto

La corrección significa: para las entradas y situaciones que decimos soportar, el sistema produce consistentemente los resultados que prometemos—y falla de formas previsibles y explicables cuando no puede.

La simplicidad como estrategia, no como preferencia de estilo

La simplicidad no busca que el código sea “bonito”, minimalista o ingenioso. Busca que el comportamiento sea fácil de predecir, explicar y modificar sin miedo. Dijkstra valoró la simplicidad porque mejora nuestra capacidad para razonar sobre programas—especialmente cuando la base de código y el equipo crecen.

Qué es simplicidad (y qué no es)

El código simple mantiene un número reducido de ideas en movimiento a la vez: flujo de datos claro, flujo de control claro y responsabilidades definidas. No obliga al lector a simular muchas rutas alternas en la cabeza.

La simplicidad no es:

• Menos líneas a cualquier costo
• Trucos “inteligentes”, one-liners densos o abstracciones pesadas
• Evitar estructura para parecer flexible

Complejidad accidental: lo que no querías añadir

Muchos sistemas se vuelven difíciles de cambiar no porque el dominio sea inherentemente complejo, sino porque introducimos complejidad accidental: flags que interactúan de formas inesperadas, parches de casos especiales que nunca se eliminan y capas que existen mayormente para sortear decisiones anteriores.

Cada excepción extra es un impuesto sobre la comprensión. El coste aparece más tarde, cuando alguien intenta arreglar un bug y descubre que un cambio en un área rompe sutilmente varias otras.

Los diseños simples reducen la necesidad de heroísmos

Cuando un diseño es simple, el progreso viene del trabajo constante: cambios revisables, diffs más pequeños y menos arreglos de emergencia. Los equipos no necesitan desarrolladores “héroe” que recuerden cada caso límite histórico o que deban depurar a las 2 a.m. bajo presión. En su lugar, el sistema soporta la atención humana normal.

Regla práctica: menos casos especiales, menos sorpresas

Una prueba práctica: si sigues añadiendo excepciones (“a menos que…”, “excepto cuando…”, “solo para este cliente…”), probablemente estás acumulando complejidad accidental. Prefiere soluciones que reduzcan el branching en el comportamiento—una regla consistente suele vencer a cinco casos especiales, incluso si la regla consistente es algo más general de lo que imaginabas al principio.

Programación estructurada: flujo de control claro en el que puedes confiar

La programación estructurada es una idea simple con grandes consecuencias: escribe código de modo que su ruta de ejecución sea fácil de seguir. En términos sencillos, la mayoría de programas se puede construir con tres bloques—secuencia, selección y repetición—sin depender de saltos enmarañados.

Los tres bloques (en términos humanos)

• Secuencia: haz el paso A, luego el paso B, luego el paso C.
• Selección: elige una ruta según una condición (p. ej., if/else, switch).
• Repetición: repite un conjunto de pasos mientras se cumple una condición (p. ej., for, while).

Cuando el flujo de control se compone con estas estructuras, normalmente puedes explicar lo que hace el programa leyéndolo de arriba a abajo, sin “teletransportarte” por el archivo.

Lo que reemplazó: caminos de ejecución tipo espagueti

Antes de que la programación estructurada se convirtiera en norma, muchas bases de código dependían fuertemente de saltos arbitrarios (control al estilo goto). El problema no es que los saltos sean siempre malos; es que los saltos sin restricciones crean rutas de ejecución difíciles de predecir. Terminas preguntando “¿Cómo llegamos aquí?” y “¿En qué estado está esta variable?”—y el código no responde claramente.

Por qué la claridad importa para equipos reales

El flujo de control claro ayuda a los humanos a construir un modelo mental correcto. Ese modelo es en lo que confías cuando depuras, revisas un pull request o cambias comportamiento bajo presión de tiempo.

Cuando la estructura es consistente, la modificación se vuelve más segura: puedes cambiar una rama sin afectar accidentalmente otra, o refactorizar un bucle sin perder una salida oculta. La legibilidad no es solo estética: es la base para cambiar comportamiento con confianza sin romper lo que ya funciona.

Herramientas de razonamiento: invariantes, precondiciones y postcondiciones

Dijkstra impulsó una idea simple: si puedes explicar por qué tu código es correcto, puedes cambiarlo con menos miedo. Tres pequeñas herramientas de razonamiento hacen eso práctico—sin convertir a tu equipo en matemáticos.

Invariantes: “hechos que permanecen verdaderos”

Un invariante es un hecho que permanece cierto mientras un fragmento de código se ejecuta, especialmente dentro de un bucle.

Ejemplo: sumas precios en un carrito. Un invariante útil es: “total equals the sum of all items processed so far.” Si eso se mantiene en cada paso, al finalizar el bucle el resultado es confiable.

Los invariantes son poderosos porque enfocan la atención en lo que nunca debe romperse, no solo en lo que debe pasar a continuación.

Precondiciones y postcondiciones: contratos cotidianos

Una precondición es lo que debe ser cierto antes de que una función se ejecute. Una postcondición es lo que la función garantiza después de terminar.

Ejemplos cotidianos:

• Precondición: “Solo puedes retirar dinero si tu cuenta tiene fondos suficientes.”
• Postcondición: “Después de retirar, el saldo se reduce exactamente en esa cantidad y nunca se vuelve negativo.”

En código, una precondición podría ser “la lista de entrada está ordenada” y la postcondición “la lista de salida está ordenada y contiene los mismos elementos más el insertado”.

Cómo escribirlos cambia la codificación y las revisiones

Cuando los escribes (aunque sea informalmente), el diseño se afina: decides qué espera y qué promete la función, y naturalmente la haces más pequeña y enfocada.

En las revisiones, desplaza el debate lejos del estilo (“lo escribiría distinto”) hacia la corrección (“¿mantiene este invariante?” “¿Imponemos la precondición o la documentamos?”).

Práctica ligera: comenta donde se acumulan bugs

No necesitas pruebas formales para beneficiarte. Elige el bucle más propenso a bugs o la actualización de estado más compleja y añade un comentario de una línea con un invariante sobre él. Cuando alguien edite después, ese comentario actúa como barandilla: si un cambio rompe ese hecho, el código ya no es seguro.

Pruebas vs razonamiento: qué puede (y no puede) garantizar cada uno

Pruebas y razonamiento buscan el mismo resultado—software que se comporte como se pretende—pero operan de formas muy distintas. Las pruebas descubren problemas intentando ejemplos. El razonamiento previene categorías enteras de problemas haciendo la lógica explícita y comprobable.

Para qué son geniales las pruebas

Las pruebas son una red de seguridad práctica. Detectan regresiones, verifican escenarios reales y documentan el comportamiento esperado de forma ejecutable por todo el equipo.

Pero las pruebas solo pueden mostrar la presencia de bugs, no su ausencia. Ninguna suite de pruebas cubre cada entrada, cada variación temporal o cada interacción entre características. Muchos fallos “funciona en mi máquina” vienen de combinaciones no probadas: una entrada rara, un orden específico de operaciones o un estado sutil que aparece después de varios pasos.

Qué puede garantizar el razonamiento (y qué no)

El razonamiento trata de probar propiedades del código: “este bucle siempre termina”, “esta variable nunca es negativa”, “esta función nunca devuelve un objeto inválido”. Bien hecho, descarta clases enteras de defectos—especialmente en fronteras y casos límite.

La limitación es el esfuerzo y el alcance. Pruebas formales completas para un producto entero rara vez son económicas. El razonamiento funciona mejor aplicado selectivamente: algoritmos centrales, flujos sensibles a seguridad, lógica de pago y concurrencia.

Un enfoque equilibrado que escala

Usa pruebas ampliamente y aplica razonamiento profundo donde fallar es caro.

Un puente práctico entre ambos es hacer ejecutable la intención:

• Aserciones para supuestos internos (p. ej., “index is in range”).
• Precondiciones y postcondiciones (contratos) para entradas/salidas de funciones.
• Invariantes para verdades persistentes (p. ej., “cart total equals sum of items”).

Estas técnicas no reemplazan pruebas: tensan la red. Convierten expectativas vagas en reglas comprobables, haciendo más difícil escribir bugs y más fácil diagnosticarlos.

Disciplina: cómo los equipos evitan la “deuda por astucia”

El código “ingenioso” suele sentirse como una victoria momentánea: menos líneas, un truco elegante, un one-liner que te hace sentir inteligente. El problema es que la astucia no escala en el tiempo ni entre personas. Seis meses después, el autor olvida el truco. Un compañero nuevo lo lee literalmente, ignora un supuesto oculto y lo cambia de manera que rompe el comportamiento. Eso es “deuda por astucia”: velocidad a corto plazo comprada con confusión a largo plazo.

La disciplina es un acelerador de equipo

El punto de Dijkstra no era “escribe código aburrido” por preferencia de estilo: era que las restricciones disciplinadas hacen que los programas sean más fáciles de razonar. En un equipo, las restricciones también reducen la fatiga de decisión. Si todos ya conocen los valores por defecto (cómo nombrar, cómo estructurar funciones, qué significa “hecho”), dejas de reabrir lo básico en cada pull request. Ese tiempo vuelve al trabajo de producto.

La disciplina aparece en prácticas rutinarias:

• Revisiones de código que valoran la claridad sobre la novedad (“¿Alguien más podría cambiar esto con seguridad?”).
• Estándares compartidos (formatos, nombres, manejo de errores) para que la base de código suene con una sola voz.
• Refactorización como mantenimiento, no misión de rescate: pequeñas limpiezas continuas.

Cómo se ve “disciplinado” en el código

Algunos hábitos concretos previenen que la deuda por astucia se acumule:

• Funciones pequeñas que hacen un trabajo, con entradas y salidas claras.
• Nombres claros que explican la intención (prefiere calculate_total() sobre do_it()).
• Sin estado oculto: minimiza globales y efectos sorpresa; pasa dependencias explícitamente.
• Flujo de control recto: evita lógicas que dependan de orden sutil, valores mágicos o “funciona si conoces el truco”.

La disciplina no busca la perfección: busca hacer predecible el siguiente cambio.

Modularidad y fronteras: mantener el cambio local

La modularidad no es solo “dividir código en archivos”. Es aislar decisiones detrás de fronteras claras para que el resto del sistema no necesite saber (o preocuparse por) los detalles internos. Un módulo oculta las partes enmarañadas—estructuras de datos, casos límite, trucos de rendimiento—y expone una superficie pequeña y estable.

Cómo los módulos reducen el radio de explosión

Cuando llega una petición de cambio, el resultado ideal es: un módulo cambia y todo lo demás queda intacto. Ese es el significado práctico de “mantener el cambio local”. Las fronteras previenen el acoplamiento accidental—donde actualizar una característica rompe tres otras porque compartían supuestos.

Una buena frontera también facilita el razonamiento. Si puedes enunciar lo que un módulo garantiza, puedes razonar sobre el programa mayor sin releer toda su implementación cada vez.

Las interfaces como promesas (y cómo permiten trabajo paralelo)

Una interfaz es una promesa: “Dado esto input, devolveré este output y mantendré estas reglas.” Cuando la promesa es clara, los equipos pueden trabajar en paralelo:

• Una persona implementa el módulo.
• Otra construye un llamador que usa la interfaz.
• QA diseña pruebas alrededor del comportamiento prometido.

No se trata de burocracia: se trata de crear puntos de coordinación seguros en una base de código que crece.

Chequeos simples de módulo que previenen la deriva

No necesitas una gran revisión de arquitectura para mejorar la modularidad. Prueba estas comprobaciones ligeras:

• Entradas/salidas: ¿puedes listar los inputs, outputs y efectos secundarios en pocas líneas? Si no, probablemente hace demasiado.
• Propiedad: ¿quién es responsable de su comportamiento y cambios? Los módulos sin dueño se convierten en vertederos.
• Dependencias: ¿depende de “todo” o solo de lo que realmente necesita? Menos dependencias significan menos roturas sorpresa.

Fronteras bien dibujadas convierten “cambio” de un evento del sistema en una edición localizada.

Por qué estas ideas triunfan a escala (equipos, bases de código y tiempo)

Cuando el software es pequeño, puedes “tenerlo todo en la cabeza”. A escala, eso deja de ser cierto—y los modos de fallo se vuelven familiares.

Síntomas comunes:

• Caídas que se rastrean a un caso límite sorprendente
• Lanzamientos que se ralentizan porque cada cambio parece riesgoso
• Integraciones frágiles donde una actualización menor rompe tres sistemas descendentes

La estructura baja la carga cognitiva

La apuesta principal de Dijkstra era que los humanos son el cuello de botella. Flujo de control claro, unidades pequeñas bien definidas y código que puedas razonar no son opciones estéticas: son multiplicadores de capacidad.

En una base de código grande, la estructura actúa como compresión para la comprensión. Si las funciones tienen inputs/outputs explícitos, los módulos tienen fronteras que puedes nombrar y la “ruta feliz” no está mezclada con cada caso límite, los desarrolladores gastan menos tiempo reconstruyendo intención y más tiempo en cambios deliberados.

Escala con equipos, no solo con código

A medida que crecen los equipos, los costes de comunicación suben más rápido que las líneas de código. El código disciplinado y legible reduce la cantidad de conocimiento tribal necesario para contribuir con seguridad.

Eso se nota de inmediato en la incorporación: los ingenieros nuevos siguen patrones predecibles, aprenden un pequeño conjunto de convenciones y hacen cambios sin necesitar un largo tour de “trampas”. El propio código enseña el sistema.

Los incidentes se debuggean más fácil—y es más seguro deshacer cambios

Durante un incidente, el tiempo es escaso y la confianza frágil. El código escrito con supuestos explícitos (precondiciones), cheques significativos y flujo de control directo es más fácil de rastrear bajo presión.

Igualmente importante: los cambios disciplinados son más fáciles de revertir. Ediciones más pequeñas y localizadas con fronteras claras reducen la posibilidad de que un rollback provoque fallos nuevos. El resultado no es perfección: son menos sorpresas, recuperaciones más rápidas y un sistema que se mantiene manejable a medida que pasan los años y se suman contribuyentes.

Aplicar a Dijkstra sin ser dogmático

El punto de Dijkstra no era “programar a la antigua”. Era “escribir código que puedas explicar”. Puedes adoptar esa mentalidad sin convertir cada característica en un ejercicio de prueba formal.

Convierte principios en hábitos diarios

Empieza con decisiones que abaraten el razonamiento:

• Prefiere flujo de control simple: varias funciones pequeñas en vez de una rutina multi-branch “que lo hace todo”.
• Reduce efectos secundarios: mantiene la mutación cerca de donde se necesita y evita que las funciones cambien estado global en silencio.
• Usa contratos claros: deja explícitos inputs, outputs y comportamiento ante errores (en tipos, nombres y comentarios).

Una buena heurística: si no puedes resumir en una frase lo que una función garantiza, probablemente hace demasiado.

Pequeñas “mejoras estructurales” (sin reescrituras)

No necesitas un gran sprint de refactor. Añade estructura en las costuras:

• Extrae un bucle complejo en una función con nombre y define qué permanece verdadero en cada iteración.
• Reemplaza condicionales “mágicos” por predicados con nombre (p. ej., isEligibleForRefund).
• Encapsula una transición de estado complicada detrás de una única función para que el resto del código no la misuse.

Estas mejoras son incrementales: reducen la carga cognitiva para el siguiente cambio.

Prompts de revisión que te mantienen honesto

Al revisar o escribir un cambio, pregunta:

• “¿Qué debe ser verdad aquí?” (invariantes, supuestos, estado requerido)
• “¿Qué puede cambiar con seguridad?” (qué partes pueden variar sin romper a los llamantes)

Si los revisores no pueden responder rápido, el código está señalando dependencias ocultas.

Documenta el razonamiento, no solo los pasos

Los comentarios que restan el código se vuelven obsoletos. En su lugar, escribe por qué el código es correcto: los supuestos clave, los casos límite que proteges y qué pasaría si esos supuestos cambian. Una nota corta como “Invariant: total is always the sum of processed items” puede valer más que un párrafo narrativo.

Si quieres un lugar ligero para capturar estos hábitos, recógelos en una lista compartida (ver /blog/practical-checklist-for-disciplined-code).

Dónde encaja la construcción asistida por IA (sin perder disciplina)

Los equipos modernos usan cada vez más IA para acelerar la entrega. El riesgo es conocido: velocidad hoy puede convertirse en confusión mañana si el código generado es difícil de explicar.

Una manera afín a Dijkstra de usar IA es tratarla como un acelerador del pensamiento estructurado, no como su reemplazo. Por ejemplo, al construir en Koder.ai—una plataforma vibe-coding donde creas apps web, backend y móviles por chat—puedes mantener los hábitos de “razonar primero” haciendo explícitos tus prompts y pasos de revisión:

• Pide contratos claros: “Define preconditions, postconditions, and error behavior for this endpoint.”
• Pide invariantes en flujos con estado: “What must always be true after each step of this checkout state machine?”
• Usa el modo de planificación para forzar la descomposición en piezas pequeñas y revisables (módulos, interfaces, responsabilidades) antes de generar detalles de implementación.
• Apóyate en snapshots y rollback para mantener cambios pequeños y reversibles—espejando la disciplina de ediciones localizadas y caminos de deshacer seguros.

Aunque eventualmente exportes el código y lo ejecutes en otro lado, la misma regla aplica: el código generado debe ser código que puedas explicar.

Una checklist práctica para código correcto, simple y disciplinado

Esta es una checklist ligera “amigable a Dijkstra” que puedes usar en revisiones, refactors o antes de mergear. No se trata de escribir pruebas todo el día: se trata de hacer que la corrección y la claridad sean la opción por defecto.

Chequeo rápido (código nuevo y refactors)

• ¿Puedo explicar el código a un compañero en 60 segundos? Si la explicación requiere mucho “confía en mí”, simplifica.
• ¿El flujo de control es evidente? Prefiere código en línea recta; mantén bucles y condicionales pequeños; evita salidas ocultas y ramas muy anidadas.
• ¿Cuáles son las precondiciones y postcondiciones? Escríbelas en un comentario, docstring o nombre de función. Si no puedes enunciarlas, la función probablemente hace demasiado.
• ¿Cada función tiene un trabajo y una frontera clara? Entradas adentro, salidas afuera—mínima dependencia de estado global.
• ¿Qué invariante mantiene honesto a este bucle? Incluso una nota de una línea como “total always equals sum of processed items” previene bugs sutiles.
• ¿Hay menos trucos “ingeniosos” de los necesarios? Si el código necesita guía turística, está acumulando deuda por astucia.

Qué medir cualitativamente

• Facilidad de explicación: ¿Alguien ajeno al módulo puede decir qué hace y por qué es correcto?
• Facilidad de pruebas: ¿Los casos límite son naturalmente testeables o requieren montajes y mocks elaborados?
• Riesgo de cambio: Cuando cambian los requisitos, ¿puedes predecir qué se rompe? Si cada cambio asusta, las fronteras están filtrando.

Un siguiente paso práctico

Elige un módulo desordenado y reestructura el flujo de control primero:

1. Extrae funciones pequeñas con nombres claros.
2. Reemplaza ramas enmarañadas por casos más simples y explícitos.
3. Mueve los casos especiales a los bordes (validación de entrada, retornos tempranos).

Luego añade algunas pruebas focalizadas alrededor de las nuevas fronteras. Si quieres más patrones como este, explora posts relacionados en /blog.