这篇论文就像是一次对软件工程界“公开分享”风气的大体检。
想象一下，在软件研究领域，科学家们（研究人员）就像是在做各种复杂的烹饪实验。他们发明了新菜谱（算法或工具），并在顶级烹饪大赛（ICSE 会议）上展示。为了证明自己的菜是真的好吃、不是作弊，他们被要求把完整的食谱、食材清单和烹饪步骤（也就是“复制包”或“复制件”）打包好，免费分享给所有人。
这篇论文的作者们（来自萨斯喀彻温大学的三位研究员）决定：“既然大家都说要分享，那我们就真的去尝尝这些‘外卖’，看看能不能做出来，做出来的味道是不是和作者说的一样。”
他们花了大约650 个小时（相当于一个人全职干了快一年），尝试运行了100 份过去十年里在 ICSE 会议上发表的“食谱包”。
以下是他们发现的“厨房真相”，用大白话和比喻来解释：
1. 现状：虽然“外卖”很多，但能吃的很少
- 现象：以前大家只把菜名写在论文里，现在大家确实开始把“食谱包”挂在网上了。从 2015 年到 2024 年，挂出来的包越来越多。
- 真相：但是，只有 40% 的包能真正“跑起来”（就像你拿到食谱，却发现缺了关键的锅，或者步骤写错了，根本做不出菜）。
- 有 36% 的包完全打不开（就像食谱被撕了一半，或者食材全烂了）。
- 有 24% 的包只能做出一部分（比如汤做好了，但配菜没熟）。
- 只有 40% 的包能完整运行。
2. 难度：想“吃”到这些菜，你得先当“修理工”
即使那些能运行的包，也绝不是“开箱即用”的。
- 比喻：这就好比你买了一个号称“傻瓜式”的组装家具，结果发现螺丝少了一半，说明书是乱码，而且还需要你自备一台特殊的电钻。
- 数据：
- 只有 32.5% 的包不需要改任何东西就能直接运行（这是极少数幸运儿）。
- 剩下的 67.5% 都需要你动手修改。有的只是改改路径（低难度），有的需要重写代码、解决版本冲突（高难度）。
- 作者们为了运行这些包，花费了大量精力去“修修补补”，就像在厨房里一边做饭一边还要自己造锅、找食材。
3. 为什么“做不出来”？（三大拦路虎）
作者们把导致失败的原因归纳为三类，就像做饭失败的三个原因：
原因一：环境没配好（缺锅少灶）
- 比喻：食谱上说“用大火炒”，但没告诉你你的炉灶是电磁炉还是煤气灶，也没说需要多少度的油。很多包缺少具体的操作系统版本、硬件要求（比如显卡型号）或软件依赖。
- 结果：你在 Windows 上跑，作者是在 Linux 上跑的；你的 Python 是 3.10 版，他的是 3.6 版。一跑就报错。
原因二：说明书太烂（乱码食谱）
- 比喻：食谱上写着“加适量盐”，但没写多少克；或者步骤是“先切菜，再点火，然后……哦对了，忘了说要把菜洗了”。
- 结果：很多包没有文档，或者文档含糊不清，甚至关键步骤直接缺失。作者们只能靠猜，猜错了就失败。
原因三：食材过期或丢失（缺斤少两）
- 比喻：食谱里提到了“特制酱料”，但链接点进去是 404 错误；或者代码里引用了作者电脑里才有的文件，没上传到网上。
- 结果：代码和依赖项不匹配，或者关键数据文件找不到了。
4. 最扎心的发现：就算做出来了，味道也不对！
这是论文最惊人的发现。
- 比喻：假设你千辛万苦，修好了锅，补全了食谱，终于把菜做出来了。结果一尝，味道和作者描述的不一样！
- 数据：在那些成功运行的 40 个包里，只有 35% 的结果和论文里写的一模一样。
- 这意味着，超过一半的成功运行，其实并没有真正复现出作者当年的实验结果。
- 原因可能是：作者没提供验证结果的脚本，或者结果本身就不稳定。
5. 作者给出的“厨房建议”（三条行动指南）
为了让未来的“食谱”更好用，作者提出了三条建议：
写一份完美的说明书（G1）：
- 不要只给代码。要像写产品说明书一样，包含：项目是干嘛的、需要什么电脑配置、怎么安装、怎么运行、怎么验证结果。
- 比喻：就像宜家家具，不仅要给木板，还要给详细的图纸、螺丝型号和组装视频。
在“干净”的厨房里测试（G2）：
- 作者们在提交前，要在一个全新的、没装过乱七八糟东西的环境里试跑一遍。
- 比喻：别在你自己那台装了无数插件、缓存了一堆旧文件的电脑上跑，要换个新电脑试试，确保没有“隐形依赖”。
既给“半成品”也给“原材料”（G3）：
- 最好同时提供容器化环境（比如 Docker，就像把整个厨房打包成一个盒子，里面锅碗瓢盆都配好了，直接拿来就能用）和源代码（让你可以修改和扩展）。
- 比喻：既给你一份“微波炉加热即食”的套餐，也给你一份“生食材 + 详细菜谱”，满足不同人的需求。
总结
这篇论文告诉我们：在软件科学界，“分享”只是第一步，“能跑”和“能复现”才是真本事。
目前的情况是，虽然大家很热情地分享“食谱”，但很多都是“半成品”甚至“残次品”。如果不改进文档质量、不标准化环境配置，所谓的“开放科学”就只是一句空话。作者希望通过这次“体检”，让未来的研究更透明、更可信，让后来者不再需要花几个月时间去修一个本该能直接运行的代码包。
软件工程研究中开源科学现状：ICSE artifacts 案例研究技术总结
1. 研究背景与问题 (Problem)
尽管开源科学（Open Science）在软件工程（SE）领域日益受到重视，顶级会议（如 ICSE）也强制或鼓励作者提交复制包（Replication Packages），但这些共享资源的实际可用性（可执行性）和结果的可复现性仍然缺乏深入评估。
- 核心痛点：现有的研究多关注“是否共享”（Availability），而忽视了“是否可用”（Usability）。许多共享的代码包存在环境配置缺失、文档不全、依赖冲突等问题，导致其他研究者无法运行或复现原始结果。
- 研究缺口：缺乏大规模、实地的（Hands-on）评估，以量化复制包的可执行程度、所需的修改工作量以及导致执行失败的具体障碍。
2. 研究方法 (Methodology)
本研究对过去十年（2015–2024）发表的 100 个 ICSE 研究论文复制包进行了全面的实证评估。
2.1 数据集构建
- 来源：从 2015 至 2024 年的 ICSE 研究轨道论文中收集了 1,372 篇论文。
- 筛选：识别包含复制包链接的论文（1,085 篇），进一步筛选出链接有效且包含可执行组件（代码、脚本等）的论文（796 篇）。
- 抽样：采用分层随机抽样（Stratified Random Sampling），按年份比例选取了 100 个样本进行深度分析，以确保时间跨度的代表性。
2.2 执行与评估流程
研究团队投入了约 650 人时，在隔离环境中手动执行这些 artifacts。
- 执行环境：使用了 7 台不同配置的机器（涵盖 Windows, Ubuntu, macOS，配备不同 GPU），以模拟多样化的硬件环境。
- 执行策略：
- 文档审查：阅读 README 等文档，理解执行流程。
- 环境搭建：使用 Docker、Conda 等工具构建隔离环境，处理依赖缺失。
- 尝试执行：运行脚本或工具。
- 故障排查与修复：若执行失败，记录错误原因并进行修复（修改代码、配置或环境）。
- 标签分类：
- 可执行性 (Executability)：完全可执行、部分可执行、不可执行。
- 努力程度 (Effort)：低（<2 小时）、中（2-8 小时）、高（>8 小时）。
- 修改类型 (Modifications)：环境设置、指令修改、源代码修改、文件组织、配置文件调整。
- 可复现性评估 (Reproducibility)：对于可执行的 artifacts，对比其输出结果与论文原始报告，判断是否完全复现、部分复现或无法验证。
3. 关键贡献 (Key Contributions)
- 大规模实证评估：首次对 ICSE 过去十年的 100 个复制包进行了系统的“动手”执行和复现评估。
- 分类学构建：
- 识别了 5 大类、14 种具体类型的修改需求（如依赖冲突、路径错误）。
- 归纳了 3 大主题、13 种具体障碍导致执行失败（如文档缺失、环境配置不明）。
- 可复现性量化：揭示了“可执行”并不等同于“可复现”，量化了结果复现的成功率。
- 提出行动指南：基于发现提出了三条改进开源科学实践的具体指南。
4. 主要研究结果 (Key Results)
4.1 可执行性现状 (RQ1)
- 总体可执行率低：在 100 个样本中，仅有 40% (40 个) 的 artifacts 能够完全执行。
- 24% 部分可执行，36% 完全不可执行。
- 尽管 2023-2024 年 artifacts 的共享率很高，但可执行性并未显著提升，甚至 2024 年完全可执行率仅为 31.82%。
- 修改成本高：
- 即使在 40 个可执行的 artifacts 中，仅 32.5% 无需任何修改即可运行。
- 82.5% 的可执行 artifacts 需要中等到高强度的修改（如修改源代码、解决复杂的环境冲突）。
- 对于不可执行的 artifacts，研究者仍花费了大量时间（平均 52.78% 投入了中/高努力）进行排查，最终因无法修复而放弃。
4.2 修改类型与障碍 (RQ2 & RQ3)
- 主要障碍：
- 环境设置问题 (91.67% 的失败案例)：缺乏操作系统细节、硬件要求（GPU/RAM）、依赖版本信息。
- 文档不足 (70% 的失败案例)：指令模糊、关键步骤缺失、无文档。
- 组件缺失或过时：数据集丢失、脚本未更新、配置不一致。
- 常见修改：
- 环境相关修改占比最高（57%），主要是安装缺失依赖和解决版本冲突。
- 指令修改（31%）和源代码修改（22%）也较为常见。
4.3 可复现性 (RQ4)
- 复现率极低：在 64 个可执行（含部分可执行）的 artifacts 中，仅有 14% 能够完全复现原始结果（无需修改或仅需微调）。
- 完全可复现：8%
- 部分可复现：16%
- 不可复现/无法验证：剩余大部分。
- 完全可执行不等于可复现：即使在 40 个完全可执行的 artifacts 中，只有 35% 复现了原始结果。
- 关键原因：缺乏验证步骤（Validation Steps）、输出格式不明确、缺少参考结果。
5. 意义与行动指南 (Significance & Guidelines)
本研究揭示了 SE 领域开源科学在“可用性”和“可复现性”之间存在巨大鸿沟。为了改善这一现状，作者提出了三条可操作的指南 (Actionable Guidelines)：
提供全面且结构化的文档 (G1)：
- 必须包含五个核心组件：项目元数据、系统规格（OS/硬件/版本）、安装与环境设置、执行步骤、验证步骤。
- 数据支持：包含所有 5 个组件的 artifacts，其可执行率高达 85.7%，可复现率达 83.3%。
避免配置泄露 (G2)：
- 作者应在干净、隔离的环境中测试复制包，确保不依赖本地隐式配置（如本地路径、缓存工具、未记录的依赖）。
结合容器化环境与可访问源代码 (G3)：
- 容器化（如 Docker）能显著提高可执行性（67.47% vs 31%）和可复现性。
- 源代码保证了透明度和长期适应性。
- 建议同时提供两者：容器降低运行门槛，源码支持调试和扩展。
6. 结论
共享 artifacts 仅仅是第一步。如果缺乏完善的环境说明、依赖管理和验证机制，这些资源将无法被有效利用，从而阻碍科学进步。本研究通过量化分析，强调了从“共享”向“可执行、可验证、可复现”转变的紧迫性，并为作者、会议组织者和社区提供了具体的改进路径。研究团队还公开了包含 100 个 artifacts 详细执行日志和元数据的复制包，作为开源科学实践的基准。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。