Al desarrollar, a veces resulta extraño sentir que escribir código complicado significa hacerlo mejor.
Añadimos muchos patrones de diseño, acumulamos capas de abstracción y definimos interfaces por adelantado porque «quizá haya que ampliarlo más adelante».
Pero cuando vuelves a abrir ese código unos años después, descubres que quien acaba sufriendo es tu yo del futuro.
Hoy hablaremos de KISS, el principio que se sitúa en el extremo opuesto.
En resumen, KISS son las siglas de «Keep It Simple, Stupid». Traducido literalmente, sería algo como «Mantenlo simple, idiota».
Es una filosofía de diseño según la cual los sistemas funcionan mejor cuando se mantienen simples, no cuando se construyen de forma compleja.
¿De dónde surge el principio KISS?
Esta expresión no nació como un término de software.
Se atribuye a Kelly Johnson, ingeniero aeronáutico de Lockheed en Estados Unidos durante la década de 1960. Diseñó los famosos aviones de reconocimiento U-2 y SR-71 Blackbird.
Al parecer, esto es lo que Kelly Johnson exigía a su equipo.
Construid un avión que un mecánico corriente pueda reparar en combate usando solo herramientas básicas.
Por brillante que sea un diseño, no sirve de nada si no se puede reparar sobre el terreno.
Esa mentalidad llegó al software. Por ingenioso que sea el código, no es buen código si los compañeros no pueden leerlo y corregirlo.
Por cierto, «Stupid» no pretende llamar tontos a los desarrolladores; se acerca más al matiz de «lo bastante simple como para que cualquiera lo entienda».
Momentos en los que KISS se rompe en el código
Suena fácil en teoría, pero ¿cómo se ve en el código real? Veamos algunos patrones que suelo encontrar.
1. Una línea que parece impresionante
// Así pareces más inteligente
let result = arr.reduce([Int: Item]()) { $0.merging([$1.id: $1]) { _, new in new } }
// Esto es mucho más fácil de leer
var result = [Int: Item]()
for item in arr {
result[item.id] = item
}El código de arriba es corto, pero quien lo ve por primera vez tiene que estudiarlo un buen rato. El de abajo se entiende en tres segundos.
2. Extensibilidad que nunca usarás
Por ejemplo, recurrir al patrón Factory y al patrón Strategy para crear un solo botón. La preocupación es «¿Y si más adelante aumentan los tipos de botón?». Pero ese «más adelante» casi nunca llega.
3. El laberinto de condicionales
Un if dentro de otro if, y otro if dentro de ese. Con solo tres niveles de anidamiento, la pila mental se desborda. En estos casos, aplanar el código con early return puede simplificarlo muchísimo.
Tres criterios prácticos para aplicar KISS
Por eso, al escribir código, uso estos tres criterios.
| Criterio | Pregunta |
|---|---|
| Prueba de explicación | ¿Puedo explicar este código al compañero de al lado en un minuto? |
| Prueba del futuro | ¿Lo entenderé de inmediato cuando lo vea dentro de seis meses? |
| Prueba de necesidad | ¿Añadí este código porque hace falta ahora mismo o porque creo que quizá lo use algún día? |
Si alguna respuesta es «no», vuelvo a pensar si existe una forma más simple.
La tercera es especialmente importante, porque conecta con el principio YAGNI (You Aren’t Gonna Need It). KISS y YAGNI prácticamente van de la mano.
Lo simple no es lo mismo que lo hecho a la ligera
Aquí hay algo que no debemos malinterpretar.
KISS no significa «escribe sin pensar». De hecho, significa todo lo contrario.
Complicar las cosas es fácil: basta con añadir todo lo que se te ocurra. Simplificarlas es difícil, porque debes pensar detenidamente qué eliminar.
Pascal dejó una frase famosa en una carta.
No tuve tiempo de escribirlo más corto, así que lo escribí más largo.
Con el código ocurre lo mismo. El código simple no es fruto de la dejadez, sino del esfuerzo por eliminar la complejidad.
Resumen
En resumen, el principio KISS es el siguiente.
- El código se lee mucho más tiempo del que se tarda en escribirlo. Escríbelo de forma simple para quienes lo leerán.
- No añadas extensibilidad que no necesitas ahora. La situación que te preocupa ocurre con menos frecuencia de lo que crees.
- La simplicidad no demuestra falta de habilidad; demuestra habilidad.
Últimamente, el comentario que más dejo en las revisiones de código es «¿No puede ser más simple?». Curiosamente, una sola pregunta reduce tanto los errores como el tiempo de revisión.
¿Puede tu compañero de al lado entender tu código en un minuto? Te recomiendo hacértelo esa pregunta hoy.
Seguir leyendo
- Entender bien el principio DRY: lo más peligroso que la duplicación de código es una abstracción incorrecta
- Separación de responsabilidades (SoC): experiencia tras operar un componente de 800 líneas
- Principio de menor sorpresa (Principle of Least Astonishment): por qué getUser no debería enviar correos