Pitch: Como saber se a arquitetura do seu projeto TypeScript está degradando (e a CLI que fiz para medir isso)
Todo mundo mede cobertura de teste e roda lint. Poucos medem se as classes e os módulos do projeto estão bem desenhados: acoplados demais, fazendo coisas de menos (ou de mais), presos em dependências circulares. Foi essa lacuna que me levou a construir o artie-lens, uma CLI open source que mede qualidade de design em projetos TypeScript, direto da AST (via ts-morph).
Ela calcula 8 métricas, cada uma com rótulo (OK / WARNING / CRITICAL) e uma sugestão:
- Nível de classe (suíte CK, Chidamber & Kemerer, 1994): WMC, DIT, NOC, CBO, RFC e LCOM. Complexidade, herança, acoplamento e coesão.
- Nível de módulo: CE (acoplamento eferente) e detecção de dependências circulares (via componentes fortemente conexos). Essas funcionam também em código funcional, sem classes.
Algumas decisões técnicas que talvez interessem a vocês:
- Fidelidade importa. É fácil implementar um proxy tosco de LCOM e chamar de métrica CK. Se o número não corresponde à definição do paper, ele engana em vez de informar. Gastei tempo garantindo que cada métrica fosse calculada fiel ao artigo, e não um contador de linhas disfarçado.
- A armadilha do "só classe". Muito TypeScript moderno é funcional. Métrica CK cobre pouco nesse caso. Foi por isso que adicionei as métricas de módulo: o acoplamento e os ciclos de import são, dentro de um repo, a mesma classe de problema que a complexidade entre serviços em microsserviços.
- O recurso que mudou tudo foi o modo baseline/diff. Falhar em todo débito preexistente é ruído, ninguém adota. O baseline salva uma fotografia e o diff falha só no que piorou em relação a ela. Isso tornou a ferramenta usável em código legado, e virou um passo de CI:
artie run --baseline --fail-on=warning
- Performance. A primeira versão construía um Project do ts-morph por métrica, ou seja, parseava o projeto inteiro 8 vezes por execução. Refatorei para um único contexto compartilhado entre todas as métricas.
Para experimentar:
npm install -g artie-lens
artie init && artie run
Sendo honesto sobre os limites: as métricas CK fazem mais sentido em código orientado a classes, downloads no npm são uma métrica ruidosa, e isto é um nicho, não substitui um SonarQube. É um projeto de estudo que virou algo utilizável, e feedback é muito bem-vindo.
O que eu queria saber de vocês:
Como vocês acompanham a saúde estrutural dos projetos hoje? Só lint e revisão, ou usam alguma métrica?
Quem usa SonarQube ou similar, confia nos números ou vira ruído que o time acaba silenciando?
Faz sentido, para vocês, um portão de CI que falha só quando o design piora, em vez de reclamar do débito antigo?
Repositório: github.com/ariusxi/artie-lens