研究环境中的软件项目与开发

Question

当您或项目不清楚最终(如果有的话)产品将是什么时，采取什么有用的策略？

让我们把“研究”看作是对一个领域的探索，在这个领域中，许多事情都是不知道或没有实现的，并且在项目开始时无法指定一组正式的可交付成果。这在STEM (物理、化学、生物学、材料等)、技术工程、医学以及信息学和计算机科学的许多领域都很常见。软件的创建本身就是一种目的(例如一种新的算法)，是一种管理数据(通常是实验性的)和模拟(例如材料、反应等)的手段。它通常是由小团体或个人创建的(我忽略了大型科学，如望远镜和强子对撞机，其中非常强调软件工程)。

研究软件的特点是(至少)：

• 未知结果
• 未知时间刻度
• 很少正式的项目管理
• 有限的预算(至少在学术界)
• 第三方工具和库的不可预测性
• 项目期间外部世界的变化(例如，新的发现可以是积极的、节省精力的，也可以是负面的)。

项目可以是任何东西，从天(“看看这是否值得去做”)到几年(“这是我的PhD主题”)或更长。通常情况下，这些人并不是被雇佣为软件人员，而是发现他们需要编写代码来完成研究，或者被软件的编写所感染。好的软件工程通常没有什么信誉--“产品”是一种会议或期刊出版物。

然而，这些项目中有一些是非常有价值的--最明显的领域是基因组学，在早期，科学家们证明动态规划是帮助思考蛋白质和核结构的革命性工具--现在，这是一个数十亿(或更多)的产业。用于预测物质性质的量子力学代码也是如此。

缺点是大量代码被丢弃，很难在此基础上进行构建。为了克服这一问题，我们建立了一些库，这些库在组中共享，并以开放源码的形式在整个世界中共享(但这里也没有什么值得称赞的地方)。许多研究人员重新发明了轮子(不征求同事意见的“向下”编程，以及“英雄”编程，即有人试图自己做很多事情)。

项目开始时过于拘泥于程序，往往会让人们失去创新(没有人会花2个月的时间来编写正式的规范和单元测试)。养成和传播的不良习惯太少。编程课程很有帮助，但也很难让人们这么做，尤其是当你依赖他们的善意时。指导是非常宝贵的，但并不总是成功的。

是否有在线资源可以帮助人们养成良好的软件习惯？

编辑:我很感谢dmckee (下面)指出了类似的讨论。这都是好东西，我特别同意版本控制是我们可以提供给科学家的最重要的事情之一(我们提供给我们的同事，并得到了非常好的接受)。我也喜欢上面提到的软件木工课程的方法。

Answer 1

这太难了。您和斯特凡诺·博里尼描述的环境都非常准确。我认为有三个关键因素是造成这种情况的原因。

1. 短期思维
2. 缺乏正规培训和经验
3. 研究生/博士后的持续更替--首当其冲的新发展

短期思维()短期思维是常态的原因有几个，斯特凡诺已经很好地解释了这些原因。除了出版的巨大压力和缺乏对软件开发的认可，我要强调的是短期合同的数量。对于更多的初级学者(PhD学生和博士后)来说，花费任何时间规划长期软件策略几乎没有什么好处，因为合同的期限是2-3年。在较长期的项目中，例如基于长期工作人员模拟代码的项目，我已经看到了一些基本软件工程的应用，比如简单版本控制、标准测试用例等，但是即使在这些情况下，项目管理也是极其原始的。

缺乏正规的培训和经验，这是一个严重的障碍。在天文学和天体物理学中，编程是一种必不可少的工具，但对开发成本，特别是维护费用的理解非常差。因为科学家通常都是聪明人，所以有一种感觉是，软件工程实践并不真正适用于他们，他们可以“让它发挥作用”。有了更多的经验，大多数程序员意识到编写主要工作的代码并不难；高效和安全地维护和扩展代码。一些科学的代码被丢弃，在这些情况下，快速和肮脏的方法是足够的。但是，在未来的几年里，代码常常会被使用和重复使用，从而给所有参与其中的人带来悲伤。

研究生/博士后的不断更替，以求新的发展。，我认为这是让软件的学术方法得以继续生存的关键。如果代码是可怕的，需要数天的时间才能理解和调试，那么谁会为此付出代价呢？一般来说，这不是原来的作者(可能已经向前看了)。它也不是工作人员的常任成员，他们往往只是在外围参与新的发展。通常是研究生在实现新的算法，产生新的方法，试图以某种方式扩展代码。有时，它将是一个博士后，专门用来在现有代码中添加一些特性，并且在合同上有义务在这方面工作一小部分时间。

这种模式效率极低。我认识一位天体物理学的PhD学生，他花了一年多的时间，试图在现有的n体代码中实现一个相对基本的数学部分，只有几百行代码。为什么花了这么久？因为她花了几个星期的时间来理解现有的、写得很糟糕的代码，以及如何将她的计算添加到其中，还有几个月来，由于单一的代码结构，再加上她自己缺乏经验，更多的是无法有效地调试她的问题。请注意，在这个过程中几乎没有涉及到任何科学；只是浪费时间处理代码。谁最终付出了这个代价？只有她。她必须投入更多的时间来尝试获得足够的结果来获得PhD。她的导师会在她离开后再找一个研究生--所以这个循环还在继续。

我想指出的是，在学术界，软件创建过程中的问题是系统本身特有的，这是可用资源和获得奖励的工作类型的函数。这种文化深深植根于学术界。我看不出通过外部资源或培训来改变这种文化的任何简单方法。系统本身需要改变，奖励编写大量代码的人，对使用科学代码产生的结果的正确性进行更严格的审查，认识到在代码中进行培训和处理的重要性，并要求管理者共同负责浪费研究小组成员的时间。

Answer 2

我来告诉你我的经历。

毫无疑问，许多软件在学术界被创造和浪费。事实上，为了特定的研究目标而设计的研究软件很难适应更普遍的环境。此外，学术界的产品是科学论文，而不是软件。软件在学术界的价值是零的。一旦你在软件上写了一篇论文(这需要很长的编辑时间)，你用这个软件生成的数据就会被评估。

然而，在大多数情况下，研究小组已经认识到频繁的模式，这些模式可以被抛光、测试和存档为内部知识。这就是我用我的个人工具箱做的。我根据我的研究需要来种植它，只有那些“交叉项目”的特性。开发一个个人工具包几乎是一项要求，因为您的科学需求很可能是某些诗句所特有的(否则您将不进行研究)，并且您希望尽可能少的外部依赖(因为如果某些东西演变并破坏了您的东西，您将没有时间修复它)。

然而，其他的一切都过于具体，以致于一个特定的项目无法结晶。因此，我倾向于不封装一些显然是一次求解的东西。但是，如果以后其他项目需要相同的代码，我会回去改进它。

短的项目跨度，以及研究的热度(例如，今天的出版或毁灭的视野)，都需要敏捷、快速的语言，以及通常能够快速掌握的语言。基因组学和量子化学领域的Ph.Ds没有正规的编程背景。在某些情况下，他们甚至不喜欢它。因此，语言必须是快速的，容易的，干净的，灵活的，容易理解的。后一点是资本，因为没有时间编写文档，而且保证在学术界，每个人迟早都会离开，你每隔三年左右就会把团队经验烧成零。学术界是一个高风险行业，它定期解雇所有顽固的执行者，只保留一些管理人员。因此，拥有一个可维护且易于被其他人掌握的代码是资本。此外，千万不要低估谷歌搜索解决问题的能力。使用一种部署良好的语言，您更有可能找到您可能遇到的难题和问题的答案。

管理也是一个问题。瀑布已经不再讨论了。没有时间进行书面程序设计(要求、规格、设计)。螺旋是相当好的，但尽可能低的文书工作显然是建议的。事实上，任何在学术界没有给你文章的东西都是浪费时间的。如果你花一个月的时间写说明书，那就浪费了一个月，你的合同在11个月内到期。此外，这份高质量的文件对你的职业生涯意味着零或接近零(就像其他许多事情一样:管理和教学就是两个例子)。当然，敏捷方法也没有讨论。大多数开发都是由那些很远的群体完成的，而且通常还有很多其他的事情要做。编码集中发生在文章之间的“业余时间”以及会议之前或之后。集市是最有可能的，但集市也有很多问题。

因此，要回答您的问题，最好的策略是“缓慢积累”已知的好软件，用快速而灵活的方法和语言进行小范围的开发。良好的编码实践需要在讲课期间教授，就像在实践课程中教授良好的实验室实践一样(例如。永远不要把水放进硫酸里，总是相反)

Answer 3

最困难的部分是“这只是为了一篇论文”和“我们真的要用它”之间的过渡。

如果你知道代码将只为一张纸，好的，走捷径。硬编码你能做的一切。如果程序员是唯一将运行代码的人，不要浪费时间在广泛的验证上。等。问题是当有人说“好极了！现在让我们真正使用它”或者“现在让我们用它来处理与开发和测试完全不同的场景”。

一个相关的挑战是必须解释为什么软件没有为黄金时段做好准备，尽管它显然是有效的，即它是原型质量而不是产品质量。你要重写它是什么意思？