Charla GSAS: Mejora tu arquitectura con el índice de madurez de la modularidad (MMI)

Compartir esta publicación

Durante la conferencia GSAS 2022 organizada por Apiumhub, la Dra. Carola Lilienthal presentó un interesante tema que había explorado a fondo en su libro, Sustainable Software Architecture, y también en un capítulo del libro Software Architecture Metrics: el Índice de Madurez de la Modularidad (MMI). Esta charla arrojó luz sobre la importancia de esta métrica para evaluar la modularidad de la arquitectura de software, y su potencial para mejorar la sostenibilidad y mantenibilidad de los proyectos de software.

¿Buen legado?

A pesar de percibirse comúnmente como maligno, el código heredado puede seguir considerándose un buen proyecto si tiene una larga vida útil, que justifique la inversión inicial, y si sus costes de mantenimiento y ampliación se reducen al mínimo. De hecho, un buen proyecto heredado se caracteriza por su facilidad de comprensión, modificación y ampliación, lo que lo convierte en un activo valioso para la organización.

resolving technical debt in software architecture 3 2048

¿Cómo empleamos nuestro tiempo?

Comprensión del código 70%

Resolución de problemas 20%

Escribiendo código 10%

Se dedica una cantidad considerable de tiempo a la comprensión del código, lo que supone el 70% del tiempo total dedicado al desarrollo de software. Esto indica que los desarrolladores dedican mucho tiempo a leer e intentar comprender el código, lo que puede sorprender a algunos que suponen que la codificación consiste únicamente en escribir la solución. En cambio, la resolución de problemas sólo ocupa el 20% del tiempo total, mientras que la escritura de código sólo supone el 10%.

Estructuras complejas bien formadas = ¡Ahorro de tiempo!

Esto pone de relieve la importancia de escribir código que sea fácil de comprender y mantener, ya que puede reducir significativamente el tiempo y el esfuerzo dedicados a tratar de entenderlo. Un código bien estructurado, bien documentado y que utilice convenciones de nomenclatura claras puede ayudar a su comprensión y facilitar el trabajo de otros desarrolladores.

  Los beneficios de TDD

Nuestro cerebro emplea mecanismos cognitivos para comprender y gestionar la complejidad.

  • Fragmentación: consiste en descomponer la complejidad en trozos coherentes que nuestro cerebro pueda procesar. Las investigaciones sugieren que solo podemos retener unas 7 cosas (+/- 2) a la vez en nuestra memoria de trabajo.
  • Jerarquías: que establecen un orden claro de importancia o disposición. Nos permite organizar la información de forma lógica y estructurada, con unos elementos en la parte superior y otros en la inferior.
  • Esquemas: también son esenciales para comprender y gestionar la complejidad. Sin una comprensión clara de las reglas y conceptos que subyacen a un sistema, puede resultar difícil navegar o resolver problemas dentro de ese sistema. Por eso, tener un esquema o modelo mental claro de un sistema complejo puede ayudar a comprenderlo y a resolver problemas.

¿Cómo podemos utilizar estos mecanismos para mejorar nuestro código?

Arquitectura bien formada

  • Modularidad
    • Alta cohesión y acoplamiento suelto
    • Diseño basado en la responsabilidad
    • Separación de intereses
    • Principio de responsabilidad única
  • Estratificación jerárquica
    • No hay ciclos ni a nivel arquitectónico ni a nivel de clase
    • Cuando la mayoría de las clases dependen de la mayoría de las otras clases, podemos tener un ciclo enorme que puede ser realmente difícil de romper.
  • Coherencia de los patrones
    • Patrones de diseño: son conocidos por todos
    • Utiliza un lenguaje de patrones
    • La aplicación coherente de patrones nos ayuda a hacer frente a la complejidad del código fuente.

Índice de madurez de la modularidad (IMM)

El índice de madurez de la modularidad determina el grado de deuda técnica de un sistema heredado. En función de

el resultado en las áreas de modularidad, jerarquía y coherencia de patrones, la necesidad de

  La coexistencia de microservicios y monolitos

puede determinarse la refactorización o una posible sustitución del sistema.

Utilizando los tres principios de modularidad, jerarquías y coherencia de patrones, se calcula el MMI.

  • La modularidad es el tema principal, con un 45% del peso final
    • Modularización técnica y de dominio (25%)
      • Un mismo módulo debe tener una alta cohesión entre sus componentes pero un bajo acoplamiento con otros módulos.
      • Los nombres deben definir la única tarea que realiza la unidad de programa
    • Interfaces internas (10%)
    • Proporciones (10%)
      • Proporciones equilibradas: No es deseable tener una unidad con la mayoría de las líneas de código mientras que el resto de las unidades sólo tienen un pequeño porcentaje.
  • Jerarquía (30%)
    • Estratificación técnica y de dominio (15%)
    • Ciclos de clases y paquetes (15%)
  • Coherencia del patrón (25%)

La calificación de cada tema viene determinada por algunas herramientas de análisis de arquitectura, algunas herramientas métricas y también por los revisores (personas que revisan el código y realizan algunos análisis manuales).

Un sistema que recibe una calificación entre 8 y 10 indica un bajo nivel de deuda técnica, es aquí donde queremos que se encuentre nuestro proyecto.

Sin embargo, si la calificación se sitúa entre 4 y 8, existe una cantidad considerable de deuda técnica. Es el momento de empezar a hacer refactorizaciones para reducir la complejidad, para mejorar la calidad del sistema. Aún estamos a tiempo.

Si la calificación es inferior a 4, el sistema sólo podrá mantenerse y ampliarse con un esfuerzo considerable. Es posible que la mayoría de nosotros nos hayamos encontrado en esta situación. En tales casos, es crucial considerar detenidamente si merecería la pena actualizar el sistema mediante refactorización (que puede ser muy difícil y dura de terminar) o si habría que sustituirlo por completo.

  Los 5 principales patrones de Arquitectura de Software

Para una comprensión más profunda, recomendamos la lectura del capítulo correspondiente del libro Software Architecture Metrics.

CTA Software

Conclusiones: Charla sobre el índice de madurez de la modularidad

El Dr. Lilienthal presentó una valiosa métrica que puede dar una idea del estado actual de un proyecto. El Índice de Madurez de Modularidad puede servir como punto de partida útil para determinar si un proyecto requiere refactorización para mantener su calidad o si es necesaria una reescritura completa. El uso de una métrica matemática tiene la ventaja de que elimina la subjetividad de las opiniones de los expertos. Sin embargo, el cálculo del Índice de Madurez de Modularidad puede resultar complicado, ya que implica la evaluación de ciertos aspectos del proyecto que requieren la intervención humana. La obtención de todas las métricas necesarias también puede ser una tarea de enormes proporciones, pero puede resultar esencial en el caso de proyectos de gran envergadura.

Author

  • Oriol Saludes

    Experienced Full Stack Engineer with a demonstrated history of working in the information technology and services industry. Skilled in PHP, Spring Boot, Java, Kotlin, Domain-Driven Design (DDD), TDD and Front-end Development. Strong engineering professional with a Engineer's degree focused in Computer Engineering from Universitat Oberta de Catalunya (UOC).

    Ver todas las entradas

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Suscríbete a nuestro boletín de noticias

Recibe actualizaciones de los últimos descubrimientos tecnológicos

¿Tienes un proyecto desafiante?

Podemos trabajar juntos

apiumhub software development projects barcelona
Secured By miniOrange