Clean Code y SOLID sin dogma: qué aplicar de verdad
El código limpio no es estética. Es la diferencia entre cambiar una regla en una tarde y pasar dos semanas con miedo de tocar un archivo. Los principios que se hicieron conocidos por Robert C. Martin, y las prácticas de refactorización descritas por Martin Fowler, existen para reducir ese miedo, no para producir archivos pequeños por obligación.
La legibilidad es economía, no capricho
El código se lee muchas más veces de las que se escribe. Nombres precisos, funciones con una responsabilidad clara y ausencia de sorpresas reducen el tiempo que cualquier persona tarda en entender lo que ya existe, y ese tiempo es el principal costo de mantenimiento.
La prueba práctica es sencilla: ¿alguien que no escribió ese fragmento puede predecir lo que hace solo por el nombre y la firma? Si necesita leer toda la implementación para estar seguro, hay espacio para mejorar.
- Nombres que revelan intención, no implementación.
- Funciones lo bastante cortas para caber en la cabeza, no en una métrica arbitraria.
- Efecto colateral explícito, nunca escondido en un nombre inofensivo.
SOLID explicado por el dolor que evita
Responsabilidad única evita que un cambio de informe rompa el cálculo de impuestos. Abierto/cerrado evita una cascada de cambios cuando surge un tipo nuevo. Sustitución de Liskov evita que una implementación alternativa rompa a quien usa la abstracción. Segregación de interfaces evita obligar a quien implementa a rellenar métodos que no tienen sentido. Inversión de dependencias evita que la regla de negocio dependa de un detalle de base de datos o de proveedor.
Ninguno de estos principios pide una capa extra por defecto. Todos piden atención al punto donde el cambio suele doler.
Cuándo no aplicarlos
Una abstracción creada demasiado pronto sale cara: congela una hipótesis antes de que exista evidencia. Duplicar una vez suele ser más barato que abstraer mal. La tercera repetición, esa sí, es una buena señal de que apareció el patrón real.
Kent Beck resume bien la secuencia práctica: haz que funcione, hazlo correcto, hazlo rápido. Invertir ese orden es el origen de buena parte de la complejidad innecesaria que encontramos en bases de código antiguas.
La refactorización es rutina apoyada en pruebas
Refactorizar significa cambiar la estructura sin cambiar el comportamiento, y eso solo es verificable con pruebas. Sin red de seguridad, lo que parece refactorización es una reescritura con riesgo. Pequeñas mejoras continuas, hechas junto con cada entrega, evitan el proyecto de reforma que nunca se aprueba.
En resumen
Aplica el principio donde el cambio duele, no donde lo manda la lista de revisión. Código limpio es el que permite cambiar con confianza mañana.
Casos de uso
Base legada sin pruebas
Pruebas de caracterización primero, para congelar el comportamiento actual antes de cualquier cambio estructural.
Regla de negocio dispersa
Consolidación en un módulo de dominio, con la interfaz dependiendo de él y no al revés.
Integración con proveedor
Aislamiento detrás de una abstracción delgada, que permite cambiar de proveedor sin tocar la regla.
Errores comunes
- Crear una interfaz para todo, sin ninguna segunda implementación prevista.
- Dividir funciones por cantidad de líneas en vez de por responsabilidad.
- Tratar SOLID como lista de revisión en lugar de criterio de decisión.
- Posponer la refactorización hasta que se vuelva un proyecto aparte.
Buenas prácticas
- Deja el código un poco mejor de como lo encontraste, en cada cambio.
- Abstrae en la tercera repetición, con evidencia.
- Escribe la prueba antes de refactorizar un fragmento crítico.
- Prefiere composición sobre herencia cuando haya duda.
Libros recomendados
Clean Code — Robert C. Martin
Criterios objetivos de legibilidad y responsabilidad a nivel de función.
Refactoring — Martin Fowler
Catálogo de transformaciones seguras apoyadas en pruebas.
A Philosophy of Software Design — John Ousterhout
Contrapunto valioso sobre la profundidad de los módulos y el costo de la fragmentación excesiva.
Para profundizar
Preguntas frecuentes
- ¿SOLID todavía tiene sentido hoy?
- Sí, como criterio de decisión sobre acoplamiento y dependencia. Como regla de memoria aplicada a todo, genera complejidad sin beneficio.
- ¿Cuál es el tamaño ideal de una función?
- El suficiente para expresar una responsabilidad clara. La cantidad de líneas es un indicio, no un criterio.
- ¿Cuándo refactorizar?
- Continuamente, junto con la entrega, y siempre con pruebas que cubran el comportamiento que no puede cambiar.
- ¿Cómo convencer al equipo de invertir en calidad?
- Tradúcelo en plazos: muestra el tiempo perdido por retrabajo y por miedo a tocar áreas críticas.
Referencias
- Robert C. Martin — principios de responsabilidad y dependencia
- Martin Fowler — refactorización y malos olores de código
- John Ousterhout — complejidad y diseño de módulos
Contenido original del equipo de i9 Conecty. Los conceptos clásicos se explican con palabras propias y se acreditan a sus autores.