Exploring the Garden of Forking Paths in Empirical Software Engineering Research: A Multiverse Analysis
该研究通过对一篇实证软件工程论文进行多宇宙分析，揭示了数据分析中的多种合理选择会导致截然不同的结论，从而呼吁研究者通过稳健性检验和明确论证来增强研究的可复现性与可靠性。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
这是一篇关于软件工程研究（特别是“挖掘软件仓库”领域）的论文，它揭示了一个令人惊讶且有些令人担忧的现象：即使面对完全相同的数据，只要研究人员在分析过程中做出一点点不同的“合理”选择，最终得出的结论就可能完全不同，甚至截然相反。
为了让你轻松理解，我们可以把这篇论文的核心思想比作**“在迷宫中找出口”或者“烹饪同一道菜”**。
🍳 核心比喻：同一份食材，不同的厨师
想象一下，你给 100 位顶级厨师（研究人员）提供完全相同的一篮食材（原始数据）和同一个任务（比如：做一道“西红柿炒蛋”，并判断这道菜是否好吃）。
- 原本的情况：大家认为，只要食材一样，做出来的味道应该差不多。
- 现实的情况（这篇论文发现的）：
- 厨师 A 决定把鸡蛋打散前多搅拌 5 下。
- 厨师 B 决定用大火炒 30 秒，而厨师 C 决定用中火炒 1 分钟。
- 厨师 D 决定加盐，厨师 E 决定加糖（虽然都是“合理”的调味选择）。
- 厨师 F 决定把西红柿去皮，厨师 G 决定不去皮。
结果是什么？
这篇论文发现，在 3000 多种不同的“烹饪组合”（分析路径）中，只有 6 种（不到 0.2%）做出来的味道和原作者（最初的研究者）做的一模一样！
- 有的厨师做出来的菜是咸的（结论支持原观点）。
- 有的厨师做出来的菜是苦的（结论完全相反）。
- 有的厨师甚至把菜炒糊了（模型无法运行，得出无效结论）。
🌳 什么是“分岔路径的花园”？
论文标题里的“分岔路径的花园”（Garden of Forking Paths）是一个著名的比喻。
想象你走进一个巨大的花园，你的目标是找到“真理”（正确的研究结论）。
- 每当你走到一个路口，你都有很多条路可以选。
- 比如：是走左边（用平均值）还是右边（用中位数）？是穿短袖（排除 15 天数据）还是穿长袖（排除 30 天数据）？
- 每一条路看起来都是合理的，没有哪条路是“错”的。
- 但是，你走的每一条路，都会把你带向不同的风景。
这篇论文就是那个“分岔花园”的探险家。他们拿着一个已经发表的研究（原作者走了一条路，看到了“风景 A"），然后重新走遍了所有其他合理的路。结果发现，绝大多数路通向的风景都和原作者看到的完全不同。
🔬 这篇论文具体做了什么？
- 选了一个案例：他们选了一篇已经发表的软件工程论文。这篇论文研究了“引入持续集成（CI）工具”后，代码审查（Code Review）发生了什么变化。
- 找出 9 个关键决策点：研究人员在分析数据时，必须做 9 个关键决定。例如：
- 时间单位是算"30 天”还是"7 天”？
- 要不要把干预前后的几天数据（不稳定期）剔除？
- 是用“平均值”还是“中位数”来代表数据？
- 统计模型怎么拟合？
- 计算所有可能性：这 9 个决定，每个都有几种合理的选项。组合起来，竟然产生了 3,072 种 不同的分析方案（3072 个“宇宙”）。
- 重新跑一遍：他们把这 3072 种方案全部在原始数据上跑了一遍。
📉 惊人的发现
- 极低的复现率：在 3072 种方案中，只有 6 种 得出了和原论文一样的结论。
- 结论反转：在大约 33% 的方案中，结论变成了“完全相反”（比如原论文说 CI 减少了沟通，新方案却说 CI 增加了沟通）。
- 结论消失：在另外 33% 的方案中，根本得不出任何显著结论（数据不支持任何说法）。
- 最脆弱的环节：研究发现，“时间跨度”的选择（比如是看 30 天还是 45 天）对结果影响最大。哪怕只是稍微改变一下时间窗口，结论就会天翻地覆。
💡 这对我们意味着什么？
这就好比我们在看新闻或科学报告时，如果作者说“根据数据分析，A 导致了 B"，我们以前会觉得很确定。但这篇论文告诉我们：
“等等！如果作者当时稍微换一种‘合理’的分析方法，结论可能就不是 A 导致 B，而是 B 导致 A，或者根本没关系。”
这意味着，很多现有的软件工程研究结论可能非常脆弱（Fragile）。它们不是绝对真理，而只是“分岔花园”中某一条特定路径上的风景。
🛠️ 作者的建议：如何修好这个花园？
作者没有只是抱怨，还提出了两个解决方案：
“多宇宙分析”（Multiverse Analysis）：
就像我们在做菜时，如果不确定哪种做法最好，不如把几种合理的做法都做一遍，看看结果是否稳定。如果不管怎么变，味道都一样，那结论才靠谱。如果一变就变味，说明结论不可靠。- 建议：研究人员在发表文章时，应该展示这种“多宇宙”测试，告诉读者：“看，即使我换了这些合理的方法，结论依然成立。”
“理由阶梯”（Justification Ladder）：
作者设计了一个梯子，用来衡量研究人员做决定时的理由够不够硬：- 第 1 级（Implicit/隐含）：随便选的，或者软件默认设置（比如默认保留 2 位小数）。（最弱）
- 第 2 级（Conventional/惯例）：因为大家都这么做，所以我也这么做。
- 第 3 级（Heuristic/经验法则）：我觉得这样比较合理。
- 第 4 级（Empirical/实证）：我根据数据特征专门测试过，这样选最好。
- 第 5 级（Causal/因果理论）：我有坚实的理论模型，证明必须这样选。
- 建议：研究人员应该努力爬得更高，不要只停留在“大家都这么做”或“默认设置”上，要给出更有力的理论或数据支持。
🎯 总结
这篇论文就像给软件工程界敲了一记警钟：
数据很丰富，但分析数据的方法太灵活了。 这种灵活性让研究人员在不知不觉中（甚至无意识地）“挑选”出了他们想要的结论。
一句话概括：
在软件研究中，“怎么做”往往比“做什么”更能决定结果。为了得到更可靠的科学结论，我们需要更透明地展示所有可能的分析路径，并为我们做的每一个选择提供坚实的理由，而不是仅仅依赖“惯例”或“默认设置”。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。