23 de marzo de 2026
Olores arquitectónicos en backends TypeScript: un análisis comparativo
Alef Felix de Farias; Jamile Raquel Regazzo
Resumen elaborado por la herramienta ResumeAI, solución de inteligencia artificial desarrollada por el Instituto Pecege orientada a la síntesis y redacción.
El desarrollo de software contemporáneo atraviesa un período de rápida evolución, impulsado por la necesidad de atender a demandas cada vez más complejas y dinámicas en el entorno digital. En este escenario, la arquitectura de software asume un papel determinante en la definición de la calidad y la sostenibilidad de las soluciones tecnológicas, especialmente en ecosistemas orientados a la web que utilizan el lenguaje TypeScript. La integridad estructural de un sistema no es solo una cuestión de organización estética del código, sino un factor crítico que influye directamente en la capacidad de mantenimiento, la escalabilidad y la longevidad de las aplicaciones. La identificación de deficiencias arquitectónicas, técnicamente denominadas como architecture smells (Martin, 2017), se ha convertido en un campo de estudio vital para la ingeniería de software moderna. Estas fallas, a menudo invisibles en pruebas funcionales inmediatas, comprometen la estructura interna del sistema, creando obstáculos que dificultan la evolución saludable del software a lo largo del tiempo.
Proyectos desarrollados en TypeScript enfrentan desafíos particulares debido a la flexibilidad del lenguaje y a la diversidad de estilos arquitectónicos que soporta, desde el modelo monolítico tradicional hasta los modernos enfoques de microservicios y computación sin servidor. Problemas como el alto acoplamiento entre módulos y la baja cohesión interna son recurrentes e impactan negativamente el rendimiento y la confiabilidad de las entregas. Aunque la literatura técnica ha explorado ampliamente estos conceptos en lenguajes como Java o C++, todavía existe una brecha significativa en estudios que se enfoquen específicamente en los impactos de estas deficiencias en el contexto de TypeScript. La relevancia de este tema se ve reforzada por investigaciones empíricas que demuestran cómo patrones arquitectónicos inadecuados afectan la mantenibilidad (Jolak, 2025). La gestión de la deuda arquitectónica, mediante la detección y priorización de smells, es una práctica esencial en grandes organizaciones que buscan mantener la agilidad sin sacrificar la calidad técnica (Martini, 2018).
La persistencia de estas fallas estructurales a lo largo del ciclo de vida del software es un fenómeno documentado, que indica que, una vez introducidos, los architecture smells tienden a volverse más recurrentes y difíciles de erradicar si no hay una intervención temprana (Gnoyke, 2024). Para enfrentar esta realidad, se han propuesto metodologías automatizadas de detección como forma de viabilizar el monitoreo continuo de la salud del código (Fontana, 2016). La base teórica para este análisis reside, en gran medida, en el conjunto de métricas para diseño orientado a objetos establecido por Chidamber y Kemerer (1994). Aunque originalmente concebidas para el análisis de código fuente a nivel de clase, estas métricas ofrecen una fundamentación sólida para evaluar problemas arquitectónicos más amplios cuando se adaptan adecuadamente. Estudios recientes confirman que la aplicación de estos indicadores permite la identificación temprana de patrones problemáticos, facilitando la adopción de medidas correctivas eficaces (Jolak, 2025; Gnoyke, 2024).
La comprensión profunda de los architecture smells exige un análisis que vaya más allá de la superficie del código, investigando cómo las decisiones de diseño impactan la interdependencia entre los componentes. El objetivo central de esta investigación es explorar la presencia y la evolución de estas deficiencias en proyectos TypeScript, utilizando métricas adaptadas para medir el impacto real en los diferentes estilos arquitectónicos. Al identificar los patrones más frecuentes y comprender sus implicaciones, se hace posible proponer estrategias de mitigación que contribuyan al desarrollo de aplicaciones web más robustas y sostenibles. La justificación para tal esfuerzo reside en la necesidad apremiante de herramientas y conocimientos que ayuden a los ingenieros de software a navegar por la complejidad de las arquitecturas modernas, garantizando que la innovación tecnológica no sea frenada por la degradación estructural interna.
Para la ejecución de este análisis, se adoptó una metodología estructurada en etapas secuenciales, enfocada en la investigación de repositorios de código abierto con predominancia del lenguaje TypeScript. El proceso se inició con un levantamiento asertivo en la plataforma GitHub, utilizando la API pública para filtrar proyectos que cumplieran con criterios rigurosos de relevancia y actividad. Se seleccionaron repositorios con un número de forks superior a 50, presencia de múltiples contribuidores y actividad reciente, caracterizada por commits realizados después del inicio del año 2025. Este filtrado garantizó que la muestra estuviera compuesta por proyectos con suficiente madurez para presentar estructuras arquitectónicas susceptibles de análisis profundo. En total, se seleccionaron 47 repositorios para el estudio detallado.
La clasificación de los proyectos en diferentes estilos arquitectónicos se realizó mediante una inspección técnica del código fuente y de los archivos de configuración. Para la identificación de arquitecturas monolíticas, se buscó la presencia de módulos centralizados y archivos de entrada estandarizados, como el prefijo module y el archivo main.ts. En el caso de las aplicaciones serverless, el criterio determinante fue la existencia de archivos de configuración específicos, como serverless.yml o template.yml, que definen rutas y funciones aisladas. Para los microservicios, la identificación se basó en la presencia de múltiples archivos package.json y estructuras de carpetas src independientes para cada servicio, indicando una descentralización funcional. Tras esta selección, la muestra final consistió en 27 monolitos, 14 sistemas de microservicios y seis aplicaciones serverless.
La recopilación de datos métricos requirió el desarrollo de un pipeline de análisis sofisticado, fundamentado en la API de compilación de TypeScript. Este pipeline permitió la lectura semántica y estructural del código, yendo más allá de un simple análisis de texto. El proceso implicó la lectura del archivo tsconfig.json de cada proyecto, la creación de un programa de análisis a través de typescript.createProgram y la generación de un Árbol de Sintaxis Abstracta (AST). Con el soporte del TypeChecker, fue posible extraer información precisa sobre las relaciones entre clases, métodos y propiedades. Los datos extraídos se persistieron en una base de datos SQLite, utilizando la biblioteca better-sqlite3 en un entorno Node.js, lo que facilitó la ejecución de consultas complejas y el análisis estadístico posterior.
Las métricas seleccionadas para la evaluación fueron el Acoplamiento entre Objetos (CBO), Métodos Ponderados por Clase (WMC), Respuesta por Clase (RFC) y Falta de Cohesión en Métodos (LCOM). El CBO se calculó identificando las dependencias entre clases, incluyendo el uso de parámetros, propiedades y herencias, permitiendo detectar puntos de bajo aislamiento funcional. El WMC se centró en la complejidad interna, calculando la complejidad ciclomática individual de cada método, considerando bloques condicionales y bucles de repetición. El RFC contabilizó el número total de métodos y funciones accesibles en respuesta a una llamada en una clase, evidenciando la acumulación de responsabilidades. Finalmente, el LCOM evaluó la cohesión interna analizando cuántos métodos comparten atributos comunes, identificando clases con responsabilidades fragmentadas.
Para interpretar los resultados, se establecieron umbrales de severidad adaptados de la literatura clásica y de estudios contemporáneos (Chidamber; Kemerer, 1994; Pigazzini, 2020; Martini, 2018). Valores de CBO y WMC entre cero y 10 se consideraron adecuados, mientras que resultados entre 11 y 20 indicaron estado de atención y valores superiores a 20 se clasificaron como críticos. Para el RFC, el intervalo de normalidad se definió hasta 25, con atención entre 26 y 50 y criticidad superior a 50. En el caso del LCOM, valores hasta cuatro se vieron como positivos, entre cinco y 10 como alerta y superiores a 10 como críticos. Además de las métricas de diseño, se utilizó la herramienta Madge para realizar una inspección estática de módulos e identificar cadenas de dependencia cíclica, que son indicadores claros de degradación de la modularidad.
El análisis de los datos reveló una distribución desigual de architecture smells entre los modelos analizados. Se observó que proyectos de gran escala, como NX, Island.is y Firebase-tools, concentran las mayores sumas de métricas, con valores de RFC y LCOM extremadamente elevados. Este patrón sugiere un acoplamiento excesivo y la presencia de clases con responsabilidades múltiples, características que frecuentemente apuntan a la existencia de deudas arquitectónicas latentes. La recurrencia de dependencias circulares en repositorios expresivos, como generator-jhipster y opencollective-api, evidencia fallas en el aislamiento de funcionalidades, lo que dificulta los procesos de refactorización y limita la escalabilidad del sistema. Estas constataciones corroboran la tesis de que la complejidad estructural tiende a aumentar proporcionalmente al tamaño del proyecto cuando no hay una gobernanza técnica rigurosa (Jolak, 2025).
En la arquitectura monolítica, la media de CBO registrada fue de 26,84, un valor considerablemente inferior al observado en los microservicios. Esta diferencia puede atribuirse a la naturaleza integrada del monolito, que exige menos dependencias explícitas entre módulos externos. Sin embargo, el modelo monolítico presentó las mayores medias de WMC, con 89 puntos, y de RFC, alcanzando 172,11. Estos números sugieren una fuerte concentración de funcionalidades dentro de pocas clases centrales, un fenómeno típico de sistemas maduros o legados donde la evolución continua genera componentes sobrecargados. La presencia elevada de WMC refuerza el indicio de métodos excesivamente complejos, lo que compromete tanto la legibilidad como la testeabilidad del código, creando lo que la literatura define como God Classes (Martin, 2017).
En contrapartida, los sistemas basados en microservicios presentaron el mayor grado de acoplamiento externo, con una media de CBO de 92,22. Este resultado es reflejo de la propia naturaleza del estilo arquitectural, que se basa en la comunicación entre múltiples servicios autónomos. No obstante, la elevada media de LCOM, que llegó a 94, indica que, incluso dentro de servicios teóricamente aislados, existe una baja cohesión interna. Esto sugiere que la transición a microservicios, si no va acompañada de un diseño de dominio preciso, puede solo desplazar la complejidad de lugar, creando servicios que intentan lidiar con múltiples responsabilidades simultáneamente. La fragilidad en la comunicación entre estos servicios, a menudo realizada sin contratos versionados, genera riesgos de fallas en cascada y aumenta significativamente la complejidad de integración (Pigazzini, 2020).
Las aplicaciones serverless, aunque presentaron las medias más bajas en términos absolutos para CBO (3,40) y RFC (6,40), revelaron un comportamiento inesperado en la métrica WMC, con una media de 69,40. Este valor indica que, a pesar de que las funciones son pequeñas e independientes, tienden a concentrar una lógica interna densa y compleja. Se observó la formación de mini-monolitos, donde una única función serverless asume responsabilidades de persistencia, manipulación de datos y reglas de negocio. Un ejemplo crítico fue identificado en el repositorio typescript-aws-lambda-typescript, donde la clase DBManager presentó un WMC de 31 en un único método. Este patrón, denominado Spaghetti Functions (Fowler, 2018), viola los principios de granularidad y simplicidad esperados para el modelo serverless, dificultando el rastreo de errores y el mantenimiento.
La discusión de los resultados apunta que la elección de un estilo arquitectural no es, por sí sola, una garantía de calidad. La ausencia de prácticas sistemáticas de monitoreo conduce inevitablemente a la degradación de la estructura interna, independientemente de si el sistema es un monolito o un conjunto de microservicios. Las pruebas estadísticas realizadas reforzaron esta visión; la prueba de Kruskal-Wallis indicó una diferencia significativa solo para la métrica CBO (p=0,0306), mientras que el perfil agregado analizado vía PERMANOVA no mostró distinción estadística global entre las arquitecturas (p=0,856). Esto sugiere que, a nivel macro, todas las arquitecturas comparten fragilidades estructurales comunes cuando son sometidas a procesos de evolución continua sin refactorización adecuada. La distinción entre ellas reside más en la ubicación y el tipo de smell que en la presencia o ausencia del problema.
La identificación de clases con valores críticos de RFC y LCOM, como observado en el proyecto island.is, donde el RFC superó 6000 y el LCOM sobrepasó 4000, sirve como un señalizador precoz de falla inminente en la mantenibilidad. Tales componentes se vuelven cuellos de botella para el desarrollo, pues cualquier alteración mínima puede desencadenar efectos colaterales impredecibles en diversas partes del sistema. Para mitigar estos riesgos, se recomienda la adopción de principios de Bounded Contexts (Evans, 2003), que auxilian en la separación clara de responsabilidades y en la reducción del acoplamiento implícito. Además, la implementación de patrones de composición de funciones y la estandarización de respuestas a través de middlewares son estrategias efectivas para reducir la complejidad ciclomática en entornos TypeScript.
La contribución práctica de este estudio se materializó en el desarrollo de la herramienta artie-lens, diseñada para automatizar la recopilación y el análisis de estas métricas en pipelines de integración continua. La utilización sistemática de herramientas de este tipo permite a los equipos de ingeniería anticipar la degradación arquitectónica antes de que se convierta en un impedimento para la evolución del negocio. El análisis estático no debe verse solo como un diagnóstico pasivo, sino como un insumo para modelos predictivos de deuda técnica. Por ejemplo, la tendencia de crecimiento exponencial en métricas de acoplamiento puede servir como disparador para sesiones de refactorización priorizadas, garantizando que la sostenibilidad del software se preserve a lo largo del tiempo (Wang; Zhang; Kazman, 2024).
Es necesario reconocer las limitaciones de esta investigación, que se centró en repositorios de código abierto. El sesgo de codificación presente en proyectos comunitarios puede diferir de las prácticas adoptadas en entornos corporativos cerrados, donde el rigor arquitectónico puede verse influenciado por plazos comerciales agresivos o por estándares internos restrictivos. Además, el número reducido de aplicaciones serverless en la muestra limitó la profundidad de las conclusiones estadísticas para este grupo específico. Investigaciones futuras deben expandir esta base de datos y explorar la correlación entre los architecture smells y los indicadores de rendimiento operativo, como el tiempo medio de recuperación de fallos y el coste de infraestructura, proporcionando una visión aún más integrada del impacto de la calidad del código en el éxito organizacional.
Se concluye que el objetivo se alcanzó, ya que la investigación demostró empíricamente que la presencia de architecture smells en sistemas TypeScript compromete significativamente la calidad y la sostenibilidad de las aplicaciones. El análisis evidenció que cada estilo arquitectónico tiene vulnerabilidades específicas: los monolitos tienden a la creación de clases sobrecargadas y complejas, los microservicios sufren de alto acoplamiento y dependencias frágiles entre componentes, y los sistemas serverless frecuentemente presentan funciones poco cohesivas que concentran lógica excesiva. Los resultados refuerzan que la degradación estructural es un proceso continuo que independe del modelo elegido, siendo la gobernanza técnica y el monitoreo automatizado a través de métricas como CBO, WMC, RFC y LCOM las únicas defensas efectivas para prolongar la vida útil del software. La herramienta artie-lens surge como una solución viable para integrar esta vigilancia al ciclo de desarrollo, permitiendo que la identificación y mitigación temprana de fallos arquitectónicos garanticen la escalabilidad y mantenibilidad necesarias para enfrentar la creciente complejidad de los sistemas modernos.
Referencias Bibliográficas:
CHIDAMBER, S. R.; KEMERER, C. F. A metrics suite for object oriented design. IEEE Transactions on Software Engineering, v. 20, n. 6, p. 476-493, 1994. DOI: 10.1109/32.295895.
EVANS, E. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2003.
FONTANA, F. A.; PIGAZZINI, I.; ROVEDA, R.; ZANONI, M. Automatic Detection of Instability Architectural Smells. In: IEEE INTERNATIONAL CONFERENCE ON SOFTWARE MAINTENANCE AND EVOLUTION (ICSME), 2016, Raleigh, NC, USA. Proceedings […]. IEEE, 2016. p. 433–437. DOI: 10.1109/ICSME.2016.33.
FONTANA, F. A.; PIGAZZINI, I.; ROVEDA, R.; ZANONI, M. Automatic Detection of Instability Architectural Smells. In: IEEE INTERNATIONAL CONFERENCE ON SOFTWARE MAINTENANCE AND EVOLUTION (ICSME), 2016, Raleigh, NC, USA. Proceedings […]. IEEE, 2016. p. 433–437. DOI: 10.1109/ICSME.2016.33.
FOWLER, M. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 2018.
GNOYKE, P.; SCHULZE, S.; KRÜGER, J. Evolution patterns of software-architecture smells: An empirical study of inter-version smells. Information and Software Technology, 14 ago. 2024.
JOLAK, R.; KARLSSON, S.; DOBSLAW, F. An empirical investigation of the impact of architectural smells on software maintainability. Information and Software Technology, v. 156, Mid Sweden University, Sweden, 27 fev. 2025.
MARTIN, R. C. Clean Code: A Handbook of Agile Software Craftsmanship. Upper Saddle River, NJ: Prentice Hall, 2008.
MARTINI, A.; FONTANA, F. A.; BIAGGI, A.; ROVEDA, R. Identifying and prioritizing architectural debt through architectural smells: a case study in a large software company. In: EUROPEAN CONFERENCE ON SOFTWARE ARCHITECTURE (ECSA), 2018. Proceedings […]. Springer, 2018. p. 320–335.
WANG, Z.; ZHANG, Y.; KAZMAN, R. The study on software architecture smell refactoring based on priority. Journal of Systems and Software, v. 206, p. 111334, 2024.
Resumen ejecutivo del Trabajo de Conclusión de Curso de Especialización en Ingeniería de Software del MBA USP/Esalq
Más información sobre el curso; haga clic aquí:
