《Bioinformatics Data Skills 2015

Bioinformatics Data Skills 2015.png

《Bioinformatics Data Skills 2015》第一章 1.7

1.7 健全研究的建议

强有力的研究主要是采用一系列的做法，这些做法可以帮助你克服一个沉默的错误不会混淆你的结果。如上所述，除了防止可怕的无声错误之外，大多数这些做法也是有益的 - 这更有理由包括在您的日常生物信息学工作中应用以下建议。

注重实验设计

强大的研究始于良好的实验设计。不幸的是，没有多少精彩的分析可以节省不良设计的实验。引用一位杰出的统计学家和遗传学家：在实验结束后咨询统计学家通常只是要求他进行验尸检查。他也许可以说实验死了。 -R.A.费舍尔

这句话贴近心脏；我已经看到项目落在我的桌子上准备分析，花了数千美元的顺序，但他们在抵达时完全死了。良好的实验设计并不难，但由于它基本上是一个统计主题，因此超出了本书的范围。我提到这个主题是因为遗憾的是，本书中没有任何其他内容可以保存不良设计的实验。在高通量研究中考虑实验设计尤其必要，因为技术“批处理效应”可能会使研究显着混淆（对此有所了解，参见Leek等，2010）。

大多数入门统计学课程和书籍涵盖了实验设计的基本主题。 Quinn和Keough的生物学实验设计和数据分析（剑桥大学出版社，2002年）是一本关于这一主题的优秀书籍。 Sarah Boslaugh的O'Reilly统计数据第二版的第18章也很好地介绍了基础知识。但请注意，基因组学实验中的实验设计是一种不同的野兽，并且正在积极研究和改进。确保您的数千美元实验能够发挥其潜力的最佳方法是查看当前最佳设计实践对您的特定项目的影响。咨询当地的友好统计学家，了解您在规划实验时可能遇到的任何实验性设计问题或疑虑，这也是一个好主意。

为人类编写代码，为计算机写入数据

调试的难度是首先编写代码的两倍。因此，如果您尽可能巧妙地编写代码，那么根据定义，您不够聪明，无法对其进行调试。 -Brian Kernighan

生物信息学项目可能涉及大量代码，而我们对bug的最佳防御之一就是为人类编写代码，而不是为计算机编写代码（Wilson等人，2012年的优秀文章中提到的一点）。人类正在进行调试，因此编写简单明了的代码可以使调试更容易。

代码应该是可读的，分解为小的包含组件（模块化），并且可重用（因此您不会重写代码来反复执行相同的任务）。这些实践在软件世界中至关重要，也应该应用于您的生物信息学工作中。评论代码和采用样式指南是提高代码可读性的简单方法。 Google提供多种语言的公共风格指南，可作为优秀的模板。为什么代码可读性如此重要？首先，可读代码使项目更具可重复性，因为其他人可以更容易地理解脚本的功能和工作方式。其次，在可读，评论良好的代码中查找和纠正软件错误要比凌乱的代码容易得多。第三，当代码得到充分评论和清晰编写时，将来重新访问代码总是更容易。编写模块化和可重用的代码只需要练习 - 我们将在本书中看到一些这方面的例子。

与代码相比，数据的格式应便于计算机的可读性。通常，我们作为人类以最大化其对我们的可读性的方式记录数据，但在计算机处理之前需要进行大量的清理和整理。计算机可读的数据（和元数据）越多，我们就越能利用我们的计算机来处理这些数据。

让您的计算机为您工作

人类做死记硬背活动往往会犯许多错误。让您的工作更加强大的最简单方法之一就是让您的计算机尽可能多地完成这项工作。这种自动执行任务的方法更加健壮，因为它可以降低您犯一个小错误的几率，例如意外地忽略文件或错误地命名输出。

例如，通过单独输入（或复制和粘贴）每个命令在20个不同文件上运行程序是非常脆弱的 - 在您处理的每个文件中，粗略错误的几率会增加。在生物信息学工作中，养成让你的计算机为你做这种重复性工作的习惯是很好的。而不是粘贴相同的命令20次，只是更改输入和输出文件，编写一个脚本，为您执行此操作。这不仅更容易且更不可能导致错误，而且还提高了可重复性，因为您的脚本可以作为您对每个文件所做的参考。

利用自动化任务的好处，需要在组织项目，数据和代码时加以考虑。像计算机（而不仅仅是人类）可以理解的一致方式命名数据文件，这样的简单习惯可以极大地促进自动化任务并使工作更容易。我们将在第2章中看到这方面的例子。

在代码和方法中做出断言并大声说话

当我们编写代码时，我们倾向于对数据进行隐式假设。例如，我们预计只有三个DNA链选项（正向，反向和未知），基因的起始位置小于终点位置，并且我们不能有负位置。我们对数据做出的这些隐含假设会影响我们编写代码的方式；例如，如果我们假设它不会发生，我们可能不会想到处理代码中的某种情况。不幸的是，这可能导致可怕的无声错误：我们的代码或程序接收超出我们预期值的值，行为不正确，但仍然在没有警告的情况下返回输出。我们防止此类错误的最佳方法是使用Python的assert（）和R的stopifnot（）等断言语句显式声明和测试我们对代码中数据的假设。

几乎每种编程语言都有自己的断言函数版本。这些断言函数以类似的方式操作：如果语句求值为false，则断言函数将停止程序并引发错误。它们可能很简单，但这些断言功能在强大的研究中是不可或缺的。在我的职业生涯早期，一位导师激励我采用相当自由地使用断言的习惯 - 即使看起来这句话绝对没有任何方式可能是错误的 - 但我仍然对这些被捕获的次数感到惊讶一个微妙的错误。在生物信息学（以及所有领域）中，我们尽可能地将可怕的无声错误转化为大声错误至关重要。

测试代码，或更好，让代码测试代码

软件工程师是一个聪明的人，他们采取让一个人的计算机将工作提升到新水平的想法。他们这样做的一种方法是让代码测试其他代码，而不是手工完成。测试代码的常用方法称为单元测试。在单元测试中，我们将代码分解为单独的模块化单元（这也具有提高可读性的副作用），并编写了测试此代码的其他代码。实际上，这意味着如果我们有一个名为add（）的函数，我们会编写一个名为test_add（）的附加函数（通常在单独的文件中）。此test_add（）函数将使用某些输入调用add（）函数，并测试输出是否符合预期。在Python中，这可能看起来像：

EPS = 0.00001 # a small number to use when comparing floating-point values

def add(x, y):
"""Add two things together."""
        return x + y

def test_add():
"""Test that the add() function works for a variety of numeric types."""
        assert(add(2, 3) == 5)
        assert(add(-2, 3) == 1)
        assert(add(-1, -1) == -2)
        assert(abs(add(2.4, 0.1) - 2.5) < EPS)

test_add（）函数的最后一行看起来比其他函数更复杂，因为它正在比较浮点值。在计算机上比较浮点值很困难，因为存在表示和舍入错误。然而，这是一个很好的提醒，我们总是受限于我们的机器可以做什么，我们必须在分析中考虑这些限制。

尽管科学代码更容易包含错误（因为我们的代码通常只运行一次才能生成出版物的结果，而且科学代码中的许多错误都是错误的），因此单元测试在科学编码中的使用要少于软件行业。无声）。我将此称为科学编码的悖论：科学编码容易出错的意味着我们应该尽可能多地利用测试而不是软件行业，但实际上我们做的测试（如果有的话）要少得多。这是令人遗憾的，因为现在很多科学结论都是大量代码的结果。

虽然测试代码是查找，修复和防止软件错误的最佳方法，但测试并不便宜。测试代码使我们的结果稳健，但它也需要相当多的时间。不幸的是，研究人员花费太多时间为他们编写的每一段代码组成单元测试。科学发展迅速，在编写和执行单元测试所需的时间内，您的研究可能会过时或被淘汰。一个更明智的策略是每次编写一些代码时考虑三个重要的变量：

• 其他代码调用此代码的次数是多少？
• 如果这段代码错了，对最终结果有多大损害呢？
• 如果发生错误，错误会有多明显？

测试一些代码的重要性与前两个变量成正比，与第三个变量成反比（即，如果一个bug非常明显，则没有理由为它编写测试）。我们将在本书的示例中使用此策略。

尽可能使用现有的库

每个初露头角的程序员的职业生涯都有一个转折点，他们在编写代码时感到很自在，并且想：“嘿，我为什么要使用这个库，我可以轻松地自己编写。”这是一种赋权的感觉，但有充分的理由让请改用现有的软件库。

与您自己编写的库相比，现有的开源库有两个优势：历史更长，受众更广。这两个优点都可以减少错误。软件中的错误类似于在大海捞针中找到针头的众所周知的问题。如果您编写自己的软件库（其中一些bug肯定会潜伏），那么您就是一个人正在寻找几根针。相比之下，开源软件库本质上已经有更多的人为这些针头寻找更长的时间。因此，在这些开源库中发现，报告和修复的错误比您自己的自制版本更容易发现。

这方面的一个很好的例子是在编写脚本以将核苷酸翻译成蛋白质时出现的潜在微妙问题。大多数具有一定编程经验的生物学家可以轻松编写脚本来完成此任务。但是在这些简单的编程练习背后隐藏着隐藏的复杂性，你可能不会考虑。如果您的核苷酸序列中含有Ns怎么办？还是Y？还是Ws？ Ns，Ys和Ws似乎不是有效的碱基，但它们是国际纯粹和应用化学联合会（IUPAC）标准模糊核苷酸，并且在生物信息学中完全有效。在许多情况下，经过良好审查的软件库已经找到并修复了这些隐藏的问题。

将数据视为只读

许多科学家花费大量时间使用Excel，没有点击会改变单元格中的值并保存结果。我强烈反对以这种方式修改数据。相反，更好的方法是将所有数据视为只读，并且只允许程序读取数据并创建新的独立结果文件。

为什么在生物信息学中将数据视为只读是重要的？首先，修改数据很容易导致结果损坏。例如，假设您编写了一个直接修改文件的脚本。在处理大文件的过程中，您的脚本会遇到错误并崩溃。因为您已修改了原始文件，所以无法撤消更改并重试（除非您有备份）！从本质上讲，此文件已损坏，无法再使用。

其次，当我们在适当的位置修改文件时，很容易忘记我们如何更改文件。与每个步骤都有输入文件和输出文件的工作流程不同，在适当位置修改的文件不会向我们提供任何有关我们已对其执行的操作的指示。如果我们忘记了我们如何更改文件并且没有原始数据的备份副本，那么我们的更改基本上是不可复制的。

将数据作为只读处理似乎与熟悉在Excel中广泛工作的科学家相反，但它对于强大的研究（并防止灾难，并有助于重现性）至关重要。最初的困难非常值得；除了保护数据免受损坏和不正确的更改外，它还可以提高可重复性。此外，分析的任何步骤都可以轻松重做，因为程序不会改变输入数据。

花时间将常用脚本开发到工具中

在您作为高技能生物信息学家的整个开发过程中，您最终会创建一些您将反复使用的脚本。这些脚本可能是从数据库下载数据，或处理某种类型的文件，或者只是生成相同的漂亮图形的脚本。这些脚本可以与实验室成员共享，甚至可以跨实验室共享。您应该付出额外的努力和注意力，使这些高使用率或高度共享的脚本尽可能健壮。在实践中，我认为这个过程是将一次性脚本转换为工具。

与脚本相比，工具被设计为一次又一次地运行。它们有详细记录，具有显式版本控制，具有可理解的命令行参数，并保存在共享版本控制存储库中。这些可能看起来像是微小的差异，但强有力的研究是关于做一些有利于防止错误的小事情。根据定义，您反复应用于众多数据集的脚本会影响更多结果，并且应该更加开发，因此它们更加强大且用户友好。对于与其他研究人员共享的脚本尤其如此，他们需要能够查阅文档并将您的工具安全地应用到他们自己的数据中。虽然开发工具比编写一次性脚本更耗费人力，但从长远来看，它可以节省时间并防止头痛。

让数据证明它是高品质的

当科学家考虑分析数据时，他们通常会考虑分析实验数据以得出生物学结论。然而，为了进行强大的生物信息学工作，我们实际上需要分析的不仅仅是实验数据。这包括检查和分析有关实验数据质量的数据，生物信息学程序的中间输出文件以及可能的模拟测试数据。这样做可确保我们的数据处理按预期运行，并体现生物信息学的黄金法则：不要相信您的工具或数据。

从不假设数据集是高质量的，这一点很重要。相反，数据的质量应该通过探索性数据分析（称为EDA）来证明。 EDA并不复杂或耗时，并且可以使您的研究更加健壮，以便在大型数据集中潜藏惊喜。我们将在第8章中了解有关使用R的EDA的更多信息。