论文技术总结：基于提交消息的纠正性软件维护研究：一项系统性映射研究

论文标题：On the Use of Commit Messages for Corrective Software Maintenance: A Systematic Mapping Study
作者：Syful Islam, Stefano Zacchiroli (Télécom Paris, 法国)
发表会议：EASE 2026 (第 30 届软件工程评估与测试国际会议)

---

1. 研究背景与问题 (Problem)

纠正性软件维护 (Corrective Software Maintenance) 是软件生命周期中至关重要的环节，旨在交付后修复源代码中发现的缺陷，直接关系到软件质量、可靠性及用户满意度。在版本控制系统 (VCS) 中，提交消息 (Commit Messages) 是开发者记录变更意图、支持后续维护的核心文档。

尽管利用提交消息辅助纠正性维护已成为业界和学界的普遍实践，但现有的研究呈现出碎片化的特征：

• 缺乏对“提交消息如何在纠正性维护中被使用”这一领域的全面映射。
• 现有研究目标多样，方法论各异，缺乏系统性综述来总结其影响、趋势及最佳实践。
• 尚未有二次研究（Secondary Study）专门针对此主题进行全景式分析。

核心问题：提交消息在纠正性软件维护中的使用现状如何？其研究目标、使用的工件、方法论、利益相关者视角以及关键发现是什么？

---

2. 研究方法 (Methodology)

本研究采用 Petersen 等人提出的系统性映射研究 (Systematic Mapping Study) 方法，旨在对现有文献进行定性和定量的综合分析。

• 数据来源与筛选：

  • 检索范围：IEEE, ACM, Scopus, Springer, ScienceDirect, Wiley 等主流数字图书馆。
  • 时间跨度：2004 年至 2025 年 5 月。
  • 筛选流程：
    1. 自动查询：基于 PICO 框架（人口、干预、比较、结果）构建查询字符串，聚焦于“提交/提交消息”与“软件/代码/仓库”等上下文术语。
    2. 去重与噪音移除：基于标题和 DOI 去重，人工检查元数据噪音。
    3. 标题与摘要筛选：应用纳入/排除标准（如：必须包含纠正性维护贡献、英文、同行评审、全文可用）。
    4. 全文筛选：两位作者协作评估，确认提交消息是否作为方法论的一部分被挖掘，且与纠正性维护对齐。
    5. 回溯滚雪球 (Backward Snowballing)：对入选文献的参考文献进行人工检查，以补充遗漏研究。
  • 最终样本：共纳入 97 篇 主要研究论文 (Primary Sources)。

• 研究问题 (RQs)：

  • RQ1: 研究发表于何时何地？（趋势与领域）
  • RQ2: 研究目标是什么？（如缺陷分析、修复识别等）
  • RQ3: 使用了哪些软件工件？（如代码变更、Issue 追踪等）
  • RQ4: 使用了什么研究方法？（如仓库挖掘、NLP、AI/ML 等）
  • RQ5: 考虑了哪些人类利益相关者视角？（开发者、维护者、研究者）
  • RQ6: 关于提交消息如何影响纠正性维护的关键发现是什么？

• 数据提取：通过三轮迭代，由两位作者协作提取数据，统一分类标准（如将“缺陷预测”和“缺陷定位”合并为“缺陷识别与定位”）。

---

3. 主要贡献 (Key Contributions)

1. 首个系统性映射研究：这是第一篇专门针对“提交消息在纠正性软件维护中的应用”的二次研究，填补了该领域的知识空白。
2. 公开的可复现包：提供了一个包含 97 篇分析论文数据集和结构化分类法（Taxonomy）的公开仓库，支持后续研究复现。
3. 全景式分析：系统梳理了该领域近 20 年的研究趋势、目标分布、技术栈及利益相关者角色。
4. 实践建议：基于实证结果，为开发者、维护者和研究者提供了具体的改进建议。

---

4. 研究结果 (Results)

4.1 发表趋势与领域 (RQ1)

• 时间趋势：研究始于 2004 年，呈现持续增长态势，2022-2023 年出现显著峰值。2024-2025 年的下降主要归因于数据库索引延迟。
• 发表 venues：主要集中在软件工程顶级会议（如 ICSE, MSR, FSE, SANER）和期刊（如 TSE, EMSE），表明该主题在实证软件工程社区中高度相关且成熟。

4.2 研究目标 (RQ2)

研究目标主要集中在以下四大主题：

1. 缺陷分析 (Bug Analysis, 53 篇)：占比最大，包括缺陷识别与定位（40 篇）、缺陷分类（Triaging, 3 篇）。重点在于通过早期识别提高软件可靠性。
2. 缺陷修复识别 (Bug Fix Identification, 26 篇)：包括安全补丁识别（18 篇）和稳定补丁识别（2 篇）。
3. 自动化程序修复 (Automated Program Repair, 7 篇)：利用提交消息辅助生成补丁。
4. 安全开发实践 (Security Development Practices, 6 篇)：较少被关注，涉及漏洞引入原因及安全消息规范。

• 发现：大部分研究集中在缺陷识别，而自动化修复和安全实践相对较少。

4.3 软件工件 (RQ3)

• 最常用组合：{提交消息，代码变更 (Code Changes/Diffs)} 是最主导的工件组合模式。
• 其他工件：问题追踪系统 (Issue Tracking, 30 篇)、开发者指标 (18 篇)、漏洞信息 (16 篇)。
• 发现：单独使用提交消息的情况较少，通常需结合代码变更（Diff）才能有效支持维护任务。Issue 追踪信息常与代码变更协同使用。

4.4 研究方法 (RQ4)

• 主导方法：仓库挖掘 (Repository Mining) 是基础（89 篇）。
• 技术栈：自然语言处理 (NLP, 82 篇) 和 人工智能/机器学习 (AI/ML, 72 篇) 是最常用的辅助技术。
• 模式：最常见的模式是 {仓库挖掘 + NLP + AI/ML} 的组合。人工检查 (Manual Inspection) 用于深度分析，社区反馈和受控实验较少见。

4.5 利益相关者 (RQ5)

• 开发者 (Developers, 81 次提及)：占据绝对主导地位，是纠正性维护策略的核心塑造者。
• 研究者 (Researchers, 48 次)：常与开发者并列，强调应用研究。
• 维护者 (Maintainers, 19 次)：提及较少，主要集中在稳定性和安全视角的研究中。

4.6 关键发现 (RQ6)

• 价值：提交消息携带关键语义信息，能显著提升缺陷预测、补丁识别和自动化修复的准确性。
• 局限性：现有提交消息往往缺乏必要的细节（如上下文、修复理由），导致自动化模型准确率受限。
• 安全视角：安全相关的提交消息常缺乏显式的漏洞引用（如 CVE ID），依赖隐式词汇，阻碍了自动化漏洞检测。
• 情感因素：提交消息中的情感色彩和开发者情绪也能反映软件质量和团队协作动态。

---

5. 意义与建议 (Significance & Recommendations)

5.1 理论意义

本研究证实了提交消息在软件演化过程中的核心地位，但也揭示了当前“消息质量”与“维护需求”之间的差距。它强调了将自然语言（消息）与代码语义（Diff）结合的重要性。

5.2 实践建议

• 对开发者：
  • 遵循严格的提交消息规范（如 Conventional Commits），确保语义与代码变更对齐。
  • 在修复 Bug 时，明确包含修复理由、上下文解释及相关的 Issue ID。
  • 安全修复应明确提及安全漏洞类型（如 CVE ID），避免隐藏漏洞性质。
• 对维护者：
  • 为新项目制定明确的提交消息指南和示例。
  • 在代码审查中，严格检查提交消息的结构和完整性，特别是针对新人的贡献。
• 对研究者：
  • 标准化提交消息的模板和最佳实践，以辅助自动化工具。
  • 在构建分类器时，注意预处理中的缩写处理（如 VRSN, RLS）。
  • 探索结合补充信息（如测试数据、Issue 内容）来丰富提交消息的上下文。
  • 进一步研究提交消息中的情感因素对团队协作的影响。

5.3 未来研究方向

1. 缩小纠正性维护目标与利益相关者实际需求之间的差距。
2. 深入研究遵循官方提交指南的利弊权衡，探索理想的 VCS 历史形态。
3. 通过访谈或调查利益相关者，三角验证研究发现，量化消息质量对维护任务的具体影响。

---

总结：该论文通过严谨的系统性映射，揭示了提交消息在纠正性维护中的巨大潜力与当前不足。它指出，虽然基于仓库挖掘和 AI/ML 的技术已能有效利用提交消息，但消息本身的质量（信息丰富度、结构化程度） 仍是制约自动化维护效果的关键瓶颈。提升提交消息的规范性是改善软件维护效率的必由之路。