Beyond Strict Rules: Assessing the Effectiveness of Large Language Models for Code Smell Detection
本文评估了四种大语言模型在检测 30 个 Java 项目中九种代码异味方面的有效性，结果表明，虽然它们擅长识别结构直观的异味，但将大语言模型与静态分析工具相结合的混合策略在大多数异味检测上表现出更优越的性能，尽管最终的最佳方法取决于优先考虑精确率还是召回率。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
大局观：寻找代码中的“坏习惯”
想象一下一个巨大的图书库（软件代码）。随着时间的推移，有些书变得很乱。它们可能章节过长、页面重复讲述同一个故事，或者角色过度依赖他人来完成自己的工作。在软件工程中，这些混乱的模式被称为代码异味（Code Smells）。它们不是会导致程序崩溃的 Bug，但它们就像是“坏习惯”，会让代码在日后难以修复、更新或理解。
多年来，我们一直使用静态分析工具（我们可以称之为“规则手册”）来发现这些异味。规则手册非常严格，它们遵循一份清单。如果一个方法超过 50 行，规则手册就会说：“这是一个长方法！”它很快，但有点“笨”。它可能会因为一个方法太长而将其标记为问题，即使这个方法本身完全没问题；或者可能会漏掉一个看起来很无辜但实际上很混乱的短方法。
最近，大语言模型（LLMs）（我们可以称之为“聪明的实习生”）变得非常出名。这些 AI 系统几乎可以像人类一样阅读和理解代码。这篇论文探讨的核心问题是：这些聪明的实习生能否比严格的规则手册更好地发现坏习惯？
实验：针对 30 个库的“口味测试”
为了找出答案，研究人员设计了一场大规模的口味测试。
- 菜单： 他们选择了 30 个流行的 Java 软件项目（就像选择 30 种不同类型的餐厅）。
- 菜单项： 他们寻找了 9 种特定的坏习惯（代码异味），例如：
- 长方法 (Long Method)： 一个试图承担过多职责的函数。
- 大类 (Large Class)： 一个充斥着过多职责的臃肿文件。
- 特征妒忌 (Feature Envy)： 一个函数把更多时间花在处理别人的数据而非自己的数据上。
- 评委： 他们并没有让 AI 盲目猜测。他们邀请了 76 名人类开发者（受过良好训练的学生）来手动检查 268 个代码片段，并决定：“这真的是一个坏习惯，还是没问题？”这创建了**“地面真值”（Ground Truth）**（即官方标准答案）。
- 参赛者： 他们让 4 种不同的聪明实习生（DeepSeek-R1, GPT-5 mini, Llama-3.3, 和 Qwen2.5-Code）与规则手册（传统的工具如 JDeodorant 和 PMD）进行对决。
结果：谁赢了？
结果既体现了“实习生们非常出色”，也体现了“规则手册仍有其地位”。
1. 简单任务：实习生表现亮眼
对于容易计数或测量的异味，聪明的实习生表现得非常出色。
- 类比： 如果坏习惯是“这本书有 500 页长”，实习生可以像规则手册一样数清页数，但他们能更好地理解上下文。
- 获胜者： 对于长方法和大类这类异味，AI 模型表现得非常强劲，通常能达到甚至超越严格工具的水平。
2. 复杂任务：取决于实习生
对于需要理解代码编写方式及其“原因”的异味，结果则褒贬不一。
- 类比： 想象故事中的一个角色与邻居聊得太多。这是“特征妒忌”（坏事）还是仅仅是良好的团队协作？规则手册可能会完全忽略它。一个聪明的实习生可能会说：“是的，这很糟糕！”而另一个则会说：“不，这没问题。”
- 发现： 不同的 AI 模型擅长不同的领域。例如，一个模型擅长发现“特征妒忌”，而另一个模型可能更擅长发现“紧密耦合”。没有一个单一的“超级 AI”能在所有方面都完美无缺。
3. 最难的任务：两者都感到吃力
对于最主观的异味，比如拒绝继承（Refused Bequest）（子类忽略了父类的规则）或霰弹式修改（Shotgun Surgery）（微小的改动会导致到处出错），规则手册和聪明的实习生都感到很吃力。
- 类比： 这些就像是群聊中微妙的社交尴尬。很难定义这种尴尬究竟在何时成为了一个问题。即使是最聪明的 AI 和最严格的规则手册，也很难在这些问题上达成一致。
秘密武器：“投票委员会”
研究人员尝试了一个聪明的技巧。他们没有只询问一个 AI 或一个规则手册，而是要求所有人（所有 4 个 AI + 2 个规则手册）对每一段代码进行投票。如果至少 3 个出 6 个说“这是一个异味”，那么就将其计为一个异味。
- 结果： 这种“委员会”方法在发现所有问题方面表现最好（高召回率/Recall）。它捕捉到了几乎所有的坏习惯，甚至是那些棘手的习惯。
- 代价： 因为它太渴望捕捉坏习惯，所以也会将一些干净的代码误标为“有异味”（假阳性/False Positives）。
- 教训： 如果你想确保不漏掉任何问题，请使用“委员会”。如果你想避免用虚假警报打扰你的团队，请为那个特定的工作挑选最合适的专家。
核心结论
- 对于简单的结构性问题（例如代码太长或太大），AI 是一个强大的工具，其表现与传统工具不相上下，甚至更好。
- 对于复杂的、依赖上下文的问题，专门的工具或特定的 AI 模型仍然比通用的“一刀切”方法更好。
- 最佳策略： 这取决于你的价值取向。
- 如果你追求安全性（发现尽可能多的问题），请结合 AI 和传统工具（即使用“委员会”）。
- 如果你追求精确度（避免虚假警报），请选择针对该特定类型异味表现最好的特定工具或 AI 模型。
简而言之，聪明的实习生已经准备好提供帮助了，但你最好知道该向哪位实习生请教哪种工作，或者让他们与老派的规则手册协同工作。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。