Barrapunto

Sencillez como objetivo

Me he permitido ampliar el espectro de lo vertido en el libro para proporcionar un enfoque universal aplicable a cualquier solución tecnológica. Deseo mostrar cómo es posible implementar mucho de este trabajo más allá de su aplicación al mundo UNIX, al que concretamente se refiere Eric S. Raymond.

El diseño de un sistema implica en sí mismo un concepto difícil de tratar: Complejidad.

Un sistema, (sea operativo, de aplicaciones y hasta social) debe mantenerse lo más sencillo posible, tanto que le permita ser altamente eficaz pero lo necesariamente complejo para evitar convertirse en algo inútil.

¿Cuál es el problema con esto? La simplicidad es compleja. Es necesario un desarrollo amplio de ideas antes de proponer siquiera un diseño. Veamos un análisis al Capítulo 13 del libro.

Complejidad

Sabemos ya que no existe una metodología de programación definida, lo cual nos lleva a deducir que tampoco existe un método específico para el diseño conceptual de ningún sistema. Si a esto sumamos el hecho de que existen una gran variedad de sistemas, soluciones o aplicaciones que pueden ser creadas, el problema es mucho más complejo todavía.

Tenemos entonces que solamente la experiencia durante la definición y prueba de diversos procesos de diseño puede acercarnos a la sencillez buscada para solucionar el gran problema de la Complejidad.

¿Hacia dónde dirigirnos? Aún cuando las diversas referencias realizadas por programadores hacen posible una mínima relación al respecto, es prácticamente imposible establecer fórmulas para la integración de cada proceso, lo cual como es obvio, hace a cada problema único.

Sin embargo, es necesario establecer ciertas definiciones básicas acerca de nuestro problema a fin de poder tratarle.

Haremos pues, para facilitar el tema, distinciones verticales y horizontales entre los tipos de complejidad más comunes y las explicaré.

1. Actores de la complejidad

Fuentes de Complejidad:

Tipos de Complejidad:

2. Fuentes de Complejidad

2. 1. Tamaño del Código Base

Una de las tres fuentes de Complejidad es el tamaño del código, entendido como el número total de líneas de código usadas para la solución.

Veremos entonces que un sistema será más complejo en tanto mayor número de líneas de código contenga, por tal, será más difícil de mantener y el costo del ciclo total de desarrollo será más elevado.

2. 2. Complejidad de la Implementación

El nivel de Complejidad de la Implementación es el grado de dificultad que experimenta el programador al intentar entender un programa o la solución misma a un problema dado.

Es decir, la implementación requerida para la solución de un problema, debe tener un nivel de complejidad tal que sea posible abstraerse mentalmente y crear el modelo de la solución. Si esto es así, el diseño será sencillo y extremadamente útil y comprensible.

2. 3. Complejidad de la Interfaz

Los usuarios deberán decidir qué tan complejo o no es el sistema, por tal razón la importancia de realizar un análisis profundo que permita salir avante de esto.

Como hemos visto, es necesario tener siempre en mente una solución para estas tres fuentes de complejidad. No es posible atender en mayor grado una mientras se deja sin atención la disminución de Complejidad en la Interfaz, por ejemplo.

3. Tipos de Complejidad

En situaciones ideales, (donde se observen los mecanismos que he citado) la solución o material resultante del trabajo realizado bajo estos preceptos, será entregado al usuario final o implementado para sus funciones como un sistema poco complejo, cuyo perfil principal será su sencillez, elegancia y capacidad de perfeccionamiento.

Ahora que, en el supuesto de que esto no ha sucedido así, existen varios niveles o tipos Complejidad a los cuales debemos atenernos a fin de reducir el grado de afectación a nuestro sistema. Veremos ahora cuáles son los Tipos de Complejidad.

3. 1. Complejidad Esencial

Existen sistemas cuya Complejidad Esencial está dada por ellos mismos o por los requerimientos especiales de ese sistema.

En ocasiones no es posible llevar la Complejidad a tal grado que la pieza final cumpla con el perfil que mencioné arriba (Sencillo, Elegante, Perfectible). Cuando esto sucede, debe hacerse lo posible por reducirle complejidad a la complejidad, lo más importante aquí es, asegurarnos de que el sistema no fallará por un exceso de complejidad y que no será tan complejo que sea prácticamente imposible mantenerlo o actualizarlo en caso de ser necesario.

La premisa es pues, mantener un sistema lo menos complejo posible, si por la solución misma tiene que ser complejo -Complejidad Esencial-, manténlo sencillo.

3. 2. Complejidad Opcional

Otros sistemas pueden encontrarse en la siguiente situación: Ser o no complejos. La razón de esto es, que la complejidad de un sistema está dada por el objetivo que debe cumplir dicho sistema -Complejidad Esencial-. Esto puede ser cambiado si los objetivos del sistema son cambiados o modificados -Complejidad Opcional-.

3. 3. Complejidad accidental

Si tomamos como ejemplo uno de los sistemas anteriormente mencionados -Complejidad Opcional- nos encontraremos en una situación peculiar:

Alguno de ellos no estará realmente en la situación que nos parece que está, sino que ha sucedido que el sistema no ha sido diseñado atendiendo a las Fuentes de Complejidad de tal manera que dicho sistema no ha sido realizado con el mejor diseño para la función requerida.

Diseñar nuevamente o rediseñar este sistema nos significará haber encontrado un sistema de Complejidad Accidental.

Simplicidad y término

Como hemos visto, uno de los pilares de la programación en UNIX, que debe ser aplicado a la programación en general, es el mantener nuestro sistema lo más sencilo posible.

Para terminar quiero hacer hincapié en el hecho de que muchas de las normas usadas en materia de programación, pueden ser usadas en otras áreas en materia de TI.

Existen para ello ciertos procesos que representan un gran avance para crear un entorno mucho más homogéneo y ventajoso para países en vías de desarrollo que pueden usar esto como un detonante para mejorar sus procesos productivos y conseguir un mercado interno estable que pueda, a mediano plazo, representar un beneficio económico para su sociedad.

Edgar Hernández Zúñiga.