Regla N°10 de la Ingeniería de Software: Si no es sencillo está mal hecho

El desarrollo de un software tiende a complicarse… a complicarse mucho. Se complica sacar el proyecto a tiempo, se complica las relaciones con el equipo de trabajo, con los proveedores o con los recursos. Debemos mantener esa complejidad bajo control, teniendo en la mente que todo lo que hagamos cumplir la regla "Si no es sencillo, está mal hecho".

La sencillez muchas veces se confunde. Sencillez no quiere decir fácil, es casi siempre lo contrario. Es difícil hacer las cosas sencillas. Casi siempre invertir en sencillez es un proceso costoso al principio y ventajoso al final del proyecto. El objetivo de esta regla es conseguir sistemas que estén guiados por la sencillez.

Para considerar un sistema sencillo debe cumplir las siguientes características:

• Sencillo de entender.
• Sencillo de explicar.
• Sencillo de mantener.

Algunos consejos para conseguir sencillez son los siguientes:

• Usa programación orienta a objetos: No veas un sistema como un flujo que va desde un punto ‘A’ a un punto ‘B’, sino como entidades que se relaciones entre ellas, e intercambian información.
• Cada vez que uses una sentencia if, preguntante si no está organizando el código para evitar usar herencia (donde cada parte de if y el else debiera ser una clases hija con determinadas características).
• Usa patrones de software: Son formas comprobadas de resolver determinados problemas, son extensamente conocidos, y son válidos tanto para incorporarlos en nuestros sistemas, como campo de estudio acerca de su sencillez.
• Vuelvo a hacer: La primera vez que resolvemos un problema posiblemente no sea de la forma más sencilla posible, sin embargo ya tendremos una imagen clara del problema, si no estamos convenidos que la solución es lo suficientemente sencilla, es mejor rehacerla con la experiencia que ya tenemos. El problema de la complejidad es que crece como una bola de nieve, por eso es mejor rehacer partes de las que no estamos seguros de su sencillez.
• Enfócate en hacer módulos que hagan muy pocas cosas pero que lo hagan muy bien.
• Reúsa código: Casi todos los entornos y lenguajes de programación, como Java, Ruby o .NET, tienen repositorios de librerías, muchas excelentes, que resuelven muchas problemas comunes. Es bueno conocerlas y usarlas.
• Pero no hagas tu código dependiente de librerías externas, encapsula apropiadamente las librerías para sea sencillo su reemplazo en caso que sea necesario.
• Hablando de patrones, usa el patrón fascade (fachada), dicho patrón encapsula en funcionamiento de sistemas complicados, exponiéndolos con una interfaz mucha más sencilla. Este patrón es extremadamente útil cuando nos comunicamos con sistemas viejos, librerías en otros lenguajes o simplemente con elementos que no son sencillos, ni claros, pero no podemos modificarlos, ya sea porque no tenemos el código fuente, o porque se sale del ámbito de nuestro desarrollo. El patrón fascade lo expondrá para nosotros de una forma sencilla, y la complejidad del código a consumir no será contagiada a nuestro código.
• Haz sistemas que no dependan de la implementación interna de otros sistemas (o módulos): Los sistemas se comunican por interfaces definidas, pero dichas interfaces debe ser independiente de sus respectivas implementaciones, es decir se debe poder cambiar la implementación sin afectar a las interfaces, ni a los sistemas con los que se consumen.