KISS = Keep It Simple Stupid!

Este principio (KISS) nos dice que en el desarrollo de software, siempre debemos optar por la solución más sencilla (que no por ello es la más fácil de implementar), evitando cualquier indicio de complejidad innecesaria.

El ejemplo máximo de sencillez es la interfaz de usuario de la aplicación con más éxito de la historia, Google: ¿que puede ser mas sencillo que un cuadro de texto y un botón para ejecutar la búsqueda? Otra cosa es la algoritmia y tecnología que hay detrás de estos botones para que todo funcione como se espera, pero el diseño de la aplicación es indiscutiblemente el más sencillo posible.

El principio KISS es fundamental para el diseño de interfaces de usuario, sin olvidarnos del modelo lógico que subyace debajo de los controles y ventanas.

También se aplica al diseño arquitectónico de la aplicación. El diseño tiene que tener tantas capas y componentes como sea necesario para cumplir los requisitos pero nada más. Esto es tan evidente cuando se escribe, como difícil de conseguir. A la hora de diseñar tenemos la tentación de añadir capas y componentes "por si acaso", para hacer el sistema "flexible" y "adaptable" y terminamos por tener una aplicación llena de modulos, componentes y clases que no tienen una función muy clara, y que en lugar de proporcionar la flexibilidad prometida, son un obstáculo a la hora de encontrar errores, optimizar el rendimiento o simplemente evolucionar el sistema. (está relacionado con el principio YAGNI, del que hablaré otro dia)

En un nivel más bajo, en el código, también es importante mantener las ideas claras y el código sencillo. Un código complejo, abigarrado, con métodos de cientos de líneas, condiciones crípticas dentro de los if() o while(), bucles anidados con varios niveles... son un indicador de código de mala calidad, resultado del trabajo descoordinado de varios desarrolladores en diferentes momentos de tiempo, sin una comprensión completa del propósito de dicho código. Por eso es tan importante dedicar tiempo suficiente a la refactorización periódica del código, para mantenerlo limpio, estilizado, coherente, ligero y eficiente.

Normalmente la sencillez es síntoma de que se están haciendo bien las cosas: cuando vemos una competición de esquí, muchas veces podemos distinguir al esquiador bueno por sus movimientos sencillos y sin brusquedades, lo hace "fácil" (aunque esa facilidad aparente sea fruto de miles de horas de entrenamiento). Igual pasa en otros deportes de técnica compleja como el golf, la gimnasia rítmica o incluso el fútbol.

Volviendo al software, un diseño tiene que ser tan simple como se pueda, y no más.

Sorprendentemente, hacer las cosas sencillas cuesta más trabajo que hacerlas complicadas. Normalmente un diseño o código suele ser fruto de varias tentativas y aproximaciones hasta que logramos una solución que cumple todos los requisitos. Inicialmente nos preocupamos de que sea eficaz (es decir que haga lo que tiene que hacer) y vamos añadiendo elementos hasta que lo conseguimos. El paso hacia la sencillez es posterior y deliberado: consiste en examinar el diseño y simplificar y quitar elementos innecesarios hasta que ya no podemos quitar ninguno.

Blaise Pascal se despedía en una de sus célebres cartas con una disculpa: "Si hubiera tenido más tiempo hubiera escrito la carta más corta". Lo mismo digo: ojala fuera capaz de decir lo mismo con menos palabras.

Realidades y Mentiras sobre la Ingeniería del Software

Leo en este blog una referencia a un libro que leí hace tiempo Facts and Fallacies about Software Engineering, y que creo que resume perfectamente muchos de los problemas que se ven a diario desarrollando software:

Interesante recordatorio.

KISS, DRY, YAGNI...

La comunidad de defensores de los métodos ágiles de desarrollo es muy aficionada a los acrónimos crípticos. Debe ser una forma de reconocerse unos a otros, y de impresionar a los no iniciados en la materia... en cualquier caso, merece la pena ver lo que quieren decir, porque las ideas que hay detrás son muy interesantes en nuestra búsqueda del Software de Calidad

DRY = Don't Repeat Yourself

Viene a decir que cada trozo de información, idea, concepto, decisión de diseño, dato debe estar expresada al menos en un sitio y como mucho en un sitio.

Un ejemplo evidente es la creación de un método para "formatear" coordenadas geográficas, es decir pasar de un double lat = 41.32242423 a un String latStr = "41º 19' 20,73"". Es lógico expresar ese algoritmo una sola vez en el código y utilizarlo desde todos los puntos de la aplicación en los que se necesite realizar esta conversión.

Parece una obviedad, y además, por suerte, este principio es una de las cosas que primero se enseñan en las escuelas de informática, por lo que a priori nadie se atreve a discutirlo... otra cosa es la aplicación real que se hace de él y lo fácilmente que lo olvidamos muchas veces.

Ventajas de aplicar este principio:

• Menos trabajo inicial: nos ahorramos repetir código que ya tenemos desarrollado (o datos, o documentación, o lo que sea)
  
• Claridad: es más fácil entender la aplicación si cada cosa está en un solo sitio
  
• Coherencia: si algo está expresado en dos lugares diferentes, es casi seguro de que habrá variaciones. Incluso si inicialmente una de las instancias es resultado del copy&paste, con el tiempo serán diferentes, cuando alguien haga una modificación en una de las instancias y se olvide de la(s) otra(s).
  

Oportunidades para aplicarlo:

• Subrutinas, clases de utilidad, código, refactorización
  
• Datos
  
• Reglas de negocio
• Esquemas de la base de datos
• Planes de Prueba
• Sistema de Build de la aplicación
• Documentación

El libro The Pragmatic Programmer (altamente recomendable) es un perfecto tratado de cómo aplicar este principio de forma extensiva en muchos aspectos de un desarrollo de software.

Un entorno de desarrollo que lleva al extremo el principio DRY es Ruby on Rails. Merece la pena echarle un vistazo aunque solo sea por la interesante aplicación de ideas como "convención frente a configuración", "database migrations", "modelo/vista/controlador" y "los 3 entornos: desarrollo, pruebas, producción" y la aplicación obsesiva del principio DRY.

Violaciones frecuentes del principio:

Está comprobado: todos tenemos un sexto sentido para detectar violaciones de este principio. Muchas veces cuando estamos escribiendo código, creando un esquema de base de datos, introduciendo datos de prueba... tenemos la sensación de "esto ya lo he escrito antes", "seguro que esto lo tenemos ya por otro lado" , "debería crear un método común en lugar de hacer copy&paste" una especie de alarma interior que nos indica que lo que estamos haciendo no huele bien del todo.

• Copy & paste del código (tengo que probar la herramienta CPD Copy&Paste Detector a ver que tal... lo que he visto promete)
  
• Copy & paste de trozos de documentación
• El esquema de base de datos está en 3 sitios: en la documentación, en la BB.DD. y en las clases del código que acceden a la BB.DD.
• ¿se os ocurren mas?
  

Para próximos posts:

• KISS = Keep It Simple Stupid !

• YAGNI = You are not going to need it.

Software de Calidad

¿ Calidad Software = Software de Calidad ?

Desde hace unas semanas se ha creado en la empresa en la que trabajo un nuevo puesto: Gerente de Calidad Sw, que casualmente voy a ocupar yo mismo.

Desde estas líneas intentaré hacerme eco de todas aquellas iniciativas que emprendamos, los resultados observados, dificultades, sugerencias, etc que nos encontremos por el camino.

Hasta pronto!