Calidad en el diseño y/o programación de Sistemas.

Actualmente, en mi posición laboral, tengo que estar interactuando con muchos desarrolladores que están comenzando su carrera, así como experimentados. Y en la mayoría me encuentro con la poca calidad en el diseño y/o implementaciones de apis. Tengo que reconocer que suena engreído de mi parte el estar criticando el trabajo de otros, sin embargo, como punto a mi favor debo decir que no se necesita ser un experto para identificar un mal diseño. Para empezar debo de explicar desde mi punto de vista que es un buen diseño, que es esto, bueno: un buen sistema está bien diseñado si es fácil de comprender, leer o interpretar, fácil de modificar (sin que tenga de afectar miles de otras interfaces) y sobre todo fácil de reutilizar. ¿Fácil, no?, pues ¡no!, en la mayoría, como lo he comentado, me encuentro con todo lo contrario.

En esta entrada detallaré de forma breve los principios que debe de seguir un buena calidad en el diseño de sistemas.

En primer lugar me acurdo de un término utilizado en la universidad: diseño de hule, y como todo, poco después en la práctica entendí que significaba eso; desde mi perspectiva un mal diseño tiene código de hule aplicado por todas partes, el cual cuenta con las siguieres características:

• Cuando dentro de un Sistema, al tratar de modificar un servicio se tiene que modificar otras interfaces o apis en cascadas para poder adaptar el nuevo cambio.
• Cuando al realiza un cambio dentro del Sistema, este afecta en otros lugares desconocidos dentro del código.
• Cuando no se puede fragmentar el código en servicios con la finalidad de reutilizarlo.
• Por último, cuando se tiene repetición de mismos fragmentos del mismo  código en todos lados con una sola variante.

Si tu sistema cuenta con alguno de estos puntos, entonces califica como un mal diseño. ¿Y a que nos lleva esto? pues esto nos lleva a otro término utilizado en la jerga de la programación: código espagueti. Al estar dentro de este punto tu sistema no está del bien claro detallando un aspecto de una maraña de código poco claro y poco mantenible, rompiendo las ventajas que proporciona la programación orientada a objetos y sobre todo el polimorfismo. 

Para llevar un buen diseño dentro de tu sistema, este deberá de seguir los siguientes principios que sostiene la programación orientada a objetos.

• Una clase no debe de gestionarse para realizar o resolver muchas cosas a la vez: cuando una clase conoce o da soporte para resolver más operaciones de las que debería, entonces deberás de pensar y dividir tu clase en operaciones más concretas.
• Todo servicio deberá ser abierto para permitir su extensión, pero cerradas a la modificación: ¿qué dice? bueno suena un poco confuso pero tratare de explicarme. Tu sistema deberá de permitir el poder cambiar el entorno de un servicio en particular, sin cambiar el servicio en si. Y es aquí en donde entra una de las grandes promesas del polimorfismo. ver Wikipedia-Polimorfismo 
• Las sub-clases deberán de ser sustituibles por sus clases padres: esto nos lleva a programar y a diseñar de una forma mas abstracta. De esta manera, las clases padre (interfaces) no deberían de conocer o proporcionar más información de lo que deberían. Dejando a las especializaciones a las sub clases. NOTA: como consejo de ser posible siempre que herede hágalo de una clase abstracta, en general las clases abstractas o interfaces cambian mucho menos que sus clases concretas. 

Siempre tenemos puntos a mejorar, desde mi punto de vista el desarrollar y diseñar sistemas de información tiene que ver con practica, mejora continua y sobre todo con las buenas practicas (esto incluyen los patrones de diseño). Pero todo lo anterior se tira a la basura si no se respeta lo antes mencionado ya que son las bases para una buena arquitectura.