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

想象一下你正在观察一座城市的成长。你可以计算每天铺设了多少块砖，或者检查市议会是否遵守了规则。但还有第三种更有趣的方式来看待一座城市：观察建筑是如何变化的。人们是在拆掉旧墙来增加一个新房间吗？他们是在侧面建造一个不接触主屋的新翼楼吗？他们只是通过切换开关来改变照明吗？还是仅仅重新排列了家具？在计算机软件的世界里，这正是研究人员正在探究的问题。软件不仅仅是代码；它是一个必须不断变化以保持实用的生命系统。如果一个系统只能通过拆毁自己的墙壁来变化，它最终会变成一个摇摇欲坠、危险重重的烂摊子。但如果它通过增加新翼楼或切换开关来进行变化，它就能保持强韧与灵活。这就是“软件质量”的核心——不仅在于代码今天是否有效，更在于它明天能否在持续增长的同时而不崩溃。

本文介绍了一个名为 CLEM（变更定位与外部化度量）的新工具，旨在回答这个问题。CLEM 不仅仅是统计修改了多少代码，它更像是一个侦探，观察开发者是如何修复或更新系统的。它将每一次变更归类为四种“人格”之一：

1. 修改 (Modification, M)： “拆墙”法。直接修改核心代码。这种方法很快，但风险很高，就像为了加个门而在墙上凿个洞。
2. 扩展 (Extension, E)： “加装”法。构建能够插入系统但不触碰核心的新功能，就像在房子旁盖一个新房间。
3. 低代码 (Low-code, L)： “流程图”法。使用可视化工具或规则来改变行为，就像业务经理在不编写代码的情况下重新排列工作流。
4. 配置 (Configuration, C)： “开关”法。仅仅是更改设置或参数，就像通过转动旋钮来调节音量。

研究人员在三个不同的软件项目上测试了这个想法：两个来自大型技术生态系统的公开项目，以及一个私有的医疗应用。他们发现，CLEM 可以清晰地分辨出一个系统是“健康”的（主要使用插件和开关）还是“生病”的（不断在破解自己的核心）。然而，他们也发现了一个令人惊讶的事实：了解系统如何变化并不能自动预测下个月它是否会出现更多漏洞。它是理解系统“结构”的一个极佳工具，但并不是预测未来错误的“水晶球”。

侦探的新笔记本：CLEM 如何运作

把软件开发想象成一个繁忙的厨房。多年来，厨师（开发者）一直通过他们做了多少菜（活动量）或深夜结束时厨房有多干净（静态代码检查）来衡量。但如果厨房之所以垮掉，是因为每次需要一种新香料时，他们都必须砸碎一面墙才能到达储藏室呢？这就是 CLEM 要解决的问题。它不只是数菜肴的数量，它观察的是厨师获取食材的“方式”。

论文提出，每当一个软件系统进行更新时，其变化都以四种方式之一发生，而这些方式的组合揭示了关于系统的一切信息。

• 修改 (M) 是“蛮力”法。它就像厨师拿着一把大锤去砸墙，只为了弄到一个新架子。它能快速完成任务，但如果你做得太多，整个建筑就会变得不稳定。
• 扩展 (E) 是“模块化”法。它就像建造一个可以从厨房里推入的新手推车。厨师不需要触碰墙壁，只需添加一个新工具。这更安全，且能保持核心结构的完整。
• 低代码 (L) 是“蓝图”法。想象一位经理在白板上画出一条新的流程，告诉机器人该做什么，而不需要对机器人进行重新编程。这是一种更高层级的变更方式。
• 配置 (C) 是“旋钮”法。仅仅是转动旋钮让烤箱更热或让灯光更亮。完全不需要任何施工。

作者认为，一个健康、持久的软件系统应该更多地依赖扩展、低代码和配置，而减少对修改的依赖。如果一个系统不断地“修改”其核心，它很可能正在积累“技术债”——这是一种高级说法，意指它正在向未来借用稳定性，并且将来必须支付利息。

实验：观察三个厨房

为了验证这个想法是否可行，研究人员去三个不同的“厨房”（软件仓库）进行了实地考察。他们不仅看了最终的菜肴，还观察了厨师的手部动作长达数月。

1. “Fit”厨房 (fit-framework)： 这是一个旨在作为插件系统的公开项目。他们预期这里会有很多“扩展”（E）。
2. “App”厨房 (app-platform)： 这是另一个公开项目，但它是为低代码视觉设计而构建的。他们预期这里会有很多“低代码”（L）和“配置”（C）。
3. “Antisuger”厨房： 这是一个用于管理血糖的私有医疗应用。它由不同的团队使用不同的工具构建。他们预期这里处于早期、混乱的阶段，很可能充满了“修改”（M）。

研究人员分析了这些项目中的 607 次特定更新（提交/commits）。他们使用一套透明的规则来观察被修改的文件。如果一个文件位于“插件”文件夹中，就将其计为扩展。如果它是一个“流”文件，就计为低代码。如果它是核心代码文件，则计为修改。

发现：系统各具特色

结果正如“健康厨房”理论所预测的那样。

• App-platform 确实非常“外部化”。大约 69.5% 的变更都是扩展，极少直接对核心进行破坏性修改。它的 “CLEM-ES” 分数（衡量将变更推离核心程度的指标）达到了强劲的 +0.685。
• Fit-framework 则比较混合。它有很多扩展（33.4%），但也有一部分显著的修改（29.1%）。它的分数为 +0.418，显示它比纯粹的乱局要健康，但不如 App 平台那样“外部化”。
• Antisuger 医疗应用则恰恰相反。它几乎完全由“修改”主导，83.0% 的变更都是直接的核心编辑。它的分数为 -0.659，表明它仍处于脆弱的、“砸墙”阶段。

这证明了 CLEM 可以成功识别出一个系统是在通过“增加新翼楼”成长，还是在通过“砸墙”成长。研究人员甚至通过让两名人类查看 160 个随机更新 来检查其规则是否公平。两人在主要类别上的达成一致率高达 100%，这表明规则是稳健且可复现的。

转折：结构并不预测漏洞（目前尚不能）

这是论文处理得非常谨慎的部分。你可能会想：“如果一个系统一直在砸自己的墙（高修改度），它应该更容易出错，对吧？”研究人员测试了这一点。他们观察了 CLEM 分数是否能预测下个月是否会出现更多的“缺陷修复”。

答案是：没有明确的联系。
在他们的数据中，“修改”得分并不能可靠地预测下个月是否会出现大量的缺陷修复。在这一特定样本中，“CLEM-ES”得分（变更的外部化程度）与未来的缺陷修复几乎呈 零相关。

这是一个至关重要的发现。作者明确指出，CLEM 不是 预测缺陷的魔力水晶球。它并不取代旧有的统计漏洞或代码变更量的方法。相反，它提供了一种 不同类型 的洞察。它告诉你的是系统的“结构姿态”。一个具有高修改得分的系统可能在 今天 不会有更多漏洞，但它正在构建一个难以维护且更容易变得脆弱的结构。这就像一座结构不稳的建筑；它今天可能不会坍塌，但其蓝图是有问题的。

为什么这很重要

论文总结道，CLEM 是软件管理者的一个强大新视角。它将对话从“我们写了多少代码？”转向了“我们是如何改变系统的？”

• 如果你看到一个团队一直在做 修改 (Modifications)，这是一个信号，提醒你要停下来问问：“我们为什么要拆自己的墙？能不能做一个插件？”
• 如果你看到一个团队主要在做 扩展 (Extensions) 和 配置 (Configurations)，这表明系统正在成熟并变得更加稳定。

作者坦诚地说明了他们工作的局限性。他们承认样本量较小（仅来自三个项目的几个月数据），且“漏洞预测”部分并未达到预期的效果。他们建议将 CLEM 作为一种 补充工具 使用——一种在观察传统指标的同时，监测系统结构健康状况的方法。它不是对质量的最终判决，但它提供了一种非常清晰、可审计的方式，让我们看到一个软件系统是在学习如何长大，还是陷入了破坏自身基础的习惯中。

简而言之，CLEM 为我们提供了一套讨论变更“形状”的词汇。它帮助我们观察我们的软件是在建造摩天大楼，还是仅仅在摇晃的堆积物之上堆叠砖块，而这种区别可能是我们衡量任何数字系统长期生存能力时最重要的指标。