Diseño Simple
Construye lo más simple que funcione. Resiste la tentación de sobre-diseñar.
1Lo Más Simple Que Funcione
XP tiene un mantra: Haz lo más simple que posiblemente pueda funcionar.
Esto no se trata de ser flojo o escribir código descuidado. El código simple a menudo es más difícil de escribir que el código complejo. Requiere:
- Entender el problema profundamente
- Resistir la tentación de generalizar
- Decir "no" a la especulación
- Confiar en que puedes cambiar las cosas después
El código simple es:
- Fácil de entender
- Fácil de cambiar
- Fácil de probar
- Justo lo suficiente para las necesidades actuales
El código complejo es:
- Difícil de entender
- Riesgoso de cambiar
- Difícil de probar
- Construido para necesidades futuras imaginadas que quizás nunca lleguen
Lo Simple Es Difícil
"Habría escrito una carta más corta, pero no tuve tiempo." —Blaise Pascal. El código simple requiere más reflexión, no menos.
2YAGNI: No Lo Vas a Necesitar
YAGNI es el principio de que solo debes construir lo que necesitas ahora mismo.
No agregues:
- Funcionalidades porque "podrían ser útiles"
- Opciones de configuración porque los usuarios "podrían quererlas"
- Puntos de extensión porque el código "podría necesitarlos"
- Abstracciones para requisitos futuros hipotéticos
¿Por qué? Porque:
- Usualmente te equivocas sobre lo que necesitarás
- El código no utilizado aún tiene costo de mantenimiento
- Cada abstracción tiene un precio en complejidad
- Construir para el futuro retrasa la entrega para hoy
La apuesta de XP: Si necesitas algo después, puedes agregarlo después. Con TDD, refactorización e IC, el cambio es económico. Así que no pagues por el futuro antes de tener que hacerlo.
Esta es una idea radical. La ingeniería de software tradicional dice anticipar el cambio y diseñar para la flexibilidad. XP dice esperar hasta que realmente lo necesites.
El equipo necesita enviar correos. Implementan el envío vía SMTP. Después, necesitan enviar vía SendGrid. Refactorizan. Costo total: menos que construir una abstracción de correo conectable desde el principio.
El equipo necesita enviar correos. Construyen una interfaz genérica 'MessageProvider' con abstracciones conectables 'MessageTransport' y 'MessageFormatter'. Solo usan SMTP con un formato. Las abstracciones ralentizan cada cambio.
3Las Cuatro Reglas del Diseño Simple
Kent Beck definió el diseño simple como código que:
1. Pasa todas las pruebas El código funciona. Esto no es negociable. Un diseño hermoso que no funciona no vale nada.
2. Revela intención El código es fácil de entender. Buenos nombres, estructura clara, organización legible. Alguien nuevo puede tomarlo y entender qué hace.
3. No tiene duplicación (DRY) Cada pieza de conocimiento se expresa una y solo una vez. La duplicación crea carga de mantenimiento y riesgo de errores.
4. Tiene los elementos mínimos Sin clases, métodos, variables o abstracciones extra. Todo lo que existe tiene una razón para existir.
Las reglas están en orden de prioridad. Pasar las pruebas supera todo. Pero una vez que las pruebas pasan, favorece la claridad sobre DRY. Y solo agrega elementos que sirvan a las primeras tres reglas.
4Diseño Incremental
El diseño simple no significa sin diseño. Significa diseño incremental—evolucionar el diseño a medida que aprendes.
El proceso:
- Comienza con la implementación más simple que funcione
- A medida que agregas funcionalidades, nota la fricción (esto se está volviendo incómodo)
- Refactoriza para abordar la fricción
- El diseño emerge de necesidades reales, no de especulación
Por esto XP enfatiza tanto la refactorización. Si no puedes cambiar el código de forma segura, no puedes hacer diseño incremental. Estás atrapado con lo que construiste primero.
El Diseño Grande por Adelantado (BUFD) falla porque:
- No sabes lo suficiente al inicio
- Los requisitos cambian
- Los diseños no sobreviven el contacto con la realidad
- Pagas por complejidad que nunca usas
El diseño incremental tiene éxito porque:
- Diseñas basándote en necesidades reales
- El diseño evoluciona con el entendimiento
- Nunca pagas por lo que no usas
- La refactorización mantiene el diseño limpio
Cuando sientas la tentación de agregar una abstracción, pregunta: "¿Necesito esto ahora, o estoy adivinando?" Si estás adivinando, espera.
5Cuándo la Complejidad Está Justificada
El diseño simple no significa evitar toda complejidad. A veces la complejidad es necesaria.
Agrega complejidad cuando:
- Las pruebas lo requieran (hazlo pasar)
- La claridad lo requiera (revelar intención)
- Eliminar duplicación lo requiera (DRY)
- Los requisitos actuales y reales lo necesiten
No agregues complejidad por:
- Escenarios "¿Qué pasaría si?"
- Posibles funcionalidades futuras
- Frameworks que crees que podrías necesitar
- Hacer el código "más flexible"
La diferencia está entre complejidad esencial (inherente al problema) y complejidad accidental (introducida por tu solución). XP minimiza la complejidad accidental al negarse a construir para requisitos imaginarios.
Cuando sí necesites una abstracción, déjala emerger de eliminar duplicación. La "Regla de Tres" es útil: no abstraigas hasta que veas el mismo patrón tres veces. Para entonces entiendes las variaciones reales, no las imaginadas.
- El código simple es más difícil de escribir pero más fácil de cambiar
- YAGNI: no construyas para requisitos que aún no tienes
- Las cuatro reglas: pasa las pruebas, revela intención, sin duplicación, elementos mínimos
- Deja que el diseño emerja incrementalmente a través de la refactorización
- Agrega complejidad cuando las pruebas, la claridad o DRY lo requieran—no por especulación
- •Confundir simple con simplista (simple es elegante, no tosco)
- •Construir abstracciones antes de necesitarlas
- •Asumir que sabes cuáles serán los requisitos futuros
- •Omitir la refactorización, lo que impide la evolución del diseño