INGSOFT: Keep It Simple, Stupid (KISS)

INGSOFT

El principio KISS es uno de los principios de programación y diseño más conocidos y a la vez más difíciles de seguir. Como supongo que sabéis, KISS dice que «el objetivo principal de todo diseño debe ser la simplicidad».

O mejor dicho, evitar en todo lo posible la complejidad innecesaria. Claro, uno piensa, «qué bien!, complejidad innecesaria, se ha matao el colega que lo ha pensado». En realidad el principio se refiere al modo en el que debe enfrentarse la solución de los problemas más que al resultado en sí mismo.

Una de las causas que lleva a código y diseños complicados tiene que ver con la tentación de añadir características nuevas a nuestros desarrollos sólo porque «es fácil hacerlo» sin considerar los efectos colaterales que eso seguro va a implicar en el sistema completo. Para alguien (incluso tú mismo unas semanas o meses después) necesite entender cómo funciona el programa (para añadir una funcionalidad o arreglar un bug) puede llevarle mucho más tiempo si el que lo escribió no tuvo el suficiente criterio y cuidado en «mantenerlo sencillo».

Eso de añadir «características innecesarias» te sonará a repetido si has leído mi post anterior pero es que tanto YAGNI, como KISS, como muchos otros principios tratan una y otra vez a la misma cuestión: la creatividad descontrolada/desinformada es la raíz de todo mal.

La otra causa principal que lleva a código innecesariamente complicado son las prisas, la falta de tiempo. A veces es posible «arreglar el problema» haciendo un pequeño apaño, un parche, un hack-truco, en definitiva ejerciendo algo que habría sido el 8º pecado capital si Dios hubiera sido programador: el quick and dirty (Q&D). Por muy inofensivo que pueda parecer ese pequeño bloque if de 3 o 4 líneas en mitad de una función, las consecuencias acumuladas de su uso como forma de mantenimiento son devastadoras. La razón, muy simple: estás añadiendo lógica en una función que no fue concebida para eso. Ni el nombre, ni la documentación, ni el diseño se corresponden con el nuevo «poder» que le acabas de otorgar. Por tanto será difícil de encontrar, de depurar, de extender o generalizar.

KISS no implica que no se puedan hacer cosas sofisticadas. Lo que dice es que las piezas que forman el sistema deben ser fáciles de identificar, con responsabilidades bien definidas y con los mecanismos necesarios para que sea posible extender su funcionalidad escribiendo más código pero sin modificar el que hay. Hay muy buenas formas de conseguir eso, como por ejemplo la herencia, la sobrecarga y/o la aplicación de ciertos patrones de diseño (suponiendo que hablamos de OO). El conjunto debe ser lo más simple posible para el problema objetivo, pero obviamente eso no significa que tenga que ser trivial. Q&D es pan duro para hoy y mucha hambre para mañana, es la principal causa de la deuda técnica y el tiempo que crees ahorrar hoy lo pagarás multiplicado por 10 mañana o la semana que viene.

Cada nueva «feature», cada nuevo caso de uso implica un cambio en el diseño (no tanto arreglar un bug si es pequeño). Si no se tiene en cuenta, el diseño se ensucia y distorsiona rápidamente. Hay que replantearse el diseño y hacer los cambios necesarios para que todo encaje, pero ahora, no luego. No hablamos de rediseñar la aplicación entera, muy malo tendría que ser el diseño si eso ocurre, hablamos de refactorizar. Resumiendo: añade y refactoriza. Sí, esto suena a TDD, verdad? En efecto, el ciclo es:

  • Escribe el ejemplo (la prueba),
  • Añade o cambia lo mínimo necesario para que la prueba funcione y
  • Refactoriza.

Vale, lo admito, todo esto era una treta para llegar a TDD, se tenía que descubrir tarde o temprano… Pero lo que pretendo es demostrar que TDD no es un método para escribir pruebas, es mucho más. TDD es una forma razonable y realista de hacer software (la más lógica para mi hasta el momento).

La mayoría de los principios de programación y diseño encajan perfectamente con TDD, porque TDD ha sido la consecuencia inevitable de entender y aplicar la naturaleza del proceso de fabricación de software. En otros posts volveré con esto, pero os dejo un libro útil para empezar (y en español):

La segunda parte del libro es el desarrollo de un ejemplo realista, puesto que los autores pretenden demostrar (o eso me parece a mi) que TDD funciona realmente y no es solo palabrería barata (tan común en ingsoft). Si eres de los escépticos (normal al empezar) está bien, pero en cuanto entiendas la dinámica de TDD te puede resultar pesadito. La primera parte está muy bien en cualquier caso y aconsejo su lectura, no hace falta leerla dos veces como dice el autor Eye-wink aunque ciertamente yo ya era un convencido de las pruebas (por el camino difícil, es decir, «innovando» en lugar de copiar) antes de acercarme a este libro.


MENOS ES MÁS
LA CREATIVIDAD ES LA ESCLAVITUD
LA EXPERIENCIA ES LA FUERZA


Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de magmax

La pastilla roja.

David, tengo que decir que, con este artículo, me has dado la pastilla roja.

Me llamó la atención, y decidí echar un ojo al libro que propones sobre TDD. Lejos de ser una maravilla, ese libro tiene dos cosas: es ameno y es sencillo de entender. Un buen punto de comienzo para TDD y ATDD.

Hace 5 días que comencé a leerlo y te doy la razón: no es para leerlo dos veces, aunque sí es posible que interese repasar un par de capítulos.

Para los que no lo hayan leído aún, un brevísimo resumen podría ser que TDD consiste en tres pasos:

  1. Crear un test de lo que queremos hacer
  2. Implementar con código mínimo una solución que valide el test
  3. Refactorizar tests y código.

Y esto, claro está, dentro de un proceso iterativo en el que vamos añadiendo características.

A veces esta refactorización es muy sencilla. Otras es terminantemente compleja, y se apoya en numerosos patrones -que yo, por desgracia, aún no tengo totalmente asimilados y me cuesta encontrar-.

Recomiendo que dediquéis 10 minutos de vuestro tiempo a ver este vídeo. Está en ruby, pero es tan simple y lo que quiere hacer es tan obvio, que se entiende sin problemas.

Yo, por mi parte, he descubierto una manera de programar completamente diferente a la que he hecho hasta ahora, y que pienso poner en práctica lo antes posible.

Aunque, de momento, necesito un poquito de entrenamiento...

Actualización: La idea original estaba hecha en java, pero es más molón ver el vídeo (aunque recomiendo echar un ojo a ambos).

Miguel Ángel García
http://magmax.org

Imagen de david.villa

Gracias miguel por tomarte en

Gracias miguel por tomarte en serio mi post. Me doy por contento por haber conseguido remover la «conciencia profesional» de al menos una persona. Lamentablemente en mi «vecindario» encuentro una dura oposición a todo lo que implique hacer las cosas de otra forma (es decir, todo aquello que no sea el caos absoluto) pero bueno, supongo que base de hostias todos acabaremos aprendiendo... o no.

No soy portavoz de ningún colectivo, grupo o facción. Mi opinión es personal e intransferible.

Imagen de magmax

Curiosidad...

Hola.

No sé por qué, aunque ya había leído el epígrafe que has puesto, pero hoy me ha llamado más la atención. El caso es que hace poco estuve leyendo el Cuento de la incomodidad: el emprendedor, el técnico y el gestor, y me he dado cuenta de las similitudes entre este cuento y el epígrafe.

"Menos es más": en cuestión de cuentas manda el gestor, que quiere tener el producto terminado lo antes posible. Nada de andarse por las ramas: lo que se ha pedido y para ayer.

"La creatividad es la esclavitud": El emprendedor, claramente. Charles Babbage no llegó a terminar casi ninguno de sus inventos, pero era muy creativo.

"La experiencia es la fuerza": Esta frase representa al técnico, ya que no hay manera de ser un buen técnico sin tener experiencia, y cuanta mayor experiencia se tenga, mejor es el técnico. Por muchos libros de programación que leas no serás un buen programador hasta que escribas programas.

Definitivamente, como bien dice el cuentecillo, mi opinión es que hay que llegar a un término medio entre estas 3 fuerzas opuestas para conseguir el equilibrio.

Respecto al resto del artículo, me interesa mucho el TDD, ya que he comenzado a ponerlo en práctica hace poco y debo decir que me va mejor desde entonces: menos dolores de cabeza, más seguridad en lo que hago, etc...

Miguel Ángel García
http://magmax.org

Imagen de david.villa

Interesante análisis, no lo

Interesante análisis, no lo había pensado, pero la verdad es que encaja bastante bien, salvo por un pequeño detalle.

«Menos es más» no es solo una cuestión de dinero o de tiempo. «menos es más» resume la esencia de los principios de diseño que he contado (KISS y YAGNI) e incluso me atrevería a decir que del mismo TDD o el agilismo. Trata principalmente de economía de esfuerzo (al mantener, probar y extender) aunque hacer algo pequeño, simple y controlado puede requerir más esfuerzo en las primeras fases (aunque sea amortizado de sobra después), algo así como esa famosa carta que empezaba con «siento no haber tenido tiempo para escribirte una carta más corta».

Saludos

No soy portavoz de ningún colectivo, grupo o facción. Mi opinión es personal e intransferible.

Imagen de magmax

Menos es más.

Por supuesto, como indiqué en la explicación, un "gestor" lo que quiere es que te ajustes a lo estrictamente necesario (o menos, para luego echarte la bronca) y que lo tengas ayer. Es justamente eso: economía, ya sea de dinero, tiempo o esfuerzo.

Miguel Ángel García
http://magmax.org