pet*_*ust 26 project-management
当您或项目不清楚最终(如果有)产品将会是什么时,采用哪些有用的策略？
让我们将"研究"意味着探索一个领域,在这个领域中许多事情都是未知或未实现的,并且在项目开始时无法指定正式的可交付成果.这在STEM(科学(物理,化学,生物学,材料等),技术工程,医学)以及信息学和计算机科学的许多领域中很常见.软件既可以作为目的本身(例如新算法),也可以管理数据(通常是实验性的)和模拟(例如材料,反应等).它通常由小团体或个人创建(我省略了大型科学,如望远镜和强子对撞机,其中重点放在软件工程上.)
研究软件的特点是(至少):
项目可以是几天("看看这是一个值得去的方向")到几年("这是我的博士主题")或更长时间.通常,人们不会被雇用为软件人员,但他们发现他们需要编写代码来完成研究或通过编写软件来感染.良好的软件工程通常没有什么功劳 - "产品"是会议或期刊出版物.
然而,其中一些项目非常有价值 - 最明显的领域是基因组学,在早期科学家们表明,动态规划是帮助思考蛋白质和核酸结构的革命性工具 - 现在这是一个数十亿的行业(或者更多).量子力学代码预测物质的属性也是如此.
缺点是很多代码被抛弃,很难建立起来.为了克服这个问题,我们建立了一个库,这些库在集团和世界上作为开源共享(但这里再次给出的信用很少).许多研究人员重新发明轮子("低头"编程,不咨询同事和"英雄"编程,有人试图完成自己的全部工作).
在项目开始时太多的形式往往会让人失望,创新就会消失(没有人会花2个月写正式的规格和单元测试).制定和颁布了太少和坏习惯.编程课程有助于再次让人们很难做到这一点,尤其是当你依赖他们的善意时.指导是非常有价值的,但并不总是成功.
是否有在线资源可以帮助说服人们养成良好的软件习惯？
编辑:我很感谢dmckee(下面)指出类似的讨论.这一切都很好,我特别同意版本控制是我们可以为科学家们提供的最重要的事情之一(我们向同事们提供了这个并得到了非常好的评价).我也喜欢那里提到的软件木工课程的方法.
ire*_*ses 19
这非常困难.您和Stefano Borini描述的环境非常准确.我认为有三个关键因素可以传播这种情况.
短期思考.短期思维是常态的原因有几个,其中大多数已经由斯特凡诺很好地解释了.除了发布的可怕压力和对软件创建缺乏认可外,我还要强调短期合同的数量.由于合同期为2 - 3年,更多初级学者(博士生和博士后)花费任何时间来规划长期软件策略的优势很小.对于长期项目,例如基于常任员工模拟代码的项目,我已经看到了基本软件工程的一些应用,例如简单版本控制,标准测试用例等.但即使在这些情况下,项目管理非常原始.
缺乏正式的培训和经验.这是一个严重的障碍.在天文学和天体物理学中,编程是一个必不可少的工具,但是对开发成本的理解,特别是维护开销,是非常差的.因为科学家通常都是聪明人,所以有一种感觉,即软件工程实践并不真正适用于他们,并且他们可以"只是让它工作".凭借更多的经验,大多数程序员意识到编写主要工作的代码并不是困难的部分; 有效和安全地维护和扩展它.一些科学代码是一次性的,在这些情况下,快速和肮脏的方法是足够的.但很多时候,代码将在未来几年内被使用和重用,从而给所有参与其中的人带来悲痛.
毕业生/博士后不断进行新的发展.我认为这是允许软件学术方法继续生存的关键特性.如果代码是可怕的,需要花费数天才能理解和调试,谁支付这个价格？一般来说,它不是原作者(可能已经移动过).它也不是常任的工作人员,往往只是外围参与新的发展.通常是研究生正在实施新算法,产生新方法,试图以某种方式扩展代码.有时它会成为博士后,专门为现有代码添加某些功能而受雇,并且合同上有义务在这个区域工作一段时间.
这种模式非常低效.我认识一位天体物理学博士生,他花了一年多时间尝试在现有的n体代码中实现一个相对基本的数学,只有几百行代码.为什么需要这么长时间？因为她花了几周时间试图理解现有的,可怕的编写代码,以及如何将其计算添加到其中,并且由于单一的代码结构,再加上她自己缺乏经验,几个月无法有效地调试她的问题.请注意,这个过程几乎没有涉及科学 ; 只是浪费时间来处理代码.谁最终支付了这个价格？只有她.她是那个不得不花费更多时间来尝试获得足够成绩以获得博士学位的人.她的主管将在她离开后获得另一名研究生 - 所以这个循环仍在继续.
我要说的是,学术界的软件创建过程中的问题在系统本身内是流行的,是可用资源和奖励工作类型的函数.这种文化深深植根于学术界.我没有看到通过外部资源或培训改变这种文化的任何简单方法.这是系统本身需要改变,奖励人们编写实质性代码,对使用科学代码产生的结果的正确性进行更严格的审查,认识到培训和流程在代码中的重要性,并让监督者共同负责浪费他们研究小组成员的时间.
我会告诉你我的经历.
毫无疑问,许多软件在学术界被创造和浪费.事实上,很难将专门为特定研究目标创建的研究软件适应更广泛的环境.此外,学术界的产品是科学论文,而不是软件.学术界的软件价值为零.一旦您在其上写了一篇论文(这需要大量的编辑时间),您对使用该软件生成的数据进行评估.
然而,在大多数情况下,研究小组已经认识到频繁的模式,可以作为内部知识进行抛光,测试和存档.这就是我使用我的个人工具包.我根据我的研究需求增长它,只有那些"跨项目"的功能.开发个人工具包几乎是一项要求,因为您的科学需求很可能是某些经文的独特之处(否则您不会进行研究)并且您希望尽可能少地获得外部依赖(因为如果某些东西发展并破坏了您的东西,你没有时间来解决它).
然而,其他一切对于特定项目来说太具体了.因此,我倾向于不封装显然是一次性求解器的东西.但是,如果稍后其他项目需要相同的代码,我会回过头来改进它.
较短的项目范围和研究的热度(例如今天如此重要的出版或灭亡愿景)需要灵活,快速的语言,以及通常可以快速掌握的语言.基因组学和量子化学博士没有正式的编程背景.在某些情况下,他们甚至不喜欢它.因此,语言必须快速,简单,干净,灵活,以后易于理解.后一点是资本,因为没有时间来制作文件,并且保证在学术界,每个人迟早都会离开,你每三年左右就将团队经验烧成零.学术界是一个高风险的行业,定期解雇他们所有硬派的执行者,只保留一些管理人员.因此,拥有可维护且易于被其他人掌握的代码是资本.此外,永远不要低估谷歌搜索解决您的问题的力量.使用良好部署的语言,您更有可能找到问题的答案和您可能偶然发现的问题.
管理也是一个问题.瀑布没有讨论.没有时间进行文书工作编程(要求,规格,设计).螺旋非常好,但显然建议尽可能低的文书工作.事实是,任何不能在学术界给你一篇文章的东西都是浪费时间.如果你花一个月写规格,那就浪费了一个月,你的合同将在11个月内到期.此外,对于你的职业生涯来说,这个脂肪文件的数量为零或接近于零(许多其他事情:管理和教学是两个例子).当然,敏捷方法也没有讨论.大多数开发是由远远的团队完成的,并且通常还有许多其他事情要做.在文章之间的"业余时间",以及会议之前或之后,编码集中是短暂的爆发.集市是最有可能的,但集市也有很多问题.
因此,为了回答你的问题,最好的策略是已知良好软件的"缓慢积累",以快速灵活的方法和语言进行小爆发.在讲座期间需要教授良好的编码实践,因为在实践课程中教授良好的实验室实践(例如,从不将水加入硫酸中,总是相反)
最困难的部分是"这只是一篇论文"和"我们真的要用它"之间的过渡.
如果您知道代码只适用于纸张,那么可以使用快捷方式.硬编码你能做的一切.如果程序员是唯一一个将运行代码的人,请不要在广泛验证上浪费时间.等等.问题在于有人说"太棒了!现在让我们用它来实现"或"现在让我们使用它来完成与开发和测试的完全不同的场景."
一个相关的挑战是必须解释为什么软件没有准备好黄金时间,即使它显然有效,即它的原型质量而不是生产质量.你是什么意思需要重写它？