project-management - 研究环境中的软件项目和开发

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

2年前关闭。




Improve this question




当您或项目对最终(如果有)产品将是什么没有清晰的想法时，可以采用哪些有用的策略？

让我们将“研究”理解为对许多事情未知或未实现并且在项目开始时无法指定正式的可交付成果的领域的探索。这在 STEM(科学(物理学、化学、生物学、 Material 等)、技术工程、医学)以及信息学和计算机科学的许多领域中很常见。软件既可以作为目的(例如新算法)、管理数据(通常是实验性的)和模拟(例如 Material 、 react 等)的手段而创建。它通常是由小团体或个人创建的(我省略了诸如望远镜和强子对撞机之类的大型科学，它们非常重视软件工程。)

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

未知结果

未知时间尺度

小正规项目管理

有限的预算(至少在学术界)

第三方工具和库的不可预测性

项目期间外部世界的变化(例如，新发现可能是积极的 - 节省精力 - 或消极 - 被抢走

项目可以是几天(“看看这是一个值得去的方向”)到几年(“这是我的博士课题”)或更长时间。通常，这些人不是被聘为软件人员，而是发现他们需要编写代码来完成研究，否则会因编写软件而受到感染。优秀的软件工程通常没有什么信誉——“产品”是 session 或期刊出版物。

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

缺点是很多代码被丢弃并且难以构建。为了克服这个问题，我们建立了在小组中共享的库，并作为开放源在世界范围内共享(但这里再次给出的信用很少)。许多研究人员重新发明了轮子(不咨询同事的“低头”编程和有人试图自己完成所有工作的“英雄”编程)。

项目开始时过于拘泥于形式往往会让人们望而却步，并失去创新(没有人会花 2 个月时间编写正式的规范和单元测试)。太少和坏习惯被养成和传播。编程类(class)有帮助，但同样很难让人们去做它们，尤其是当你依赖他们的善意时。指导非常有值(value)，但并不总是成功。

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

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

Answer 1

这是非常困难的。你和我的环境Stefano Borini描述非常准确。我认为有三个关键因素会传播这种情况。

短线思维

缺乏正规培训和经验

研究生/博士后持续更替首当其冲

短期思维。 短期思考是常态有几个原因，其中大多数已经被 Stefano 很好地解释过。除了发布的巨大压力和对软件创作缺乏认可之外，我还要强调短期契约(Contract)的数量。对于更多的初级学者(博士生和博士后)来说，花费任何时间来规划长期软件战略几乎没有什么优势，因为契约(Contract)是 2-3 年。在长期项目的情况下，例如那些基于常驻人员的模拟代码，我看到了一些基础软件工程的应用，比如简单的版本控制、标准测试用例等。但即使在这些情况下，项目管理也是非常原始的。

缺乏正规培训和经验。 这是一个严重的障碍。在天文学和天体物理学中，编程是必不可少的工具，但对开发成本(尤其是维护费用)的理解极其贫乏。因为科学家通常都是聪明人，所以有一种感觉，软件工程实践并不真正适用于他们，他们可以“让它发挥作用”。随着经验的增加，大多数程序员意识到编写最有效的代码并不是最难的部分；有效和安全地维护和扩展它是。一些科学代码是一次性的，在这些情况下，快速而肮脏的方法就足够了。但很多时候，这些代码将在 future 几年内被使用和重用，给所有相关人员带来随之而来的悲痛。

研究生/博士后的持续更替以进行新的发展。 我认为这是让软件的学术方法继续生存的关键特征。如果代码很糟糕并且需要数天时间来理解和调试，那么谁会为此付出代价？一般来说，它不是原作者(他可能已经离开了)。也不是常任工作人员，他们通常只在外围参与新的开发。通常是研究生在实现新算法，产生新方法，试图以某种方式扩展代码。有时它会是一名博士后，专门聘请来为现有代码添加一些功能，并根据契约(Contract)有义务在他们的一小部分时间里在这个领域工作。

这种模式非常低效。我认识一位天体物理学博士生，他花了一年多的时间试图在现有的 n 体代码中实现一个相对基本的数学部分，只有几百行代码。为什么花了这么长时间？因为她真的花了数周时间试图理解现有的、编写得非常糟糕的代码，以及如何将她的计算添加到其中，并且由于单一的代码结构以及她自己缺乏经验，她的问题调试效率低下数月。请注意，这个过程几乎没有涉及任何科学；只是浪费时间处理代码。谁最终付出了这个代价？只有她。她是那个不得不花更多时间尝试获得足够的结果来攻读博士学位的人。她走后，她的主管会再招一名研究生——这样循环下去。

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