Detecting Object-Oriented Code Smells through Social Network Analysis
本文提出了一种通过将软件组件及其交互建模为社交网络，并对四个 Java 开源项目应用社交网络分析（SNA）指标来揭示隐藏设计缺陷的方法，从而实现对面向对象代码异味的新颖检测。
原始论文采用 CC BY 4.0 许可（https://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
软件是由无数细小的指令构成的，这些指令协同工作，就像一座城市是由单体建筑和连接它们的道路组成的。当一座城市规划良好时，交通便会顺畅，新的社区也可以在不引发混乱的情况下被添加进来。在计算机编程的世界里，这种组织方式被称为“面向对象设计”，即代码被分组为相互作用的自包含单元。然而，正如城市可能会遭受交通拥堵或废弃建筑的困扰一样，软件也会产生被称为“代码异味”（code smells）的结构性缺陷。这些异味并不会导致程序崩溃，但它们是设计变得混乱、难以理解或难以修复的信号。如果任由其发展而不加处理，这些异味会使软件变得脆弱且难以维护，迫使开发者花费更多时间去解开乱麻，而不是开发新功能。
几十年来，研究人员一直试图自动发现这些缺陷，通常通过统计代码行数或测量单个部分使用的变量数量来进行。虽然这些传统方法很有帮助，但有时会忽略大局，无法看到系统的不同部分是如何以复杂的方式相互依赖的。由沙特国王大学的穆罕默德·马德赫（Mohamed Madheh）在最近的一项研究中提出的新方法建议，不要仅仅将软件视为文件的集合，而是将其视为一个社交网络。在这种视角下，每一类代码都是一个人，而每当一段代码使用另一段代码时，就是一次社交互动。通过应用用于绘制人类社区中的友谊和影响力图谱的相同数学工具，研究人员开发出了一种能够更清晰地识别这些结构性弱点的方法。
该研究重点关注了四个使用 Java 语言编写的知名开源软件项目：JUnit、Spring、Apache Commons BCEL 和 Guava。这些项目的规模差异显著，从几百个到超过四千个不同的代码单元不等。为了进行分析，研究人员首先提取了这些项目中的每一个类，并精确绘制了它们是如何相互作用的。如果一个类需要另一个类的数据或函数，就会在它们之间画一条线，从而创建一个巨大的连接网络。随后，这个网络被导入到一个名为 Gephi 的专业可视化工具中，这使得研究人员能够将整个软件结构视为一张单一的、互连的地图来观察。
一旦软件被建模为网络，研究人员就会应用特定的度量标准来识别“异味”。在社交网络中，一个认识所有人并处于许多对话中心的人是高度连接的。在软件中，一个与过多其他类进行交互的类往往预示着一个“上帝类”（God Class），即一个承担了过多职责、试图做所有事情的单元。相反，一个谁也不认识、独自坐在地图边缘的人代表了“死代码”（Dead Code），即一段不再被使用的软件。其他模式，例如一群只互相交流却从不与外界沟通的人，或者一个作为两个独立群体之间唯一桥梁的单个人，揭示了诸如“数据类”（Data Classes，仅持有信息而不执行任何操作）或“散弹式修改”（Shotgun Surgery，即一次改动需要多处地方进行修改）之类的缺陷。
结果表明，这种基于网络的方法可以有效地过滤掉绝大部分健康的编码，从而为开发者留下一个更小的可疑名单进行检查。在研究的规模最大的项目中（包含超过四千个类），该方法仅将约 17% 的代码标记为潜在的问题代码。在另一个拥有近千个类的项目中，它识别出大约 35% 的代码需要关注。可视化工具使这些发现变得直观且即时；“上帝类”表现为地图中心巨大的、色彩鲜艳的核心枢纽，而“死代码”和“未使用的类”则表现为被推向边缘的微小、暗淡的节点，通常孤立在各自断开的岛屿中。
这种方法并不声称可以取代人类判断，或完美地识别出每一个没有误差的缺陷。相反，它是一个强大的分诊工具，一种将审查整个代码库的繁重任务缩减为一份可控的、针对最具结构异常部分的清单的方法。通过关注代码片段之间的关系而非仅仅是其内部内容，该方法提供了一个看待旧问题的全新视角。它表明，一个软件系统的健康状况往往体现在其连接的模式中，通过绘制这些模式，开发者可以在威胁其数字创作稳定性的隐患变得无法控制之前，找到这些隐藏的弱点。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。