Lecciones de Clean Code de Robert C. Martin para equipos más rápidos

Por qué Clean Code sigue importando para los equipos modernos

Robert C. Martin —más conocido como “Uncle Bob”— popularizó el movimiento Clean Code con una premisa simple: el código debe escribirse para la próxima persona que tenga que cambiarlo (a menudo, esa persona eres tú dentro de tres semanas).

Mantenibilidad y velocidad del equipo (en lenguaje llano)

Mantenibilidad es qué tan fácilmente tu equipo puede entender el código, cambiarlo de forma segura y desplegar esos cambios sin romper partes no relacionadas. Si cada edición pequeña se siente arriesgada, la mantenibilidad es baja.

Velocidad del equipo es la capacidad sostenida del equipo para entregar mejoras útiles a lo largo del tiempo. No es “teclear más rápido”: es qué tan pronto puedes ir de la idea al software funcionando, una y otra vez, sin acumular daño que te ralentice después.

Por qué la calidad del código es un asunto de equipo

Clean Code no se trata de las preferencias de estilo de un desarrollador. Es un entorno de trabajo compartido. Un módulo desordenado no solo frustra a quien lo escribió; aumenta el tiempo de revisión, dificulta la incorporación de nuevos, crea bugs que tardan más en diagnosticarse y obliga a todos a avanzar con cautela.

Cuando varias personas contribuyen a la misma base de código, la claridad se vuelve una herramienta de coordinación. La meta no es “código bonito”, sino cambio predecible: cualquiera del equipo puede hacer una actualización, entender qué afecta y sentirse seguro al fusionarla.

Hábitos prácticos, no perfección

Clean Code puede llevarse al extremo si se trata como una prueba de pureza. Los equipos modernos necesitan guías que rindan en plazos reales. Piensa en esto como un conjunto de hábitos que reducen la fricción: pequeñas decisiones que se acumulan en entregas más rápidas.

A lo largo del resto del artículo nos centraremos en tres áreas que mejoran más directamente la mantenibilidad y la velocidad:

• Nombres: hacer el significado obvio para que la gente gaste menos tiempo decodificando la intención.
• Límites: separar responsabilidades para que los cambios no creen efectos en cascada.
• Disciplina: prácticas consistentes (revisiones, tests, refactorización) que impiden que la base de código vuelva al caos.

La idea central de Clean Code: optimizar para el cambio

Clean Code no trata principalmente de estética o preferencia personal. Su objetivo central es práctico: hacer el código fácil de leer, de razonar y, por tanto, fácil de cambiar.

Los equipos raramente fallan porque no pueden escribir código nuevo. Fallan porque el código existente es difícil de modificar de forma segura. Los requerimientos cambian, aparecen casos límite y los plazos no se detienen mientras los ingenieros “reaprenden” qué hace el sistema.

Claro vence a ingenioso

El código “ingenioso” suele optimizar para la satisfacción momentánea del autor: lógica condensada, atajos inesperados o abstracciones complejas que parecen elegantes —hasta que alguien más tiene que editarlas.

El código “claro” optimiza para el próximo cambio. Prefiere un flujo de control directo, intención explícita y nombres que expliquen por qué algo existe. La meta no es eliminar toda complejidad (el software no puede), sino poner la complejidad donde corresponde y mantenerla visible.

El costo de la confusión es medible

Cuando el código es difícil de entender, los equipos lo pagan repetidamente:

• Entrega más lenta: se dedica más tiempo a leer, rastrear y comprobar.
• Más bugs: los malentendidos llevan a correcciones incorrectas o cambios parciales.
• Más retrabajo: los ingenieros implementan soluciones parche porque “tocar esa zona da miedo”, lo que añade deuda técnica.

Por eso Clean Code se conecta directamente con la velocidad del equipo: reducir la confusión reduce la vacilación.

Principios, no mandamientos

Clean Code es un conjunto de compensaciones, no reglas rígidas. A veces una función un poco más larga es más clara que dividirla. A veces las limitaciones de rendimiento justifican un enfoque menos “bonito”. El principio sigue siendo el mismo: preferir opciones que mantengan los cambios futuros seguros, locales y comprensibles, porque el cambio es el estado por defecto del software real.

Nombres: la vía más rápida hacia código legible y mantenible

Si quieres código fácil de cambiar, empieza por los nombres. Un buen nombre reduce la cantidad de “traducción mental” que el lector tiene que hacer, para que pueda centrarse en el comportamiento en lugar de descifrar qué significan las cosas.

Qué debe comunicar un buen nombre

Un nombre útil transporta información:

• Intención: qué representa o hace (no cómo está implementado).
• Ámbito: ¿es un valor único, una colección, una caché, una petición, un borrador?
• Unidades y formato: Cents vs Dollars, Utc vs hora local, Bytes vs Kb, string vs objeto parseado.
• Restricciones: ¿incluye impuestos, está descontado, está validado, es un máximo?

Cuando esos detalles faltan, el lector tiene que hacerse preguntas —o peor— adivinar.

Nombres ambiguos vs claros (ejemplos)

Nombres vagos ocultan decisiones:

• data, info, tmp, value, result
• list, items, map (sin contexto)

Nombres claros aportan contexto y reducen seguimiento:

• invoiceTotalCents (unidad + dominio)
• discountPercent (formato + significado)
• validatedEmailAddress (restricción)
• customerIdsToDeactivate (ámbito + intención)
• expiresAtUtc (zona horaria)

Incluso pequeños renombrados pueden prevenir bugs: timeout es ambiguo; timeoutMs no lo es.

Consistencia: usar el lenguaje del producto

Los equipos avanzan más rápido cuando el código usa las mismas palabras que aparecen en tickets, copia de UI y conversaciones de soporte. Si el producto dice “subscription”, evita llamarlo plan en un módulo y membership en otro, salvo que sean conceptos realmente distintos.

La consistencia también significa elegir un término y mantenerlo: customer vs client, invoice vs bill, cancel vs deactivate. Si las palabras derivan, el significado deriva.

Nombrar es coordinación, no estilo

Los buenos nombres actúan como pequeñas piezas de documentación. Reducen preguntas en Slack (“¿qué contiene tmp otra vez?”), bajan la fricción en las revisiones y evitan malentendidos entre ingenieros, QA y producto.

Lista rápida de comprobación para nombres

Antes de confirmar un nombre, pregúntate:

• ¿Un compañero nuevo adivinaría qué es sin abrir otros archivos?
• ¿Indica unidades/zona horaria/formato donde importa?
• ¿Está alineado con la terminología del producto?
• ¿Evita palabras contenedor como data salvo que el dominio esté explícito?
• Si es booleano, ¿se lee claro: isActive, hasAccess, shouldRetry?

Mantener honestos los nombres: prevenir la “deriva de nombres”

Un buen nombre es una promesa: le dice al siguiente lector qué hace el código. El problema es que el código cambia más rápido que los nombres. Tras meses de edición rápida y “solo lanzar”, una función validateUser() empieza a validar y provisionar y hacer analytics. El nombre sigue pareciendo ordenado, pero ya no es fiel —y los nombres engañosos cuestan tiempo.

Por qué los nombres deben reflejar lo que el código hace hoy

Clean Code no consiste en elegir nombres perfectos una vez. Consiste en mantener los nombres alineados con la realidad. Si un nombre describe lo que el código hacía, cada lector futuro tiene que deducir la verdad desde la implementación. Eso aumenta la carga cognitiva, ralentiza las revisiones y hace que los cambios pequeños sean más riesgosos.

Cómo ocurre la deriva en equipos reales

La deriva raramente es intencional. Suele venir de:

• Arreglos rápidos: parchear comportamiento sin revisar la intención.
• Creep de funcionalidades: “una responsabilidad más” añadida a una función existente por conveniencia.
• Copiar-pegar: clonar código y ajustar lógica pero mantener nombres originales.

Formas ligeras de mantener nombres precisos

No necesitas un comité de nombres. Unos pocos hábitos simples funcionan:

• Cuando una función gana una responsabilidad nueva, renómbrala para reflejar el nuevo alcance o divídela para que el nombre antiguo siga siendo verdad.
• Añade al checklist de revisión: “¿Los nombres aún describen el comportamiento?” (es rápido y detecta mucho).
• Si te encuentras escribiendo un comentario como “Esto en realidad…”, suele ser señal de que hace falta renombrar.

La regla “renombra cuando tocas”

Durante cualquier edición pequeña —fix, refactor o ajuste de funcionalidad— dedica 30 segundos a ajustar el nombre engañoso más cercano. Este hábito evita que la deriva se acumule y mantiene la legibilidad mejorando con el trabajo diario.

Límites: separar responsabilidades para reducir efectos en cascada

Clean Code no es solo métodos ordenados: es trazar límites claros para que el cambio se mantenga local. Los límites aparecen en módulos, capas, servicios, APIs e incluso en “quién se encarga de qué” dentro de una clase.

Separación de responsabilidades (con analogía de cocina)

Piensa en una cocina con estaciones: preparación, parrilla, emplatado y lavado. Cada estación tiene un trabajo claro, herramientas e insumos. Si la parrilla empieza a lavar platos “esta vez”, todo se ralentiza: las herramientas desaparecen, se forman colas y queda poco claro quién responde cuando algo falla.

El software funciona igual. Con límites claros, puedes cambiar la “parrilla” (lógica de negocio) sin reorganizar el “lavado” (acceso a datos) o el “emplatado” (formato UI/API).

Cómo los límites poco claros ralentizan al equipo

Los límites poco claros crean efectos en cascada: un pequeño cambio obliga a editar múltiples áreas, pruebas adicionales, más idas y venidas en las revisiones y mayor riesgo de bugs no deseados. El equipo empieza a dudar: cada cambio se siente propenso a romper algo no relacionado.

Olores comunes de límites:

• Responsabilidades mezcladas: un módulo calcula precios y también escribe en la base de datos.
• Atajos entre capas: código UI consultando la base de datos “por rendimiento”.
• Abstracciones con fugas: un servicio expone tablas internas u objetos ORM como API pública.
• Utilidades “helper” que acumulan comportamientos no relacionados con el tiempo.

Cómo se sienten los buenos límites en el día a día

Con buenos límites, los tickets son previsibles. Un cambio en una regla de precios toca mayormente el componente de precios, y los tests te dicen rápido si cruzaste una línea. Las revisiones son más simples (“esto pertenece a la capa de dominio, no al controlador”) y la depuración es más rápida porque cada pieza tiene un único lugar que mirar y una sola razón para cambiar.

Funciones pequeñas e intención clara: hacer el cambio más seguro

Las funciones pequeñas y enfocadas facilitan el cambio porque reducen la cantidad de contexto que hay que mantener en la cabeza. Cuando una función tiene un solo propósito claro, puedes probarla con pocos inputs, reutilizarla y entender fallos sin recorrer un laberinto de pasos no relacionados.

“Hacer una sola cosa” (con ejemplo concreto)

Considera una función llamada processOrder() que: valida una dirección, calcula impuestos, aplica descuentos, cobra una tarjeta, envía un correo y escribe logs de auditoría. Eso no es “procesar un pedido”: son cinco decisiones y tres efectos secundarios agrupados.

Un enfoque más limpio separa la intención:

function processOrder(order) {
  validate(order)
  const priced = price(order)
  const receipt = charge(priced)
  sendConfirmation(receipt)
  return receipt
}

Cada helper puede probarse y reutilizarse de forma independiente, y la función de alto nivel se lee como una historia corta.

Por qué las funciones largas son riesgosas

Las funciones largas ocultan puntos de decisión y casos límite porque entierran el “¿y si…?” en medio de trabajo no relacionado. Un solo if para “dirección internacional” puede afectar silenciosamente impuestos, envío y redacción del email —y la conexión es difícil de ver cuando está a 80 líneas de distancia.

Pasos prácticos de refactorización

Comienza pequeño:

• Extraer función: selecciona un bloque coherente y muévelo a calculateTax() o formatEmail().
• Renombrar: usa nombres que describan resultados (applyDiscounts vs doDiscountStuff).
• Eliminar duplicación: si dos ramas repiten pasos, extrae un helper compartido.

Guardarraíles (evitar sobre-fragmentación)

Pequeño no significa “mínimo a cualquier precio”. Si creas muchos wrappers de una línea que obligan al lector a saltar por cinco archivos para entender una acción, has cambiado claridad por indirección. Apunta a funciones cortas, significativas y entendibles localmente.

Gestionar efectos secundarios: menos sorpresas, depuración más fácil

Un efecto secundario es cualquier cambio que una función hace además de producir su valor de retorno. En términos sencillos: llamas a un helper esperando una respuesta y este cambia algo en silencio —escribe un archivo, actualiza una fila, muta un objeto compartido o cambia una bandera global.

Los efectos secundarios no son automáticamente “malos”. El problema son los efectos ocultos. Sorprenden a los llamadores, y las sorpresas son las que convierten cambios simples en largas sesiones de depuración.

Por qué los efectos secundarios ralentizan a los equipos

Los cambios ocultos hacen el comportamiento impredecible. Un bug puede aparecer en una parte de la app pero ser causado por un helper “conveniente” en otro sitio. Esa incertidumbre mata la velocidad: los ingenieros dedican tiempo a reproducir problemas, añadir logging temporal y discutir sobre dónde debe vivir la responsabilidad.

También dificultan las pruebas. Una función que escribe en la base de datos o toca estado global necesita setup/cleanup, y los tests empiezan a fallar por razones no relacionadas con la funcionalidad en desarrollo.

Patrones que reducen las sorpresas

Prefiere funciones con entradas y salidas claras. Si algo debe cambiar el mundo fuera de la función, hazlo explícito:

• Pasa dependencias (logger, repositorio, reloj) en lugar de alcanzar globals.
• Separa “calcular” de “hacer”: una función calcula; otra realiza la escritura.
• Nombra los efectos honestamente (p. ej., saveUser() vs getUser()).

Trampas comunes: logging dentro de helpers de bajo nivel, mutar objetos de configuración compartidos y realizar escrituras en BD durante pasos que parecen formato o validación.

Lista rápida para revisiones

Al revisar código, haz una pregunta simple: “¿Qué cambia además del valor de retorno?”

Seguimientos: ¿muta argumentos? ¿toca estado global? ¿escribe en disco/red? ¿dispara trabajos en background? Si es así, ¿podemos hacer el efecto explícito o moverlo a un mejor límite?

Disciplina: el efecto compuesto en la velocidad de entrega

Clean Code no es solo una preferencia de estilo: es disciplina: hábitos repetibles que mantienen la base de código predecible. Piensa menos en “escribir código bonito” y más en rutinas que reducen la varianza: tests antes de cambios riesgosos, refactors pequeños cuando tocas código, documentación ligera donde evita confusión y revisiones que detectan problemas temprano.

Velocidad ahora vs velocidad en el próximo mes

Los equipos a menudo “van rápido” hoy saltándose estos hábitos. Pero esa velocidad suele ser prestada del futuro. La factura llega en releases frágiles, regresiones sorpresa y caos en el ciclo final cuando un cambio simple desencadena una reacción en cadena.

La disciplina intercambia un pequeño coste consistente por fiabilidad: menos emergencias, menos arreglos de último minuto y menos situaciones en las que el equipo debe parar todo para estabilizar un release. Con el tiempo, esa fiabilidad se convierte en rendimiento real.

Prácticas diarias que se componen

Unas pocas conductas simples suman rápidamente:

• Añade o actualiza un test al arreglar un bug (para que no vuelva).
• Refactoriza el área que tocaste mientras aún está en tu cabeza (renombra, extrae función, elimina duplicación).
• Mantén cambios pequeños y fáciles de revisar (branches de corta duración, descripciones claras en PRs).
• Trata la revisión de código como propiedad compartida: pregunta “¿la próxima persona entenderá esto?” en vez de “¿funciona?”.

“No tenemos tiempo para limpieza”

Esa objeción suele ser cierta en el momento —y costosa con el tiempo. El compromiso práctico es el alcance: no programes una limpieza masiva; aplica disciplina en los bordes del trabajo diario. Semanalmente, esos pequeños depósitos reducen la deuda técnica y aumentan la velocidad de entrega sin un gran rewrite.

Tests como ejecutores de límites y red de seguridad para refactorizaciones

Los tests no son solo para “atrapar bugs”. En términos de Clean Code, protegen límites: el comportamiento público que tu código promete a otras partes del sistema. Cuando cambias internals—divides un módulo, renombras métodos, mueves lógica—buenos tests confirman que no rompiste silenciosamente el contrato.

Feedback rápido vence a arreglos tardíos

Un test fallando segundos después de un cambio es barato de diagnosticar: aún recuerdas qué tocaste. Compáralo con un bug encontrado días después en QA o producción, cuando el rastro está frío, la corrección es más riesgosa y varios cambios están entrelazados. El feedback rápido convierte la refactorización de una apuesta en una rutina.

Qué testear primero (cuando el tiempo es limitado)

Comienza con cobertura que te dé libertad:

• Comportamiento crítico: flujos que generan dinero, protegen datos o bloquean usuarios.
• Lógica complicada: casos límite, parseos, zonas horarias, redondeos, permisos.
• Fallos comunes: entradas problemáticas, integraciones flakey, reglas de reintento.

Heurística práctica: si un bug sería caro o embarazoso, escribe un test que lo hubiera detectado.

Mantén los tests legibles—como documentación

Los tests limpios aceleran el cambio. Trátalos como ejemplos ejecutables:

• Nombra tests con intención: rejects_expired_token() se lee como un requisito.
• Prefiere un setup claro sobre helpers ingeniosos. Si un helper oculta significado, no ayuda.
• Aserta resultados, no pasos internos. Quieres libertad para reescribir la implementación.

Evita tests frágiles que ralentizan el cambio

Los tests se vuelven un impuesto cuando te encadenan a la estructura actual—mocking excesivo, aserciones sobre detalles privados o depender de texto/HTML exacto del UI cuando solo te importa el comportamiento. Los tests frágiles fallan por “ruido”, entrenando al equipo a ignorar builds rojos. Apunta a tests que fallen solo cuando algo relevante se rompe.

Hábitos de refactorización: pasos pequeños que mantienen la deuda bajo control

Refactorizar es una de las lecciones más prácticas de Clean Code: es una mejora que preserva comportamiento en la estructura del código. No cambias qué hace el software; cambias qué tan claro y seguro será cambiarlo la próxima vez.

Una mentalidad simple es la Regla del Boy Scout: deja el código un poco más limpio de lo que lo encontraste. Eso no significa pulir todo. Significa hacer pequeñas mejoras que reduzcan la fricción para la siguiente persona (a menudo tu futuro yo).

Refactors seguros y pequeños que valen la pena

Los mejores refactors son de bajo riesgo y fáciles de revisar. Algunos que consistentemente reducen deuda técnica:

• Renombrar variables, funciones y clases para que coincidan con lo que realmente hacen (especialmente después de que evolucionen los requisitos).
• Extraer método cuando un bloque tiene un propósito único pero está enterrado en una función larga.
• Simplificar condicionales eliminando negaciones, colapsando ramas duplicadas o introduciendo helpers con nombres claros.

Estos cambios son pequeños pero hacen la intención obvia —lo que acorta la depuración y acelera ediciones futuras.

Cuándo refactorizar (sin bloquear entregas)

Refactorizar funciona mejor cuando está atado a trabajo real:

• Antes de añadir una feature: despeja el camino para que el nuevo código encaje naturalmente, en vez de forzar hacks.
• Después de arreglar un bug: cuando encuentras el punto débil, haz que sea más difícil que vuelva el mismo tipo de bug.

Cuándo detenerse

Refactorizar no es licencia para limpieza sin fin. Para cuando el esfuerzo se convierte en un rewrite sin un objetivo claro y testeable, haz una pausa. Si el cambio no puede expresarse como una serie de pasos pequeños y revisables (cada uno seguro para merge), divídelo en hitos más pequeños —o déjalo para otra ocasión.

Revisiones de código y normas: convertir principios en hábitos del equipo

Clean Code solo mejora la velocidad cuando se convierte en un reflejo del equipo —no en una preferencia personal. Las revisiones de código son donde principios como nombres, límites y funciones pequeñas se transforman en expectativas compartidas.

Para qué sirve una revisión

Una buena revisión optimiza:

• Entendimiento compartido: más que “LGTM”—el equipo debería entender qué cambió y por qué.
• Consistencia: nombres, estructura y convenciones que hacen que el código se sienta familiar.
• Chequeo de límites: ¿se separaron responsabilidades o se coló lógica entre capas?
• Gestión de riesgo: identificar efectos secundarios, casos borde y preocupaciones de despliegue temprano.

Plantilla ligera para revisiones

Usa un checklist repetible para acelerar aprobaciones y reducir idas y vueltas:

1. Intención: ¿qué problema resuelve este cambio? ¿el diseño es simple?
2. Legibilidad: ¿los nombres son específicos y honestos? ¿hay código “ingenioso” que podría aclararse?
3. Límites: ¿mantenemos responsabilidades en el lugar correcto (UI/servicio/dominio/datos)?
4. Tests: ¿qué lo prueba? ¿qué fallaría si esto se rompe más adelante?
5. Riesgos: rendimiento, seguridad, migraciones, compatibilidad hacia atrás.
6. Seguimientos: ¿qué deuda pospusimos intencionalmente (con ticket/enlace)?

Normas que reducen debate

Normas escritas (convenciones de nombres, estructura de carpetas, patrones de manejo de errores) eliminan argumentos subjetivos. En lugar de “prefiero…”, los revisores pueden señalar “lo hacemos así”, lo que hace las revisiones más rápidas y menos personales.

Amabilidad y claridad

Critica el código, no al autor. Prefiere preguntas y observaciones sobre juicios:

• “¿Podríamos renombrar process() a calculateInvoiceTotals() para que coincida con lo que devuelve?”
• “Esta función cruza el límite de persistencia—¿no debería la repository encargarse de esa consulta?”

Comentarios: útiles vs ruidosos

Buen comentario:

// Why: rounding must match the payment provider’s rules (see PAY-142).

Comentario ruidoso:

// increment i

Apunta a comentarios que expliquen por qué, no qué ya dice el código.

Cómo aplicar Clean Code para mejorar la velocidad (sin dogmas)

Clean Code solo ayuda si facilita el cambio. La forma práctica de adoptarlo es tratarlo como un experimento: acordar unos comportamientos, medir resultados y conservar lo que reduzca la fricción de forma mensurable.

Esto importa aún más cuando los equipos usan cada vez más desarrollo asistido por IA. Ya sea que generes esqueleto con un LLM o iterares dentro de un flujo de trabajo asistido, aplican los mismos principios: nombres claros, límites explícitos y refactorización disciplinada mantienen la iteración rápida fuera de convertirse en espagueti difícil de cambiar. Las herramientas aceleran la salida, pero las prácticas de Clean Code preservan el control.

Medir la velocidad midiendo fricción

En lugar de debatir estilo, observa señales que correlacionan con ralentizaciones:

• Tiempo en PR: desde abrir un PR hasta merge (y tiempo en “esperando revisión”).
• Tasa de defectos: bugs encontrados en QA/producción por release.
• Tiempo de incorporación: cuánto tarda un nuevo compañero en enviar un cambio seguro.
• Retrabajo: porcentaje de trabajo que se deshace (rollback, tickets reabiertos, “arregla el arreglo”).

Llevar un “registro de fricción” ligero

Una vez por semana, dedica 10 minutos a capturar problemas repetidos en una nota compartida:

• “Difícil encontrar dónde se implementa X.”
• “Los tests fallan por cambios no relacionados.”
• “Este módulo tiene demasiadas razones para cambiar.”

Con el tiempo aparecen patrones. Esos patrones te dicen qué hábito de Clean Code dará mayor retorno.

Crear un pequeño acuerdo de equipo

Mantenlo simple y aplicable:

• Reglas de nombres: preferir nombres que revelen intención; prohibir palabras vagas como data, manager, process salvo que estén bien acotadas.
• Reglas de límites: un módulo = una responsabilidad clara; evitar mezclar persistencia, reglas de negocio y formateo en la misma unidad.
• Mínimos de testing: cada fix añade un test; nuevo comportamiento se entrega con el test apropiado.

Plan de despliegue de 30 días (un hábito por semana)

• Semana 1 — Nombres: renombra los peores casos que toques; exige “¿este nombre sigue siendo correcto?” en los PRs.
• Semana 2 — Límites: extrae una seam de dependencia (p. ej., encapsular una API externa detrás de una interfaz).
• Semana 3 — Efectos secundarios: haz un flujo más predecible (valores de retorno en lugar de mutación oculta; logging en el borde).
• Semana 4 — Refactor con tests: elige un archivo caliente y mejóralo con PRs pequeños.

Revisa métricas al final de cada semana y decide qué mantener.

Checklist rápido

• ¿Un recién llegado puede encontrar el lugar del cambio en menos de 2 minutos?
• ¿Los nombres siguen coincidiendo con el comportamiento tras la última edición?
• ¿Hay un límite claro entre lógica de negocio y IO?
• ¿Puedes cambiar una parte sin tocar cinco otras?
• ¿Este PR reduce trabajo futuro (o lo añade)?