Programar a ciegas

Dentro de las reglas para escribir software simple y robusto tenemos la regla de SOC cuyo acrónimo significa Separation of concerns. Esto se traduce como separación de intereses. Este término de ingeniería fue creado por Edsger Dijkstra en un artículo para indicar la necesidad de centrar la atención en aspectos específicos dentro de las distintas estructuras de manipulación de la información dentro del software. Esta separación de intereses dentro del software se puede aplicar a nivel de arquitectura del proyecto y a nivel de codificación de los métodos y funciones.

Arquitectura de intereses

A nivel de arquitectura debemos agrupar los distintos intereses dentro de módulos o microservicios. Cada módulo o servicio deberá encargarse de un aspecto del proyecto.

Se busca que cada módulo o microservicio sea independiente y tengan claras sus responsabilidades.

Dentro de la modularización del código se aplican patrones de diseño como MVC (Modelo vista controlador), MVP (Modelo vista presentador) y patrones de diseño similares. Esta forma de organizar el código nos permite diferenciar cláramente las clases relacionadas con el modelo de datos, la interfaz de usuario y la forma de presentar y manipular los datos en la interfaz de usuario. 

Aplicando estos patrones de diseño a la hora de modularizar nuestro código podremos realizar modificaciones en la interfaz de usuario sin necesidad de afectar al modelo de datos o a la lógica de negocio ya que las responsabilidades de cada parte del módulo están conceptualmente definidas.

Separación del código por intereses

Para separar el código por intereses se debe realizar un ejercicio de análisis observando desde el punto más alto de abstracción de nuestro proyecto, tanto en funcionalidad como en la información que se manipula, hasta delimitar la responsabilidad y relación entre las distintas clases y módulos del proyecto.

Con este esfuerzo se busca obtener las siguientes ventajas: eliminar la posible duplicación en la lógica de negocio, ampliar la capacidad de mantenimiento del proyecto, incremento de la cohesión entre clases y reducción del acoplamiento entre clases y módulos.

Una vez realizado este análisis se aplican distintos paradigmas de programación como la programación orientada a aspectos, arquitectura hexagonal, inyección de dependencias y la separación de métodos por responsabilidad.

Una de las reglas para escribir software simple y robusto que también podemos aplicar a otros aspectos de la vida es la regla de Demeter. Esto es lo que significa LOD: law of Demeter.

Esta regla se resume en el concepto de: no hables con desconocidos.

Dentro de la ingeniería de software esta regla representa al principio del mínimo conocimiento.

Este principio nos dice que una función o método X perteneciente a un objeto Y sólo puede llamar a otros métodos o funciones pertenecientes al objeto, un parámetro del método X, cualquier objeto creado dentro del método X o cualquier propiedad definida dentro del método X.

Esto establece que la comunicación del método X se limita al dominio de su objeto contenedor o al propio dominio del método X.

De forma más comprensible este principio nos permite escribir un método de forma que cualquier información que el método necesite consultar o manipular estará dentro del propio código del método o dentro del código de la clase que lo contiene. De esta forma podemos detectar fácilmente posibles errores o seguir el movimiento de la información que manipula ese método.

Otra de las reglas para escribir software simple y robusto es la regla KISS.

El acrónimo de KISS significa Keep it super simple (manténlo super simple). 

Esta regla indica que la mayoría de las aplicaciones funcionan mejor si se mantienen simples en lugar de complicadas; Esta regla busca que la simplicidad debe ser un objetivo clave en el diseño y se debe evitar la complejidad innecesaria.

Algunas soluciones para seguir esta regla es aplicar código limpio y utilizar algunos paradigmas para abordar la resolución de problemas como pueden ser el de divide y vencerás y las reglas de programación SOLID.

Siguiendo la regla de KISS crearemos un software estructurado en clases y módulos simples donde sea fácil localizar cada dato y función.

En el artículo sobre reglas para escribir software simple y robusto hablamos de 5 reglas para mantener la simplicidad. Una de estas cinco reglas y la más fácil de entender es la regla DRY cuyo acrónimo significa Don’t repeat yourself (No te repitas a ti mismo). Esta regla aparece por primera vez en el libro The pragmatic programmer.

Esta regla implica que cada pieza de conocimiento debe tener una representación única dentro del proyecto. Esto implica que no se deben repetir partes como la lógica de negocio en distintas partes del proyecto.

Esto reduce el código repetido en el proyecto y hace que nuestras clases y módulos sean más reutilizables.

Si no seguimos esta regla y tenemos elementos repetidos para hacer algún proceso del modelo de negocio, el día que tengamos que actualizar esa función o proceso deberemos invertir tiempo en localizar todas las partes donde se repite dicho proceso y actualizar el código.

Se considera que una aplicación software es robusta cuando puede seguir funcionando en condiciones adversas e impredecibles.

A la hora de crear un software robusto una de sus primeras reglas es hazlo simple. Desde su código, escribiendo limpio y legible, hasta su arquitectura utilizando patrones de diseño. Todo esto nos lleva a seguir un estilo de diseño simple a la hora de definir nuestro proyecto software.

La navaja de Ockham

La simplicidad en el software mejora nuestro proyecto en su ejecución y en su mantenimiento. Gracias a que su código es simple de leer podemos entender mejor su estructura y su funcionalidad y gracias a que la relación entre módulos, clases y funciones es simple la detección de errores o la incorporación de nuevas características es menos estresante.

Muchas ramas de la ingeniería buscan esta simplicidad debido a la idea del principio de economía o el principio de la navaja de Ockham.

Este principio dice que en igualdad de condiciones, la explicación más simple suele ser la más probable». Esto implica que, cuando dos teorías en igualdad de condiciones tienen las mismas consecuencias, la teoría más simple tiene más probabilidades de ser correcta que la compleja.

Las cinco reglas para mantener la simplicidad

Con la evolución y la historia de la creación de software han ido apareciendo una serie de reglas que nos ayudan a mantener la simplicidad dentro del diseño de nuestro software. En futuros artículos iremos viendo cada una de estas cinco reglas.