Desarrollo de software: El acoplamiento y su trascendencia en el mantenimiento del software

El acoplamiento es un concepto teórico que tiene consecuencias fatales en el mundo real. Un programa con alto nivel de acoplamiento es un programa muy difícil (y en consecuencia) costoso de mantener, en consecuencia, un software con un acoplamiento elevado tiene una deuda técnica también bastante importante.

No tener en cuenta el acoplamiento cuando se desarrolla es caer en el reverso tenebroso de la fuerza, lo mismo resulta más sencillo no tener que pensar en eso cuando se codifica, además no requiere de personal más cualificado (hacer las cosas bien para luego hacer que las cosas sean más sencillas necesita de un esfuerzo y por tanto no es nada trivial). Como ya comenté en un artículo anterior, programar pensando en que no se va a tener que volver a tocar el código es vivir ajeno a la realidad de lo que es el desarrollo de software y el ciclo de vida de los sistemas de información. ¿Puede pasar que no se tenga que tocar? Sí, pero, ¿realmente lo puedes asegurar?, ¿qué te dice tu experiencia?. Cierto es que puedes pensar: «bueno, al final le tocará el marrón a otro», pero ¿y si al final te termina tocando a ti o a algún compañero?.

Un software fuertemente acoplado es una caja de sorpresas cuando te pones a realizar tareas de mantenimiento, lo más probable es que cuando tapes un agujero se abran dos. Al final se conseguirá sacar el mantenimiento adelante, pero con un esfuerzo, desgaste y coste bastante importante.

El uso de frameworks de desarrollo supone un primer paso para reducir el acoplamiento, pero el uso de este tipo de estrategias por sí mismas no aseguran nada, ya que aunque se «deleguen» determinadas tareas en ellos, al final las «tareas de bajo nivel» residen en el software que se implementa y que el software esté más o menos acoplado depende de las buenas prácticas, conocimientos y experiencias del programador.

A los modelos de clases no se les suele prestar demasiada atención ya que una vez obtenidos los requisitos, construido el modelo de datos y consensuada la interfaz parace que lo demás no tiene demasiada importancia, sin embargo, los modelos de clases sí que permiten ver (por lo menos a alto nivel) situaciones de acoplamiento y tomar decisiones antes de codificar que pueden reducir esta métrica. Evidentemente requiere un esfuerzo y hay que sopesar también en función de las características del sistema si se realiza ese estudio o no, habrá situaciones en las que puede merecer (y merecerá) la pena y otras en las que no (aplicaciones relativamente simples).

Una sistema de información sin mantenimiento

Un sistema de información puede subsistir sin mantenimiento, para ello se tienen que dar una serie de circunstancias:

– Ha pasado tiempo suficiente desde su puesta en producción para detectar y corregir la mayor parte de las incidencias que llegaron hasta esta fase, para subsanar las deficiencias funcionales y para incluir una serie de mejoras que no se tuvieron en cuenta durante el proceso de construcción. Este tiempo suficiente va a depender mucho de lo grande que sea el sistema, de su tecnología y de la cantidad y complejidad de los evolutivos que se le hayan añadido.

– No se prevén cambios en los procesos que impliquen modificaciones en el código (puede haber cambios que no tengan por qué provocar tareas de programación, para ello ciertas partes del software deben ser parametrizables).

– Existe un buen conjunto de herramientas de administración que permiten resolver la mayor parte de las incidencias de los usuarios relacionadas con la utilización del software.

– El número de usuarios no es muy elevado y saben trabajar con la herramienta.

– Si el sistema de información interopera con otros y la comunicación es no transaccional y falla el intercambio de información es posible recuperar a través de las herramientas de administración el estado anterior.

– No se prevén cambios en el software de base (servidor de aplicaciones, versión de máquina virtual (en el caso por ejemplo de aplicaciones Java), sistema de gestión de base de datos, etc…).

El conjunto de circunstancias que he descrito se dan todas o en su inmensa mayoría en un buen número de sistemas de información que conozco y por lo tanto no requieren un servicio de mantenimiento contínuo, de manera que solo haría falta realizar estas tareas en caso de modificaciones funcionales, en cuyo caso pues acudiríamos a contratar el servicio correspondiente.

Pero también conozco sistemas de información que no cumplen con algunos de ellos y que necesitan un servicio de mantenimiento contínuo (entiéndase por contínuo, cuando los problemas que surgen se tienen que solucionar en un tiempo menor del que se tiene que esperar para realizar la contratación de los servicios de mantenimiento).

Si estas aplicaciones no tienen este tipo de servicios, provocará que con el paso del tiempo su uso se vaya degradando, de manera que los usuarios irán abandonando progresivamente su uso (lo rápido o lento que esto sucederá dependerá, además del grado de obligatoriedad del uso de la herramienta y de lo útil que le haya sido hasta ahora, del tipo de problemas que se vayan encontrando, de su capacidad de buscar caminos alternativos a los mismos dentro del programa y de la existencia de un centro de atención a usuarios capaz de darle soporte ante estas contingencias) y se irá degradando la calidad de las tareas que se realicen en la herramienta ya que generalmente los caminos alternativos, por propia definición, pasarán por saltarse algunos tipos de datos o tareas obligatorias.

PMD: Security – Array is stored directly

En Sonar, a la hora de revisar el cumplimiento de reglas, una de las que aparece muy frecuentemente en el software que nos entregan es la regla PMD «Security – Array is stored directly» que se produce cuando uno de los parámetros que aparece en la definición de un método, de un constructor o de un setter (es bastante frecuente que cuando los accesores son autogenerados por el IDE o por generador de código se produzca este tipo de incumplimientos, salvo que se haya tenido en cuenta previamente) es un array y en el interior del método se realiza una asignación de dicho objeto a otro (que no es local) sin realizarse previamente una clonación (se tendría lo que algunos denominan acoplamiento entre objetos por compartir direcciones de memoria).

Si no clona el objeto resulta muy peligroso, ya que el número de objetos que apuntan a las mismas direcciones de memoria aumenta y en consecuencia se incrementa la posibilidad de errores colaterales, los cuales además en estos casos no son siempre triviales de localizar.

Cita donde se define a los programadores

Siempre me ha sacado una sonrisa esta cita de autor desconocido (la pongo en inglés que es como normalmente me la suelo encontrar):

«Programmer – an organism that turns coffee into software».

Escribir los objetivos personales a mano en un papel

No sé a vosotros pero a mi me cuesta. Tengo muchas metas, muchos objetivos en la cabeza pero me da respeto coger un bolígrafo y ponerlos sobre un papel.

En muchos libros que he leído consideran una buena práctica hacerlo, ya que es como comprometerte realmente a conseguir algo y es ese compromiso el que se impregna en nuestro comportamiento y el que hace, casi sin querer, que nuestras acciones vayan dirigidas a su cumplimiento.

Precisamente por eso, porque me conozco, me pienso muy mucho poner lo que pretendo conseguir en un papel ya que cuando fijo objetivos soy demasiado perseverante, lo cual siendo una buena estrategia puede resultar agotador, sobre todo si se tarda en conseguir (si es que se logra).

En cualquier caso, me parece una buena estrategia hacerlo, sobre todo si se tiende a la dispersión de objetivos y/o a empezar muchas cosas sin terminarlas.

Una cita sobre la mantenibilidad del software que se desarrolla

La cita no tiene un origen claro, hay quienes la atribuyen a Martin Golding y otros a John F. Woods, en cualquier caso lo más importante en este caso es su contenido:

«Programa siempre como si el tío que finalmente vaya a mantener tu código sea un psicópata violento que sabe donde vives».

Detrás de esta frase hay algo muy claro y que me comentó no hace mucho un amigo y que reflejé en mi blog y es que es engañarse a uno mismo programar pensando en que después nadie va a tocar lo que estás codificando, por lo que en la medida de lo posible hay que intentar que el código sea lo más claro que se pueda y en general que lo que se desarrolla se haga pensando que después, muy probablemente, tenga que mantenerse.

La productividad y los entornos

Entornos productivos fomentan personas productivas y al revés sucede exáctamente lo contrario. Por supuesto que podemos encontrarnos con personas no productivas en entornos productivos y productivas en entornos improductivos porque como he dicho en muchas ocasiones, la productividad y la profesionalidad están dentro de cada uno.

Cuando uno tiene claro como funcionar el entorno juega un papel secundario (aunque por supuesto afecta), pero cuando no, el entorno es el que te lleva a la deriva. Esto se hace más marcado sobre todo en las nuevas incorporaciones al mundo profesional que no conocen otra cosa y que piensan para bien o para mal que lo que están viviendo es la realidad que existe en el resto de sitios.

Existe una confusión cuando se asocia entornos productivos a entornos de baja calidad laboral, no es así salvo que lo que uno espere en el trabajo sea precisamente no trabajar. Un entorno productivo es un entorno justo, un entorno donde no se te valora por estar más tiempo atado a una silla sino donde se te valora por tus resultados, un entorno donde se miden los progresos y tu aportación al conjunto. Eso no es baja calidad laboral sino totalmente lo contrario, es un mundo más objetivo donde crecen más quienes más lo han merecido, donde las reglas del juego son conocidas por todos y cada uno por su cuenta y riesgo decide qué camino tomar.

Por supuesto que estoy describiendo un entorno productivo ideal ya que es difícil alcanzar esa objetividad total, pero entre ese extremo y el otro creo que es preferible intentar acercarse cada vez a este.