注：个人能力有限，解释未必得当，若有错误请见谅。

文献来源：Ten Simple Rules for Reproducible Computational Research

我们在这里提出针对计算分析研究重复性的十条简单规则。这些规则的使用可以根据自己的研究情况进行调整。

Rule 1：记录每一个结果是如何产生的

当一个结果可能有潜在价值的时候，确保记录它是如何产生的。计算分析涉及多个连续的步骤，大量的中间步骤（简单命令、脚本、软件）、结果，无论是自动处理还是手动处理，我们都称这一系列步骤为分析流程。对于其中的每一步，你要确保可能会影响结果的步骤详情都被记录。如果分析是通过计算机软件执行的，一定要记录软件的名字、版本号以及输入使用的参数。虽然我们可以人工地记录处理的每一个步骤，写进说明文档，但它非常容易和我们最后使用的版本失去同步，从而导致无法重现结果。与其提供全部流程的分析说明文档，不如让分析流程可以直接执行重现，这样无论是自己还是他人都可以自动实现重复，这需要利用一些可执行的描述——脚本、编译文件或者存储在工作流程管理系统中的工作流程记录（GenePattern, Galaxy等）。

最低限度你也至少要充分地记录软件、参数以及手动处理过程的详情保证你在一年左右能够重复结果。

Rule 2：避免手动的数据操作步骤

尽可能地依赖软件而不是手动地对数据操作，手动操作不仅效率低而且容易出错、难以重复。如果手动操作不可避免，也要记录对哪些文件进行了移动和修改，为了什么目的。

Rule 3：对所有的外部软件版本进行存档

为了能够精确重复一个既定的结果，使用数据处理时对应的原始版本是非常有必要的。对于同一个软件不同的版本，输入输出可能会改变，而使用原始版本可以不用做任何修改。除此之外，数据处理可能会用到多种软件，而它们之间可能有版本依赖，所以对使用的软件版本进行记录或存档方便重复。为了确保使用软件未来的可用性，一种可用的策略是将软件和系统保存为虚拟镜像。

Rule 4：所有自定义脚本的版本控制

即使使用相同的参数与数据，对程序（自定义的脚本）的轻微的改动都有可能导致不可估量的后果，使得分析不可重现。标准的解决方案是用版本控制系统记录你代码的演变，比如Subversion，Git等。这些系统都简单易用，而且支持多平台，可以在整个开发过程中系统性地记录和存储代码的及其状态。

最低限度也要时时对脚本拷贝和存档。

Rule 5： 记录所有的中间结果，可能情况下使用标准文件格式

原理上只要记录了得到既定结果的所有的处理流程，所有相应中间结果也能够重现。而实际操作中，如果做到非常容易获取中间结果将会非常有价值。快速浏览中间结果可以揭示与假定之间的差异，发现bug和错误的揭示，而这通常在最后的结果中看不出来；其次，更能直观显示每一步备用程序和参数的结果；第三点，如果全部的流程不能执行，可以执行一部分；第四点，重复结果时可以追踪记录到出错或有问题的那一步；第五，可以针对某一个结果进行关键性的检查而不用所有的步骤都可执行。最低限度，在存储空间允许的情况下，对分析产生的任何中间结果进行存档。

Rule 6： 对于包含随机性的分析，记录设定的随机种子

有些分析和预测可能包含随机的元素，这意味着相同的程序每次执行结果可能会有所不同。一般程序软件都提供了设定随机种子功能，确保在进行相关分析时使用并记录。最低限度也要记录哪些步骤涉及了随机性分析。

Rule 7：总是存储绘图使用的原始数据

发表文章难免要多次修改图形，但大多数情况图形使用的原始数据是一致的，所以存储它有利于自己重复修改图形和创建新的图形，而不要重复整个分析，增加出错的可能。

Rule 8：生成分层的分析输出，允许对增加的细节进行检查

在文章中使用的最后结果可能是图形或表格，通常是高度总结的数据。当存储环境允许条件下，最好在生成主要结果时将所有底层数据的永久输出合并起来。一般而言，我们发现超文本文件html非常有用。当处理总结性的结果时，你至少应该做过一次生成、检查和研究总结中的具体数值。

Rule 9：将文本报告连接到底层结果

大致意思是一个典型的研究项目会有结果的大量不同分析和文本解释说明。结果通常在服务器或个人电脑的数据区域，而文本解释则经常在个人笔记、或与同事的邮件中。如果我们想要重新评估之前的解释或者允许你的同行自己进行评估，你需要将给定的文本说明（解释、声明、总结）与支持它的精确结果（图、表）连接起来。这个过程非常难或者容易出错，所以我们建议将文本报告连接到底层结果。它可以是指向具体结果的文件路径；或者是分析框架中结果的ID。

最低限度，你也应该提供充分的文本解释，保证未来也以追踪到它指向的部分结果。

Rule 10：提供脚本、运行和结果的公共存取

（没啥好说的，就是公开你的分析及结果）