CLEM: A Behavior-Centric Software Quality Measurement Framework for Structural Change Monitoring

Imagine que você está observando uma cidade crescer. Você poderia contar quantos tijolos são assentados a cada dia, ou poderia verificar se a câmara municipal seguiu as regras. Mas há uma terceira maneira, mais interessante, de olhar para uma cidade: observar como os edifícios mudam. As pessoas derrubam paredes antigas para adicionar um novo cômodo? Elas constroem uma nova ala que se conecta à lateral sem tocar na casa principal? Elas apenas giram uma chave para mudar a iluminação? Ou simplesmente rearranjam os móveis? No mundo do software, esta é exatamente a pergunta que os pesquisadores estão fazendo. O software não é apenas código; é um sistema vivo que tem que mudar constantemente para continuar útil. Se um sistema muda apenas derrubando suas próprias paredes, ele eventualmente se torna um emaranhado instável e perigoso. Mas se ele muda adicionando novas alas ou girando chaves, ele permanece forte e flexível. Este é o cerne da "qualidade de software" — não apenas se o código funciona hoje, mas se ele pode continuar crescendo sem desmoronar amanhã.

Este artigo apresenta uma nova ferramenta chamada CLEM (Change Localization and Externalization Measurement) para responder a essa pergunta. Em vez de apenas contar quanto código foi alterado, o CLEM atua como um detetive que observa como os desenvolvedores corrigem ou atualizam um sistema. Ele classifica cada mudança em uma de quatro "personas":

1. Modificação (M): A abordagem "Derrubar Paredes". Alterar o código central diretamente. É rápido, mas arriscado, como abrir um buraco em uma parede para adicionar uma porta.
2. Extensão (E): A abordagem "Adição". Construir novos recursos que se conectam ao sistema sem tocar no núcleo, como adicionar um novo cômodo a uma casa.
3. Low-code (L): A abordagem "Fluxograma". Usar ferramentas visuais ou regras para mudar o comportamento, como um gerente de negócios rearranjando um fluxo de trabalho sem escrever código.
4. Configuração (C): A abordagem "Interruptor". Apenas mudar configurações ou parâmetros, como girar um botão para mudar o volume.

Os pesquisadores testaram essa ideia em três projetos de software diferentes: dois públicos de um grande ecossistema tecnológico e um aplicativo de saúde privado. Eles descobriram que o CLEM consegue distinguir claramente entre um sistema que é "saudável" (usando principalmente adições e interruptores) e um que está "doente" (constantemente hackeando seu próprio núcleo). No entanto, eles também descobriram algo surpreendente: saber como um sistema muda não prevê automaticamente se ele terá mais bugs no próximo mês. É uma ótima ferramenta para entender a estrutura de um sistema, mas não é uma bola de cristal para prever erros futuros.

O Novo Caderno do Detetive: Como o CLEM Funciona

Pense no desenvolvimento de software como uma cozinha movimentada. Durante anos, os chefs (desenvolvedores) foram medidos pelo número de pratos que cozinham (volume de atividade) ou pela limpeza da cozinha ao final da noite (verificações de código estático). Mas e se a cozinha estiver desmoronando porque toda vez que precisam de um tempero novo, precisam quebrar uma parede para chegar à despensa? Esse é o problema que o CLEM resolve. Ele não apenas conta os pratos; ele observa o método que os chefs usam para obter ingredientes.

O artigo propõe que, toda vez que um sistema de software é atualizado, a mudança ocorre de uma de quatro maneiras, e a mistura dessas maneiras revela tudo sobre a saúde do sistema.

• Modificação (M) é o método da "Força Bruta". É como um chef pegando uma marreta para quebrar uma parede porque precisa de uma nova prateleira. Resolve o problema rápido, mas se você fizer isso demais, todo o edifício se torna instável.
• Extensão (E) é o método "Modular". É como construir um novo carrinho destacável que rola para dentro da cozinha. O chef não toca nas paredes; ele apenas adiciona uma nova ferramenta. Isso é mais seguro e mantém a estrutura central intacta.
• Low-code (L) é o método do "Projeto". Imagine um gerente desenhando um novo fluxo em um quadro branco que diz aos robôs o que fazer, sem que os robôs precisem ser reprogramados. É uma forma de nível superior de mudar as coisas.
• Configuração (C) é o método do "Botão". É apenas girar um botão para deixar o forno mais quente ou as luzes mais brilhantes. Nenhuma construção é necessária.

Os autores argumentam que um sistema de software saudável e duradouro deve depender mais de Extensão, Low-code e Configuração, e menos de Modificação. Se um sistema está constantemente "Modificando" seu núcleo, é provável que esteja acumulando "dívida técnica" — uma forma elegante de dizer que está pegando emprestada a estabilidade do futuro e terá que pagá-la com juros mais tarde.

O Experimento: Observando Três Cozinhas

Para ver se essa ideia funciona, os pesquisadores fizeram uma excursão a três "cozinhas" (repositórios de software). Eles não olharam apenas para os pratos finais; eles observaram as mãos dos chefs durante meses.

1. A Cozinha "Fit" (fit-framework): Este era um projeto público projetado para ser um sistema de plugins. Eles esperavam que fosse cheio de "Extensões" (E).
2. A Cozinha "App" (app-platform): Este era outro projeto público, mas foi construído para design visual de low-code. Eles esperavam que fosse cheio de "Low-code" (L) e "Configuração" (C).
3. A Cozinha "Antisuger": Este era um aplicativo de saúde privado para gestão de açúcar no sangue. Foi construído por uma equipe diferente com ferramentas diferentes. Eles esperavam que estivesse em uma fase inicial e caótica, provavelmente cheia de "Modificações" (M).

Os pesquisadores analisaram 607 atualizações específicas (commits) nestes projetos. Eles usaram um conjunto de regras transparentes para examinar os arquivos que estavam sendo alterados. Se um arquivo estava em uma pasta de "plugin", eles o contavam como Extensão. Se era um arquivo de "fluxo", contavam como Low-code. Se era um arquivo de código central, era Modificação.

O Que Eles Descobriram: Os Sistemas Pareciam Diferentes

Os resultados foram exatamente o que a teoria da "cozinha saudável" previu.

• O App-platform era de fato muito "externalizado". Cerca de 69,5% de suas mudanças eram Extensões, com muito pouco hacking direto do núcleo. Seu score "CLEM-ES" (uma medida de quanto a mudança foi afastada do núcleo) era de um forte +0,685.
• O Fit-framework era uma mistura. Tinha muitas Extensões (33,4%), mas também tinha uma parte significativa de Modificações (29,1%). Seu score era de +0,418, mostrando que era mais saudável do que um caos total, mas não tão "externalizado" quanto o App platform.
• O aplicativo de saúde Antisuger era o oposto. Era quase inteiramente dominante em "Modificação", com 83,0% de suas mudanças sendo edições diretas no núcleo. Seu score era de -0,659, indicando que ainda estava em uma fase frágil de "quebrar as paredes".

Isso provou que o CLEM pode identificar com sucesso a diferença entre um sistema que cresce adicionando alas e um que cresce quebrando paredes. Os pesquisadores até verificaram se suas regras eram justas, fazendo com que dois humanos analisassem 160 atualizações aleatórias. Eles concordaram 100% das vezes sobre a categoria principal, o que sugere que as regras são sólidas e reproduzíveis.

A Reviravolta: A Estrutura Não Prediz Bugs (Ainda)

Aqui é a parte onde o artigo é muito cuidadoso. Você pode pensar: "Se um sistema está hackeando suas próprias paredes (alta Modificação), ele deve quebrar com mais frequência, certo?" Os pesquisadores testaram isso. Eles observaram se os scores do CLEM podiam prever se o sistema teria mais "correções de bugs" no mês seguinte.

A resposta? Não há um vínculo claro.
Em seus dados, o score de "Modificação" não previu de forma confiável se o próximo mês seria cheio de correções de bugs. O score "CLEM-ES" (o quão externalizadas eram as mudanças) teve quase zero correlação com futuras correções de bugs nesta amostra específica.

Esta é uma descoberta crucial. Os autores afirmam explicitamente que o CLEM não é uma bola de cristal mágica para prever defeitos. Ele não substitui as formas antigas de contar bugs ou churn de código. Em vez disso, oferece um tipo diferente de insight. Ele informa sobre a postura estrutural do sistema. Um sistema com um alto score de Modificação pode não ter mais bugs hoje, mas está construindo uma estrutura que é mais difícil de manter e mais propensa a se tornar frágil ao longo do tempo. É como um edifício que é estruturalmente inseguro; pode não desabar hoje, mas a planta é ruim.

Por Que Isso Importa

O artigo conclui que o CLEM é uma nova lente poderosa para gestores de software. Ele move a conversa de "Quanto código escrevemos?" para "Como estamos mudando nosso sistema?".

• Se você vê uma equipe fazendo constantemente Modificações, é um sinal para pausar e perguntar: "Por que estamos quebrando nossas próprias paredes? Podemos construir um plugin em vez disso?"
• Se você vê uma equipe fazendo principalmente Extensões e Configurações, isso sugere que o sistema está amadurecendo e se tornando mais estável.

Os autores são honestos sobre os limites de seu trabalho. Eles admitem que sua amostra foi pequena (apenas alguns meses de dados de três projetos) e que a parte de "previsão de bugs" não funcionou como esperado. Eles sugerem que o CLEM é melhor usado como uma ferramenta complementar — uma forma de manter um olho na saúde estrutural de um sistema junto com as métricas tradicionais. Não é um veredito final sobre qualidade, mas uma forma muito clara e auditável de ver se um sistema de software está aprendendo a crescer ou se está preso no hábito de quebrar sua própria fundação.

Em resumo, o CLEM nos dá um vocabulário para falar sobre a forma da mudança. Ajuda-nos a ver se o nosso software está construindo um arranha-céu ou apenas empilhando tijolos sobre uma pilha instável, e essa distinção pode ser a coisa mais importante que podemos medir para a sobrevivência a longo prazo de qualquer sistema digital.