23 de março de 2026
Smells arquiteturais em backends TypeScript: uma análise comparativa
Alef Felix de Farias; Jamile Raquel Regazzo
Resumo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.
O desenvolvimento de software contemporâneo atravessa um período de rápida evolução, impulsionado pela necessidade de atender a demandas cada vez mais complexas e dinâmicas no ambiente digital. Nesse cenário, a arquitetura de software assume um papel determinante na definição da qualidade e da sustentabilidade das soluções tecnológicas, especialmente em ecossistemas voltados para a web que utilizam a linguagem TypeScript. A integridade estrutural de um sistema não é apenas uma questão de organização estética do código, mas um fator crítico que influencia diretamente a capacidade de manutenção, a escalabilidade e a longevidade das aplicações. A identificação de deficiências arquiteturais, tecnicamente denominadas como architecture smells (Martin, 2017), tornou-se um campo de estudo vital para a engenharia de software moderna. Essas falhas, muitas vezes invisíveis em testes funcionais imediatos, comprometem a estrutura interna do sistema, criando obstáculos que dificultam a evolução saudável do software ao longo do tempo.
Projetos desenvolvidos em TypeScript enfrentam desafios particulares devido à flexibilidade da linguagem e à diversidade de estilos arquiteturais que ela suporta, desde o modelo monolítico tradicional até as modernas abordagens de microsserviços e computação sem servidor. Problemas como o alto acoplamento entre módulos e a baixa coesão interna são recorrentes e impactam negativamente o desempenho e a confiabilidade das entregas. Embora a literatura técnica tenha explorado amplamente esses conceitos em linguagens como Java ou C++, ainda existe uma lacuna significativa em estudos que foquem especificamente nos impactos dessas deficiências no contexto do TypeScript. A relevância desse tema é reforçada por investigações empíricas que demonstram como padrões arquiteturais inadequados afetam a manutenibilidade (Jolak, 2025). A gestão da dívida arquitetural, por meio da detecção e priorização de smells, é uma prática essencial em grandes organizações que buscam manter a agilidade sem sacrificar a qualidade técnica (Martini, 2018).
A persistência dessas falhas estruturais ao longo do ciclo de vida do software é um fenômeno documentado, indicando que, uma vez introduzidos, os architecture smells tendem a se tornar mais recorrentes e difíceis de erradicar se não houver uma intervenção precoce (Gnoyke, 2024). Para enfrentar essa realidade, metodologias automatizadas de detecção têm sido propostas como forma de viabilizar o monitoramento contínuo da saúde do código (Fontana, 2016). A base teórica para essa análise reside, em grande parte, no conjunto de métricas para design orientado a objetos estabelecido por Chidamber e Kemerer (1994). Embora originalmente concebidas para a análise de código-fonte em nível de classe, essas métricas oferecem uma fundamentação sólida para avaliar problemas arquiteturais mais amplos quando devidamente adaptadas. Estudos recentes confirmam que a aplicação desses indicadores permite a identificação antecipada de padrões problemáticos, facilitando a adoção de medidas corretivas eficazes (Jolak, 2025; Gnoyke, 2024).
A compreensão profunda dos architecture smells exige uma análise que vá além da superfície do código, investigando como as decisões de design impactam a interdependência entre os componentes. O objetivo central desta investigação é explorar a presença e a evolução dessas deficiências em projetos TypeScript, utilizando métricas adaptadas para mensurar o impacto real nos diferentes estilos arquiteturais. Ao identificar os padrões mais frequentes e compreender suas implicações, torna-se possível propor estratégias de mitigação que contribuam para o desenvolvimento de aplicações web mais robustas e sustentáveis. A justificativa para tal esforço reside na necessidade premente de ferramentas e conhecimentos que auxiliem os engenheiros de software a navegar pela complexidade das arquiteturas modernas, garantindo que a inovação tecnológica não seja freada pela degradação estrutural interna.
Para a execução desta análise, adotou-se uma metodologia estruturada em etapas sequenciais, focada na investigação de repositórios de código aberto com predominância da linguagem TypeScript. O processo iniciou-se com um levantamento assertivo na plataforma GitHub, utilizando a API pública para filtrar projetos que atendessem a critérios rigorosos de relevância e atividade. Foram selecionados repositórios com um número de forks superior a 50, presença de múltiplos contribuidores e atividade recente, caracterizada por commits realizados após o início do ano de 2025. Essa filtragem garantiu que a amostra fosse composta por projetos com maturidade suficiente para apresentar estruturas arquiteturais passíveis de análise profunda. Ao todo, 47 repositórios foram selecionados para o estudo detalhado.
A classificação dos projetos em diferentes estilos arquiteturais foi realizada por meio de uma inspeção técnica do código-fonte e dos arquivos de configuração. Para a identificação de arquiteturas monolíticas, buscou-se a presença de módulos centralizados e arquivos de entrada padronizados, como o prefixo module e o arquivo main.ts. No caso das aplicações serverless, o critério determinante foi a existência de arquivos de configuração específicos, como serverless.yml ou template.yml, que definem rotas e funções isoladas. Já para os microsserviços, a identificação baseou-se na presença de múltiplos arquivos package.json e estruturas de pastas src independentes para cada serviço, indicando uma descentralização funcional. Após essa triagem, a amostra final consistiu em 27 monolitos, 14 sistemas de microsserviços e seis aplicações serverless.
A coleta de dados métricos exigiu o desenvolvimento de um pipeline de análise sofisticado, fundamentado na API de compilação do TypeScript. Esse pipeline permitiu a leitura semântica e estrutural do código, indo além de uma simples análise de texto. O processo envolveu a leitura do arquivo tsconfig.json de cada projeto, a criação de um programa de análise via typescript.createProgram e a geração de uma Árvore Sintática Abstrata (AST). Com o suporte do TypeChecker, foi possível extrair informações precisas sobre as relações entre classes, métodos e propriedades. Os dados extraídos foram persistidos em um banco de dados SQLite, utilizando a biblioteca better-sqlite3 em ambiente Node.js, o que facilitou a execução de consultas complexas e a análise estatística subsequente.
As métricas selecionadas para a avaliação foram o Acoplamento entre Objetos (CBO), Métodos Ponderados por Classe (WMC), Resposta por Classe (RFC) e Falta de Coesão em Métodos (LCOM). O CBO foi calculado identificando as dependências entre classes, incluindo o uso de parâmetros, propriedades e heranças, permitindo detectar pontos de baixo isolamento funcional. O WMC focou na complexidade interna, calculando a complexidade ciclomática individual de cada método, considerando blocos condicionais e laços de repetição. O RFC contabilizou o número total de métodos e funções acessíveis em resposta a uma chamada em uma classe, evidenciando o acúmulo de responsabilidades. Por fim, o LCOM avaliou a coesão interna ao analisar quantos métodos compartilham atributos comuns, identificando classes com responsabilidades fragmentadas.
Para interpretar os resultados, foram estabelecidos limiares de severidade adaptados da literatura clássica e de estudos contemporâneos (Chidamber; Kemerer, 1994; Pigazzini, 2020; Martini, 2018). Valores de CBO e WMC entre zero e 10 foram considerados adequados, enquanto resultados entre 11 e 20 indicaram estado de atenção e valores acima de 20 foram classificados como críticos. Para o RFC, o intervalo de normalidade foi definido até 25, com atenção entre 26 e 50 e criticidade acima de 50. No caso do LCOM, valores até quatro foram vistos como positivos, entre cinco e 10 como alerta e acima de 10 como críticos. Além das métricas de design, utilizou-se a ferramenta Madge para realizar uma inspeção estática de módulos e identificar cadeias de dependência cíclica, que são indicadores claros de degradação da modularidade.
A análise dos dados revelou uma distribuição desigual de architecture smells entre os modelos analisados. Observou-se que projetos de grande escala, como NX, Island.is e Firebase-tools, concentram as maiores somas de métricas, com valores de RFC e LCOM extremamente elevados. Esse padrão sugere um acoplamento excessivo e a presença de classes com responsabilidades múltiplas, características que frequentemente apontam para a existência de dívidas arquiteturais latentes. A recorrência de dependências circulares em repositórios expressivos, como o generator-jhipster e o opencollective-api, evidencia falhas no isolamento de funcionalidades, o que dificulta processos de refatoração e limita a escalabilidade do sistema. Essas constatações corroboram a tese de que a complexidade estrutural tende a aumentar proporcionalmente ao tamanho do projeto quando não há uma governança técnica rigorosa (Jolak, 2025).
Na arquitetura monolítica, a média de CBO registrada foi de 26,84, um valor consideravelmente inferior ao observado nos microsserviços. Essa diferença pode ser atribuída à natureza integrada do monolito, que exige menos dependências explícitas entre módulos externos. No entanto, o modelo monolítico apresentou as maiores médias de WMC, com 89 pontos, e de RFC, atingindo 172,11. Esses números sugerem uma forte concentração de funcionalidades dentro de poucas classes centrais, um fenômeno típico de sistemas maduros ou legados onde a evolução contínua gera componentes sobrecarregados. A presença elevada de WMC reforça o indício de métodos excessivamente complexos, o que compromete tanto a legibilidade quanto a testabilidade do código, criando o que a literatura define como God Classes (Martin, 2017).
Em contrapartida, os sistemas baseados em microsserviços apresentaram o maior grau de acoplamento externo, com uma média de CBO de 92,22. Esse resultado é reflexo da própria natureza do estilo arquitetural, que se baseia na comunicação entre múltiplos serviços autônomos. Contudo, a elevada média de LCOM, que chegou a 94, indica que, mesmo dentro de serviços teoricamente isolados, existe uma baixa coesão interna. Isso sugere que a transição para microsserviços, se não for acompanhada de um design de domínio preciso, pode apenas deslocar a complexidade de lugar, criando serviços que tentam lidar com múltiplas responsabilidades simultaneamente. A fragilidade na comunicação entre esses serviços, muitas vezes realizada sem contratos versionados, gera riscos de falhas em cascata e aumenta significativamente a complexidade de integração (Pigazzini, 2020).
As aplicações serverless, embora tenham apresentado as médias mais baixas em termos absolutos para CBO (3,40) e RFC (6,40), revelaram um comportamento inesperado na métrica WMC, com uma média de 69,40. Esse valor indica que, apesar de as funções serem pequenas e independentes, elas tendem a concentrar uma lógica interna densa e complexa. Observou-se a formação de mini-monolitos, onde uma única função serverless assume responsabilidades de persistência, manipulação de dados e regras de negócio. Um exemplo crítico foi identificado no repositório typescript-aws-lambda-typescript, onde a classe DBManager apresentou um WMC de 31 em um único método. Esse padrão, denominado Spaghetti Functions (Fowler, 2018), viola os princípios de granularidade e simplicidade esperados para o modelo serverless, dificultando o rastreamento de erros e a manutenção.
A discussão dos resultados aponta que a escolha de um estilo arquitetural não é, por si só, uma garantia de qualidade. A ausência de práticas sistemáticas de monitoramento conduz inevitavelmente à degradação da estrutura interna, independentemente de o sistema ser um monolito ou um conjunto de microsserviços. Os testes estatísticos realizados reforçaram essa visão; o teste de Kruskal-Wallis indicou uma diferença significativa apenas para a métrica CBO (p=0,0306), enquanto o perfil agregado analisado via PERMANOVA não mostrou distinção estatística global entre as arquiteturas (p=0,856). Isso sugere que, em um nível macro, todas as arquiteturas compartilham fragilidades estruturais comuns quando submetidas a processos de evolução contínua sem refatoração adequada. A distinção entre elas reside mais na localização e no tipo de smell do que na presença ou ausência do problema.
A identificação de classes com valores críticos de RFC e LCOM, como observado no projeto island.is, onde o RFC superou 6000 e o LCOM ultrapassou 4000, serve como um sinalizador precoce de falha iminente na manutenibilidade. Tais componentes tornam-se gargalos para o desenvolvimento, pois qualquer alteração mínima pode desencadear efeitos colaterais imprevisíveis em diversas partes do sistema. Para mitigar esses riscos, recomenda-se a adoção de princípios de Bounded Contexts (Evans, 2003), que auxiliam na separação clara de responsabilidades e na redução do acoplamento implícito. Além disso, a implementação de padrões de composição de funções e a padronização de respostas via middlewares são estratégias eficazes para reduzir a complexidade ciclomática em ambientes TypeScript.
A contribuição prática deste estudo materializou-se no desenvolvimento da ferramenta artie-lens, projetada para automatizar a coleta e análise dessas métricas em pipelines de integração contínua. A utilização sistemática de ferramentas desse tipo permite que as equipes de engenharia antecipem a degradação arquitetural antes que ela se torne um impedimento para a evolução do negócio. A análise estática não deve ser vista apenas como um diagnóstico passivo, mas como um insumo para modelos preditivos de dívida técnica. Por exemplo, a tendência de crescimento exponencial em métricas de acoplamento pode servir como gatilho para sessões de refatoração priorizadas, garantindo que a sustentabilidade do software seja preservada ao longo do tempo (Wang; Zhang; Kazman, 2024).
É necessário reconhecer as limitações desta pesquisa, que se concentrou em repositórios de código aberto. O viés de codificação presente em projetos comunitários pode diferir das práticas adotadas em ambientes corporativos fechados, onde o rigor arquitetural pode ser influenciado por prazos comerciais agressivos ou por padrões internos restritivos. Além disso, o número reduzido de aplicações serverless na amostra limitou a profundidade das conclusões estatísticas para esse grupo específico. Pesquisas futuras devem expandir essa base de dados e explorar a correlação entre os architecture smells e indicadores de desempenho operacional, como o tempo médio de recuperação de falhas e o custo de infraestrutura, proporcionando uma visão ainda mais integrada do impacto da qualidade do código no sucesso organizacional.
Conclui-se que o objetivo foi atingido, uma vez que a investigação demonstrou de forma empírica que a presença de architecture smells em sistemas TypeScript compromete significativamente a qualidade e a sustentabilidade das aplicações. A análise evidenciou que cada estilo arquitetural possui vulnerabilidades específicas: monolitos tendem à criação de classes sobrecarregadas e complexas, microsserviços sofrem com o alto acoplamento e dependências frágeis entre componentes, e sistemas serverless frequentemente apresentam funções pouco coesas que concentram lógica excessiva. Os resultados reforçam que a degradação estrutural é um processo contínuo que independe do modelo escolhido, sendo a governança técnica e o monitoramento automatizado por meio de métricas como CBO, WMC, RFC e LCOM as únicas defesas eficazes para prolongar a vida útil do software. A ferramenta artie-lens surge como uma solução viável para integrar essa vigilância ao ciclo de desenvolvimento, permitindo que a identificação e a mitigação precoce de falhas arquiteturais garantam a escalabilidade e a manutenibilidade necessárias para enfrentar a crescente complexidade dos sistemas modernos.
Referências 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.
Resumo executivo oriundo de Trabalho de Conclusão de Curso de Especialização em Engenharia de Software do MBA USP/Esalq
Saiba mais sobre o curso; clique aqui:
