El Principio KISS: La Regla de Oro de la Simplicidad en el Código
En el desarrollo de software, nuestro mayor enemigo no son los bugs, ni los servidores caídos, ni los cambios de requerimientos. Nuestro mayor enemigo es la complejidad.
A menudo, cuando descubrimos un patrón de diseño nuevo o una función avanzada de un lenguaje, nos entusiasma tanto que queremos aplicarla en todos lados. Terminamos escribiendo código súper abstracto o resolviendo problemas en una sola línea (one-liners) simplemente porque técnicamente es posible. Pero la realidad de la ingeniería nos enseña que la complejidad innecesaria siempre pasa factura.
El Origen: Herramientas Básicas
El principio KISS (adaptado hoy en la industria como Keep It Super Simple, o "Mantenelo súper simple") fue acuñado en 1960 por Kelly Johnson, el ingeniero principal de Lockheed, la empresa que fabricaba aviones para el gobierno de Estados Unidos.
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 súper especializadas o un doctorado para entenderlo, el avión era inútil en el mundo real.
El Código se Lee Más de lo que se Escribe
Esta misma filosofía aplica exactamente a la arquitectura web. Escribir código complejo es fácil; lo difícil es mantenerlo.
Tenemos que recordar que el código se lee diez veces más de lo que se escribe. Si armamos un sistema tan enredado que solo nosotros lo entendemos en el momento en que lo estamos programando, estamos creando una bomba de tiempo.
Dentro de seis meses, cuando el sistema se caiga a las tres de la mañana y tengamos que arreglar un bug urgente, no vamos a querer descifrar un rompecabezas lógico. Vamos a necesitar un código tan simple y predecible que podamos arreglarlo medio dormidos.
La Verdadera Elegancia
Aplicar el principio KISS en nuestro día a día 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 testear.
La verdadera maestría en nuestra industria consiste en agarrar un problema de negocio increíblemente 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, entenderlo y modificarlo a la primera.
