[Paper] 软件工程研究中开放科学的现状：ICSE 工件案例研究

Source: arXiv - 2601.02066v1

概述

本文研究了随软件工程论文一起提供的复制包（artifact）的可用性。通过尝试运行并复现 2015‑2024 年在 ICSE 论文中发布的 100 个 artifact 的结果，作者揭示了“开放科学”承诺与开发者在自己机器上实际能够运行之间的巨大差距。

关键贡献

• 大规模实证评估：对跨越十年的 100 个 ICSE 复现包进行评估。
• 量化指标：可执行性（40 % 可运行）、所需工作量以及可复现性（可运行工件中有 35 % 能复现原始结果）。
• 障碍分类法：五种修改类型和 13 项不同挑战（环境、文档、结构性问题）。
• 可操作的指南：为作者、评审人和会议组织者提供提升工件共享质量的建议。

方法论

1. 工件选择 – 作者收集了2015年至2024年期间正式链接到 ICSE 论文的所有复制包（总计 = 100）。
2. 执行尝试 – 在约 650 人小时的工作中，研究团队克隆了每个仓库，搭建了声明的环境，并尝试运行提供的脚本。
3. 工作量分类 – 根据所需的手动调试量（例如，安装缺失的库、修复路径问题），每次成功执行被标记为 低、中等 或 高 工作量。
4. 复现检查 – 对于可运行的工件，团队重新运行实验，并将输出与原论文报告的数值进行比较。
5. 问题分析 – 当执行失败时，研究人员记录根本原因，随后将其聚类为一系列常见的修改类型和挑战。

该过程刻意保持透明：所有日志、脚本和分类标准均随论文一起发布，使其他人能够复制本研究本身。

结果与发现

这意味着

• 可获得性 ≠ 可用性 – 即使作者提供了软件包，大多数开发者仍需投入相当的时间才能使其运行。
• 可复现性低于可执行性 – 只有三分之一的可运行工件实际产生了与论文相同的数值，表明存在隐藏的依赖或未记录的步骤。
• 常见痛点 – 问题分为五类修改（例如缺少依赖、硬编码路径、过时的库）和 13 种挑战类型，其中环境配置和文档不足最为常见。

实际意义

• 对工具开发者 – 在构建 CI 流水线或可复现性平台（如 ReproZip、基于 Docker 的运行器）时，研究强调了自动化环境捕获和依赖解析的必要性。
• 对会议组织者 – ICSE 及类似会议可以强制要求容器化工件（Docker、OCI）或可复现性徽章，要求提供最小化的“一键”执行测试。
• 对研究人员和工程师 – 指南建议采用可设计即可复现的实践：使用包管理器、固定版本、提供清晰的 README 步骤，并包含自动化的健全性检查脚本。
• 对行业从业者 – 在评估学术原型以供采纳时，团队应预留额外时间进行工件验证，或请求容器化演示以降低集成摩擦。

限制与未来工作

• 范围仅限于 ICSE – 研究结果可能无法推广到其他软件工程会议或跨学科会议。
• 二元可执行性度量 – 本研究将只要能运行的工件视为“可执行”，而不对部分成功进行评分（例如，运行后崩溃）。
• 人工工作量测量 – 工作量水平由研究团队判断；使用自动化工作量指标（例如手动命令的数量）可以提供更客观的数据。

未来的研究方向包括将分析扩展到其他会议，探讨容器化标准的影响，以及构建工具支持，在工件提交时自动标记已识别的 13 种挑战类型。

作者

• Al Muttakin
• Saikat Mondal
• Chanchal Roy

论文信息

• arXiv ID: 2601.02066v1
• 分类: cs.SE
• 出版日期: 2026年1月5日
• PDF: 下载 PDF