20

我来自计算机科学。背景，但我现在正在做基因组学。

我的项目包括许多生物信息学，通常涉及：比对序列、比较序列和各种基因组注释特征之间的重叠等，来自不同类别的生物样本、时间进程数据、微阵列、高通量测序（“next-代”排序，虽然它实际上是当前一代）数据，这种东西。

这种分析的工作流程与我在计算机科学研究期间所经历的完全不同：没有 UML 和精心设计的对象，闪耀着崇高的优雅，没有版本管理，没有适当的文档（通常根本没有文档），没有软件工程全部。

相反，每个人在这个领域所做的就是一个接一个地破解一个 Perl 脚本或AWK -one-liner，通常用于一次性使用。

我认为原因是输入数据和格式变化如此之快，问题需要尽快回答（截止日期！），似乎没有时间组织项目。

一个例子来说明这一点：假设你想写一个光线追踪器。您可能首先会在软件工程上投入大量精力。然后对其进行编程，最后以某种高度优化的形式。因为你会无数次地使用光线追踪器来处理不同的输入数据，并且会在未来几年内对源代码进行更改。因此，在从头开始编写严肃的光线追踪器时，优秀的软件工程至关重要。但是想象一下，你想写一个光线追踪器，你已经知道你会用它来光线追踪一个，永远的单张照片。那张照片是在方格地板上的一个反射球。在这种情况下，您只需以某种方式将其破解。生物信息学只是后一种情况。

您最终会得到具有不同格式的相同信息的整个目录树，直到您达到下一步所需的一种特定格式，以及十几个名称如“tmp_SNP_cancer_34521_unique_IDs_not_Chimp.csv”的文件，您对此一无所知一天后你为什么创建这个文件以及它到底是什么。

有一段时间，我使用MySQL有帮助，但现在生成新数据和更改格式的速度如此之快，以至于无法进行正确的数据库设计。

我知道有一份涉及这些问题的出版物（Noble，WS（2009 年，7 月）。组织计算生物学项目的快速指南。PLoS Comput Biol 5 (7)，e1000424+）。作者很好地总结了目标：

核心指导原则很简单：不熟悉您项目的人应该能够查看您的计算机文件并详细了解您做了什么以及为什么。

嗯，这也是我想要的！但是我已经跟那个作者一样的做法了，我觉得这绝对是不够的。

记录你在Bash中发出的每一个命令，评论你为什么这样做，等等，都是乏味且容易出错的。工作流程中的步骤太细了。即使你这样做了，要弄清楚每个文件的用途、特定工作流在什么时候被中断、出于什么原因以及你继续的位置，这仍然是一项极其繁琐的任务。

（我不是在 Taverna 的意义上使用“工作流程”这个词；我所说的工作流程只是指您为达到特定目标而选择执行的步骤、命令和程序）。

你如何组织你的生物信息学项目？

4

3 回答 3

12

我是一名嵌入研究科学家团队的软件专家，尽管在地球科学领域，而不是生命科学领域。你写的很多东西我都很熟悉。

要记住的一件事是，您在学习中学到的大部分内容都是关于工程软件以供继续使用。正如您所观察到的，科学家所做的很多研究都是一次性使用，而工程方法并不适合。如果你想实现优秀软件工程的某些方面，你将不得不仔细选择你的战斗。

在你开始战斗之前，你必须批判性地检查你自己的想法，以确保你在学校学到的关于通用软件工程的知识对你当前的情况有效。不要假设它是。

就我而言，我选择的第一场战斗是源代码控制的实施。当您没有适当的版本控制时，不难找到所有出错的示例：

  • 一些用户有几十个目录，每个目录都有不同版本的“相同”代码，只有最模糊的想法是他们中的大多数人做了什么，或者他们为什么在那里；
  • 一些用户通过覆盖它们而丢失了有用的修改并且无法记住他们做了什么；
  • 很容易发现人们正在研究应该是相同的程序，但实际上却在不同方向上不兼容地发展；
  • 等等等等

一旦我收集了这些信息——并确保你记好谁说了些什么，以及他们花了多少钱——就相对容易地用源代码控制来描绘一个更美好的世界。

接下来，好吧，接下来你必须选择自己的下一场战斗。但是，你必须在你的科学家同事心中播下怀疑的种子之一是“可重复性”。不可重复的科学实验是无效的；如果他们的实验涉及软件（而且他们总是这样做），那么仔细的软件工程对于可重复性至关重要。其中很多是关于数据来源的，但这是另一天的话题。

于 2010-09-21T12:15:59.357 回答
1

这里的部分问题是软件文档与发布文档之间的区别。

对于软件开发（和研究计划）设计，重要的文档是结构化的和有意的。因此，对数据进行建模、你做某事的原因等等。我强烈建议你使用你在 CS 中学到的技能来记录你的研究计划。为您想要做的事情制定计划可以让您在进行长时间分析时有很大的自由度来处理多任务。

另一方面，很多生物信息学工作是分析。在这里，您需要将文档视为实验室笔记本，而不一定是项目计划。你想记录你做了什么，也许是一个简短的评论为什么（例如当你对数据进行故障排除时），以及输出和结果是什么。我所做的相当简单。首先，我从一个目录开始并创建一个 git repo。然后，每当我更改某些文件时，我都会将其提交到 repo。我尽可能地尝试以一种我可以放入我的 git 忽略文件的方式命名数据输出。然后，尽可能地，我一次为一个项目处理一个终端会话，当我遇到一个暂停点时（比如当我有一组作业发送到网格时，我运行'history |剪切 -c 8-' 并将其粘贴到实验室笔记文件中。然后我编辑该文件以添加我所做的评论，请记住，将 git add/commit 行更改为 git checkout （我有一个基于提交消息执行此操作的脚本）。只要我在正确的目录中启动它，并且我的外部数据没有消失，这意味着我可以稍后重新创建整个过程。

对于任何稍微复杂的处理任务，我都会编写一个脚本来完成它，以便我的笔记本尽可能看起来干净。近似地，一个帮助脚本可以被视为一个更大项目中的一个子例程，并且应该在内部记录到至少那个级别。

于 2010-10-19T17:05:24.250 回答
0

你的问题是关于项目管理的。糟糕的项目管理并不是生物信息学独有的。我很难相信整个生物信息学行业都致力于糟糕的软件设计。

关于压力......这个世界上还有其他人的截止日期非常具有挑战性，他们仍在使用良好的软件设计。

在许多情况下，遵循良好的软件设计并不会拖累项目，甚至可以加快其设计和维护（至少从长远来看）。

现在问你真正的问题......你可以让你的经理重新设计对其余代码没有影响的小部分代码作为概念证明（POC），但是很难阻止卡车继续行驶搬家，所以如果他觉得“我们多年来一直这样工作——我们知道自己在做什么，我们不需要孩子教我们如何做我们的工作”，请不要生气。学会像其他人一样工作，当你获得他们的信任时，你可以偶尔做你的事情（我希望你有时间和奉献精神做正确的事）。

祝你好运。

于 2010-09-21T11:57:31.000 回答