El Principio KISS: La Regla de Oro de la Simplicidad en el Código
El mayor enemigo del software
En el desarrollo de software, uno de nuestros mayores enemigos no son los bugs ni los cambios de requerimientos, sino la complejidad innecesaria.
A menudo, cuando descubrimos un patrón de diseño nuevo o una función avanzada, nos entusiasma tanto que queremos aplicarla en todos lados. Terminamos escribiendo código muy abstracto o resolviendo problemas en una sola línea (one-liners) simplemente porque es técnicamente posible. Pero la realidad de la ingeniería nos enseña que la complejidad extra suele pasar factura.
La complejidad innecesaria hace que el mantenimiento a futuro sea frustrante y propenso a errores.
El Origen: Herramientas Básicas
El principio KISS (Keep It Super Simple, o "Mantenelo súper simple") fue acuñado alrededor de 1960 por Kelly Johnson, el ingeniero principal de Lockheed, empresa que fabricaba aviones.
Johnson le entregó a su equipo de ingenieros un puñado de herramientas básicas y les dio una regla inquebrantable: el avión que diseñaran tenía que poder ser reparado por un mecánico promedio, en el medio de la pista y usando únicamente esas herramientas.
Si el motor era una obra de arte de la ingeniería pero requería herramientas ultra especializadas o un doctorado para entenderlo, el avión era inútil en condiciones reales.
El código se lee más de lo que se escribe
Esta misma filosofía aplica a la arquitectura web. Escribir código complejo es fácil; lo difícil es mantenerlo.
Tenemos que recordar que el código suele leerse muchas más veces de las que se escribe. Si armamos un sistema tan enredado que solo nosotros lo entendemos en el momento de programarlo, estamos creando un riesgo a futuro.
Dentro de seis meses, cuando haya que arreglar un bug urgente a las tres de la mañana, no vamos a querer descifrar un rompecabezas lógico. Vamos a necesitar un código simple y predecible.
La verdadera elegancia
Aplicar el principio KISS significa tomar decisiones conscientes:
- Si podemos resolver un problema con un simple
if, evitemos forzar un patrón de diseño complejo. - Elijamos nombres de variables que expliquen exactamente qué hacen, en lugar de abreviaturas crípticas.
- Dividamos funciones gigantes en tareas pequeñas y fáciles de probar.
La verdadera maestría en nuestra industria consiste en tomar un problema de negocio difícil y resolverlo con un código simple, limpio y hasta "aburrido". Un código tan claro que cualquier persona del equipo pueda leerlo y modificarlo a la primera.
