研究中的软件维护

Konrad Hinsen 撰写，发布于 2014 年 2 月 26 日的《研究中的软件维护》。

软件维护是科学软件开发人员经常面临的困难之一。这是一项重要的活动，但可能需要花费大量时间，而且在今天的评估程序中很难获得回报。如果您管理一个大型软件项目，获得维护资金通常很困难。鉴于软件维护很困难，且本质上不具有科学研究意义，我们应该问自己为什么它是有必要的，以及我们是否可以采取一些措施来减少对维护的需求。

首先，什么是软件维护？《韦氏词典》将动词“maintain”（维护）定义为通过修理、纠正问题等来保持（某物）处于良好状态。这对于因机械磨损等原因而随时间恶化的技术设备来说是有意义的。软件不会恶化，因此维护在应用于软件时必须具有不同的含义。我不知道是否有任何共识定义，所以我在这里给出我自己的定义：软件维护包括出于以下两个原因之一修改软件：

1. 修复错误（Bugs）。
2. 保持软件在不断演进的计算环境中可用。

有些人会在此列表中添加功能增强，但从任何意义上来说，这些都不是真正的维护，而是改进。特别是在科学软件的情况下，新功能通常意味着新的科学发现。

首先是错误。与任何软件一样，我们希望修复科学软件中的错误，以便将来获得更好的结果。然而，如果有任何已发表的科学研究使用过该版本，我们也希望保留这个有缺陷的版本。这纯粹是一个诚实和保存科学记录的问题：如果研究结果有可能受到软件错误的影响，那么查看该研究的人应该能够发现这一点。他们应该能够访问与最初使用的完全相同的软件，而不仅仅是今天改进后的继任版本。因此，保留研究中使用的代码实际上比修复错误更重要。

ActivePapers 的设计就考虑到了这一目标：ActivePaper 中的任何计算数据项都链接到生成它的软件。此外，此链接在发布后严格不可修改，因为 ActivePapers 的发布就像文章的电子副本一样，并通过 DOI 引用。您可以在发布前作弊，通过修改 ActivePaper 来达到欺诈的特定目的。ActivePapers 不支持此类行为，但也不采取任何措施来防止欺诈。可以通过使用哈希值保护出处信息来添加此类功能，但我希望这不是必需的。

Related: Dataquest — Project-based data-science paths with a guided terminal and real datasets.

第二个问题，不断演进的计算环境，是一个更微妙的问题。计算机世界中的一切（计算机、操作系统、编译器、语言定义、库……）都在快速变化，这是一个客观事实，其结果是一段给定的源代码在几年后不太可能按原样工作。发生这种情况有两个原因：(1) 技术进步带来了更好的计算机和软件，这是人们想要的；(2) 没有人对计算平台的稳定性具有既得利益，也没有能力实现它。对于硬件供应商和商业软件供应商来说，快速变化是确保客户购买新机器并定期更新许可证的最佳方式。

当然，至少有一个社区对计算平台的稳定性有着既得利益：计算科学社区。如果我们能够在 20 年后无需修改地运行我们的软件，并得到相同的结果，我们会很高兴。我们不想进行软件维护，而且我们大多数人都无法合理地在个人直接需求之外，维护他们为自己的研究而开发的软件。期望任何人维护别人的软件就更不合理了，例如现在在工业界工作的研究生留下的软件。

在实践中，只有广泛使用的社区软件才能得到足够长时间的维护。但即使是使用广泛且经过维护的软件包的研究项目，通常也需要一些特定于项目的软件，至少是几个 shell 脚本。这就是计算研究的可重复性如此糟糕的原因之一。

Worth a look: Coursera Plus — One subscription for university-backed Python and data-science certificates.

科学界可以为此做点什么吗？我相信可以，但我不乐观它会在不久的将来采取行动。科学家很可能会继续使用商用硬件进行科学计算，这意味着他们将不得不接受硬件和相关系统软件的演进，而这是他们无法控制的。然而，他们可以在这些不断演进的平台之上构建一个稳定的平台，至少对于他们工作的纯计算部分来说是这样。

从根本上讲，所有图灵完备的软件表示法都是等效的，并且可以相互转换。在实践中，性能考虑对代码转换施加了限制，但仍然可以定义一种代码表示，它可以高效地转换为各种底层硬件和系统软件，从而保持稳定。两个现实生活中的例子是 JVM 字节码和 LLVM 的中间形式（intermediate form）。JVM 字节码已经存在 20 年了，并且已被证明非常稳定。LLVM 的中间形式并非旨在稳定，这是因为 LLVM 的开发人员不想通过承诺一个稳定的表示来限制他们未来的选择。Google 的 PNaCl 项目试图忽略这个警告，并以一种只有在保持稳定时才有意义的方式使用 LLVM 代码。时间会告诉我们这将如何发展。

科学界可以基于现有方法的经验来定义自己的中间代码表示，并为其科学应用优化平台。但是，正如我上面所说，我对这种情况的发生并不乐观。这需要几个大型研究和资助组织长期致力于维护这个平台数十年。我相信这在经济上是合理的，因为我确信维护一个平台比维护大量科学软件包并不断重写那些未维护的软件包更便宜。但这需要一定程度的共识和承诺，这在科学界是罕见的；这种情况只发生在像 CERN 这样少数几个巨型设施中。

稳定平台提供的重要优势，正是第一个 ActivePapers 版本围绕 JVM 设计的原因。不幸的是，JVM 在科学计算中并不流行。这通常被解释为缺乏性能，尽管这种论点不再像以前那样有效。此外还存在一些设计问题，特别是关于浮点运算的问题，但对于 C 或 C++ 等流行语言也可以这么说，而这并没有阻止科学家使用它们。

实际上更有用的 ActivePapers Python 版本构建在由 Scientific Python 生态系统（特别是 Python、NumPy 和 h5py）定义的平台上。事实证明，该平台在过去具有一定的稳定性，而向 Python 3 的过渡是不稳定的主要事件。科学的时间尺度

资料来源和进一步阅读

• 软件维护 — 维基百科：软件维护是指软件交付后的修改。与新开发相比，软件维护通常被认为是技能较低且回报较低的…

进一步阅读

• SciPy — 维基百科