Ing. Luis Javier Chavarría | Administración de Tecnologías de Información | TEC | lchavarria@itcr.ac.cr

La formación de competencias de programación en el ámbito académico de nivel técnico o universitario debe considerar esfuerzos para llamar la atención de profesores y estudiantes sobre el tema de los olores de software.

La opacidad, entendida como la dificultad para leer y entender líneas de código; la repetición innecesaria producto de duplicar líneas de código en vez de promover su reutilización, son solo dos ejemplos de olores de software. Estos deben ser conocidos y entendidos por quienes participan del proceso de formación de los estudiantes.

La presencia de olores de software en el ámbito académico resulta relevante por cuanto el ejercicio de formación excluye las actividades de mantenimiento del ciclo de vida del software y es allí donde la presencia de olores se convierte en un problema que puede producir efectos negativos como aumentar el costo y retrasos en las entregas de los proyectos.

En la actualidad, la actividad de programación de aplicaciones de software exige que, quienes llevan a cabo la programación, tengan presente que temprano o tarde, su código será sujeto de mantenimiento producto de extensiones o cambios en los requerimientos del negocio.

Los olores de software son indicadores que apuntan y presagian que, la falta de atención a problemas de diseño, puede causar dificultades en la evolución y mantenimiento del software”.

De forma resumida, algunos de los olores básicos que provocan los síntomas de un diseño pobre son:

• Rigidez: el diseño es difícil de cambiar.
• Fragilidad: el diseño es fácil de romper.
• Inmovilidad: el diseño es difícil de reusar.
• Viscosidad: es difícil hacer lo correcto.
• Complejidad innecesaria: se incorporan características que no agregan valor al negocio.
• Repetición innecesaria: copiar y pegar resulta una acción problemática.
• Opacidad: el diseño y la codificación son difíciles de leer y entender.

La presencia de olores puede pasar una cara factura a las compañías que hacen uso de software para apalancar sus operaciones. Desde 1950 y hasta la fecha, las compañías han venido incrementando los porcentajes de personal dedicado a labores de mantenimiento de software (cerca de un 80%).

Esta tendencia ejerce presión sobre las actividades de mantenimiento de software. Las dificultades encontradas, producto del mantenimiento, pueden convertirse en una situación problemática para las empresas que apuntan a responder, de forma oportuna, a las necesidades cambiantes de sus clientes y usuarios.

Este artículo busca llamar la atención de los diferentes actores de la academia y la industria sobre los olores del software. Un olor, se puede definir, como situaciones donde ciertas características del código hacen que sea difícil o problemático su entendimiento, mantenimiento y pruebas.

Lo anterior, tiene una connotación primordial en el ámbito académico de formación de competencias de programación, esto, debido al limitado enfoque de construcción de aplicaciones que excluye parcial o totalmente las labores de mantenimiento.  El estudiante debe comprender que el ejercicio académico de construcción de software, conlleva actividades más allá de la entrega de una tarea o proyecto programado. Los proyectos programados de un curso, difícilmente son retomados en cursos posteriores para su correspondiente actualización y mantenimiento. Por otro lado, en el ejercicio laboral, la programación  obedece al cumplimiento y satisfacción de requerimientos del negocio que, implican además, tareas de puesta en producción, operaciones,  monitoreo y mantenimiento entre otras.

Adicionalmente, otro aspecto a considerar sobre las labores de mantenimiento de código es la participación de terceros diferentes a quienes realizaron la construcción del software.

Si la programación tiene olores, la labor de mantenimiento se verá comprometida. De ahí la importancia de programar evitando los olores desde un principio”.

Los olores del software

Las actividades de mantenimiento de software podrían resultar onerosas si el código presenta síntomas de un diseño pobre. Por ello es importante ahondar sobre cada uno de los olores citados:

• Rigidez: es la tendencia que tiene el software que dificulta realizar cambios. Incluso cambios simples podrían volverse complejos, es decir, realizar una modificación sencilla podría implicar una cascada de cambios a través de toda la aplicación.

• Fragilidad: es la tendencia que posee una aplicación de romperse en muchos lugares cuando se realiza una modificación. La fragilidad está íntimamente ligada con la rigidez. Pueden existir partes del software que nadie quiera cambiar por temor a lidiar con eventos inesperados.

• Inmovilidad: este síntoma se refiere a que existen partes de una aplicación que podrían ser reutilizadas en otros sistemas, pero el esfuerzo y riesgo de separarlos del sistema original son muy grandes.

• Viscosidad: cuando un desarrollador se enfrenta a un cambio, existen varias formas de hacerlo: las que preservan el diseño y las que no, es decir, la forma correcta y la incorrecta. La viscosidad de una aplicación o un de un diseño se presenta cuando implementar un cambio de la forma correcta es más complicado que hacerlo de la forma incorrecta.

• Complejidad innecesaria: cuando el diseño contiene elementos que no aportan valor y se convierten en candidatos a ser código muerto.

• Repetición innecesaria: este olor se refiere a estructuras repetitivas que se podrían unificar en una sola. El recurso desmedido de copiar y pegar tiene implicaciones negativas en el ámbito de la programación, esto favorece la posible proliferación de líneas de código idénticas o casi idénticas a lo largo del código.

• Opacidad: es la tendencia que tienen las aplicaciones que dificulta leerlas y entenderlas.

Para quien realiza la programación inicial, el código puede parecer sencillo y fácil de entender. La persona conoce su código (en ese momento) y sabe cuáles son las posibles implicaciones producto de un cambio. Con el pasar del tiempo, el código puede ser manipulado y modificado por diferentes actores que imprimen su estilo personal. Dichos cambios pueden provocar una mezcla compleja de variaciones y asunciones que pueden arriesgar la estabilidad de una solución de software.

El ciclo de vida del software

En el ámbito académico la vivencia del ciclo de vida de las soluciones de software es un tanto diferente a la realidad experimentada en el mundo laboral.

En la academia los estudiantes reciben una especificación de tarea programada, tienen un tiempo para desarrollarla, realizan actividades de análisis, construcción y pruebas y finalmente obtienen una nota. Las actividades mencionadas no pretenden abarcar la totalidad de las posibles variaciones que se pueden presentar, incluye solamente las actividades mínimas presentes en cualquier proyecto de programación académico.

Dependiendo del tipo de curso, por ejemplo, uno relacionado con Ingeniería de requerimientos, los estudiantes podrían completar, además, tareas relacionadas con la elicitación y validación de requerimientos.

Otro aspecto que vale la pena destacar es la conformación de equipos de trabajo para completar el proyecto programado. Generalmente, los equipos se conforman con dos o tres estudiantes que presentan afinidad para trabajar en equipo. El proyecto programado, se realiza entonces, en un ambiente controlado donde los diferentes actores deben efectuar la programación que responda a la especificación planteada. Una vez finalizado el tiempo de entrega, el profesor recibe las tareas, se llevan a cabo actividades de validación y revisión y finalmente se obtiene una calificación. De tal manera que el ciclo de vida de la tarea programada termina en el momento de recibir la calificación.

Además, difícilmente se retoma la tarea en cursos posteriores para su correspondiente mantenimiento producto de los cambios en la especificación inicial.

Por otro lado, el ciclo de vida de las soluciones de software en el mundo laboral, tiene un matiz un tanto diferente. Los requerimientos que dan origen a una programación no son estáticos, cambian de forma gradual según los cambios y necesidades de usuarios y clientes. Esta necesidad de actualización y mantenimiento produce la principal diferencia con relación al ciclo de vida de las tareas programadas en el  ámbito académico. En este caso, vale la pena destacar las actividades de puesta en producción y mantenimiento de la solución de software. La puesta en producción conllevará actividades de implantación, configuración y monitoreo de la disponibilidad de la solución de software.

El mantenimiento, por su parte, puede responder a cambios en regulaciones nacionales o internacionales, extensión de los requerimientos iniciales, corrección de defectos, migraciones, reingeniería, y optimizaciones entre otros.

Adicionalmente, los equipos que tienen participación en la creación de una solución de software pueden ser interdisciplinarios, por ejemplo: analistas de requerimientos, diseñadores, programadores, arquitectos de TI, usuarios de negocio, gestores de calidad, oficiales de proyecto, oficiales de seguridad de TI, gestión de la configuración e infraestructura.   Sumado al panorama anterior, quienes realizan las labores de soporte y mantenimiento de las soluciones de software podrían ser equipos distintos.

La vivencia de los ciclos de vida, actividades más, actividades menos, resulta ser diferente en el ámbito académico y en el mundo laboral. Esto no significa que los estudiantes conozcan parcialmente el ciclo de vida de las aplicaciones, significa que la experiencia en actividades como la puesta en producción y el mantenimiento es escasa o nula.

En la industria, entre el 60% y el 80% de todo el esfuerzo invertido en software se gasta después que se entrega al cliente por primera vez.

Lo anterior, debe llamar la atención de los diferentes actores del ámbito académico para hacer consciencia sobre la necesidad de tomar acciones para evitar los olores del software. Se debe promover que el diseño y programación de soluciones de software que no sean rígidas o frágiles. Temprano o tarde, el código inicial de una solución de software será sujeto de mantenimiento. La actividad ingenieril no finaliza cuando se obtiene una calificación, aunque así sea en el mundo académico.

Conclusiones

Las principales conclusiones que se derivan de la construcción de este artículo son:

1. El código subyacente a una tarea programada no solamente debe funcionar, debe exhibir todas las acciones que correspondan con la mitigación de los olores mencionados. Con ello se favorecerán las actividades de mantenimiento.
2. La calidad del software va más allá de una validación de la funcionalidad. Debe asegurarse, además, el cumplimiento de normas para garantizar una labor de mantenimiento menos dolorosa y costosa.
3. La sensibilización y socialización del tema de olores de software en etapas tempranas del proceso de formación de competencias de programación, puede convertirse en un elemento diferenciador de los egresados.
4. Las actividades de mantenimiento de software están cobrando más relevancia en la industria mundial.
5. Un diseño oloroso va a provocar dificultades cada vez que se realicen actividades de mantenimiento.