A Concern-Centric Empirical Evaluation of Multi-Language Code Smells: An LLM-Assisted Study of JNI Software Evolution
本文通过对 15 个开源项目的 8,207 个提交进行基于大语言模型辅助的分析，呈现了对 JNI 代码异味以关注点为中心的实证评估，揭示了现有的异味定义仅覆盖了 36.5% 的开发者维护关注点，并提出了三种新的异味定义以填补识别出的空白。
原始论文采用 CC BY 4.0 许可（https://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
现代软件通常给人一种运转良好的机器之感，但在精美的界面之下，它往往是由许多使用不同语言构建的部件组成的。为了让程序快速、高效或能够与专门的硬件通信，开发者经常将用一种语言编写的代码与另一种语言编写的代码结合在一起。实现这一目标的一种常见方式是通过一个被称为 Java 本地接口（Java Native Interface, JNI）的桥梁，它允许用 Java 编写的程序去调用用 C 或 C++ 编写的强大工具。虽然这种语言的混合赋予了软件巨大的力量，但也创造了一种独特的混乱。正如翻译人员可能难以在两种不同的方言之间保持一致一样，软件也会产生隐藏的缺陷，即两种语言在如何共享数据、管理内存或处理错误方面无法达成共识。这些被称为“代码异味”（code smells）的缺陷并非会导致程序立即崩溃的漏洞，而是那些会让软件在随时间推移变得难以修复、更新或理解的设计选择。多年来，专家们一直试图对这些异味进行分类，建立关于糟糕跨语言设计的清单。但一个关键的问题始终悬而未决：这些清单是否真的与开发者在试图维持这些复杂系统运行的过程中每天面临的实际问题相匹配？
一组研究人员致力于通过直接观察软件随时间变化的演进历史，而非仅仅盯着代码本身，来回答这个问题。他们将目光锁定在十五个高度依赖这种 Java 到 C 桥接技术的流行开源项目上。他们没有靠猜测哪里可能出错，而是检查了这些项目多年来开发者所做的成千上通次的更新，即“提交”（commits）。他们寻找的是这样的时刻：开发者必须停下来修复一个与两种语言连接相关的特定维护问题。为了处理海量的数据，他们使用了一种先进的人工智能工具来阅读代码的变化以及开发者编写的注释。这个 AI 扮演了一个高度熟练的助手角色，扫描修改内容以识别开发者试图解决的具体问题，例如修复内存泄漏、保障数据传输安全，或是重新组织两个系统部分之间通信的方式。研究人员随后手动检查了一组发现结果，以确保 AI 的准确性，从而证实了该方法的可靠性。
这项研究揭示了开发者实际挣扎于何处的清晰图景。他们识别出了十一类不断出现的不同问题家族。最常见的问题涉及保持两种语言之间的边界安全，以及确保资源（如内存或文件句柄）在使用后得到妥善清理。仅这两类问题就占据了研究人员发现的所有维护工作的近百分之六十。这表明，这些开发者最紧迫的日常工作仅仅是防止语言之间的连接断裂或发生泄漏。然而，当研究人员将这些现实世界中的问题与现有的已知“代码异味”列表进行对比时，他们发现了一个显著的差距。目前的目录主要由专家基于理论设计原则创建，仅涵盖了开发者正在修复的实际问题的百分之三十六。换句话说，现有的清单遗漏了开发者为保持软件健康所做的大部分工作。
研究人员意识到，缺失的问题并非随机错误，而是值得被命名的重复模式。他们发现，每当一个细节发生变化时，开发者往往必须对 Java 代码和 C 代码同时进行协调性的修改，这种情况使得更新过程缓慢且易错。他们还观察到，软件会在语言障碍之间暴露隐藏的内部细节，从而削弱系统的安全性和组织性。最后，他们注意到职责经常被分配到了错误的语言中，导致系统的一侧必须不断请求另一侧来完成其工作，这造成了不必要的复杂性。基于这些重复的观察，该团队提出了三个专门针对这些跨语言问题的代码异味新定义。他们将其命名为“跨语言霰弹式修改”（Cross-Language Shotgun Surgery），描述了需要同时更改多个文件的需求；“跨语言抽象泄漏”（Cross-Language Abstraction Leakage），指隐藏的细节被意外暴露；以及“职责分配错误”（Wrong Responsibility Allocation），指任务被分配到了错误的语言层。
这项工作将焦点从专家认为应该是问题的地方，转向了开发者实际在修复的问题。通过倾听软件本身的历史，研究人员表明，目前对多语言设计缺陷的理解是不完整的。现有的清单擅长捕捉简单的局部错误，但忽略了当两个不同的代码世界试图协同工作时所产生的更深层次的架构挑战。这些新定义为这些隐藏的挣扎提供了词汇，为开发者提供了一种在这些问题变得无法收拾之前识别并修复它们的方法。研究结论指出，要真正理解软件质量，我们不能只看静态代码，还必须观察那段漫长、混乱的、关于代码如何被维持生命并不断演进的历史。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。