转载

To the Moon:太空任务与开发软件的相似之处

Russ Olsen在 GOTO Berlin 2015 会议上发表了题为“To the Moon”的开幕式演讲，在演讲中他介绍了太空任务与开发软件的相似之处。

InfoQ对 Russ Olsen进行了采访，主要关于为了满足期限在同一时间进行所有事情的弊端、从错误的和正确的事情中吸取经验教训、在软件开发中再渺小的事情也能扼杀你和当实施复杂工作时如何专注和处理细节。

InfoQ：您演讲的大部分形式都是第一次登月故事。您为什么选择用这种形式组织您的演讲？

Olsen ：你知道的，人们习惯使用短语“改变一切”。但是他们谈论的很难改变什么，更何况改变一切。那个周日的下午，当我们登上月球后它真的改变了一切，至少对我而言是这样的。突然我有了人生的方向，我知道我长大后希望成为什么。并且我不是孤军奋战：我见到了很多从那天开始发生转变的人。我尝试了很久，希望帮助那些不够幸运没有经历登月事件的人们感受那种体验，但是唯一起作用的是让他们与我一起重温那一时刻，惊心动魄的时刻。因此，才有了这次演讲。

重要通知：接下来InfoQ将会选择性地将部分优秀内容首发在微信公众号中，欢迎关注InfoQ微信公众号第一时间阅读精品内容。

To the Moon:太空任务与开发软件的相似之处

InfoQ：在太空任务中，为了满足最后期限人们在同一时间进行所有的事情。这种情况在软件开发中存在吗？您认为这是否有效？

Olsen ：NASA在阿波罗计划中面临的情况是他们需要在一个疯狂的截止日期前完成一个几乎不可能的项目。因为时间线不允许他们“在第一步的基础上建立第二步”，最终他们简单地列出了所有需要发生的事情，一次进行所有的事情，最终整合它们。这种做事的效率及其的低下：你不可避免地会遇到人们构建的组件不能很好地一起工作。你让人们不断地解决同样的问题，因为他们没有意识到其他人也在解决这个问题。并且当整体设计发生变化的时候，你会有大量的返工。

阿波罗疯狂方式最明显的标志是阿波罗母舰后面巨大的火箭引擎。火箭引擎最初是设计用来推动母舰离开月球表面。但是随着项目整体设计落实后，他们有了一个独立的、专门的登陆飞船。所以母舰不需要着落——或者升空离开——月球。这意味着母舰不需要一个巨大的火箭引擎。但是设计的时候他们已经考虑了这个引擎，并且很容易做到扔掉它。

可悲的是，人们在软件开发中过度使用“先构建后集成”技术。显然我不是唯一一个：在演讲中我开玩笑说这种着手构建系统的方式“永远是一个好主意”。人们——尤其是开发者——总是哈哈大笑。那为什么开发者有时还是采用这种方法呢？原因跟 NASA那帮人是一样的——不可能完成的目标和疯狂的截止日期。这么说吧：如果你正在管理一个软件项目，你设置了不可能完成的目标和疯狂的截止日期，取决于你的团队他们可能会圆满完成。或许不会，但是可能。但是无论成功还是失败，不可能的目标和疯狂的截止日期将会浪费你的精力、使团队疲倦、导致蹩脚的设计，和一百种不同的方式。

InfoQ：您能举例说明在太空任务中，人们如何从错误的事情中吸取经验教训？在软件开发中您有看到类似的学习模式吗？

Olsen ：通常你能在航空航天中看到不间断的、系统的失败研究，不仅是实际的，还包括潜在的。如果飞机或者宇宙飞船中的某个零件发生故障，通常会有一系列系统的提问。不仅仅是“这个零件为什么会发生故障？”还包括“为什么早期我们没有发现这个故障？”和“其它交通工具中这个故障发生的比例是多高？”更不用说“这个故障是更一般故障的案例吗？”同时不仅仅是彻底的故障：航空航天工程师们一直在寻找异常现象，比如即使是发生直接损伤也不应该发生的故障。重要的是，航空航天工程师们面对故障时倾向于数据驱动和统计方法。

如今情况得到了好转，但是传统的开发人员仍然将失败看成是随机的从天而降的闪电：也许日志服务发生了故障，所以我们修复了问题，并忘了这件事。或者更糟糕的是，我们将软件缺陷看成是相关开发人员道德缺陷的证据：“你怎么可以让这种事情发生！！”是一种对软件故障可以理解的反应，但不是一个有用的反应。同样我们往往也会忽略异常行为：如果它不发生故障，就不进行修复。除非虽然你的系统没有发生故障，但是它引起了你的注意，试图告诉你它即将发生故障。

你可以将软件系统看成是由许多零件组成的复杂机器。事实证明收集系统的实际数据——包括故障和“有趣”的事件——基于收集的数据建立对系统的理解是我们应该一直考虑的事情。

InfoQ：您认为从成功和运转良好的事情中吸取经验教训如何？您对此看法是什么，它是否已经在软件行业中得到了充分的体现？

Olsen ：我在软件行业中看到的一次又一次的主旋律是，我们过分推广我们在成功项目中学到的经验教训。在进行项目前，我们有着明确很好理解的目标、积极合作的客户、扎实的技术、灵活的思维和良好的设计文档，因此我们认为，“嘿，这个项目成功是因为我们有着良好的设计文档！”或者，“我们每天与客户交流一个小时，这是成功的原因。”或者，“我们充分理解需求，”这是灵丹妙药！问题是，为了构建复杂系统需要正确完成上百万的事情。如果你成功了，那么很好，尝试找出成功的根本原因。但是请注意，原因肯定不止一个。

InfoQ：您提到在太空中，再小的事情也可能会杀死你。这在软件开发中也是如此吗？

Olsen ：软件开发是在所有尺度上把事情做对。清楚地获得正确的软件系统的整体设计是至关重要的。但是缺乏有效的执行力，好的设计也不会给你带来好的结果。同样好的执行力但是充满了bug同样也不会让任何一个人感到快乐。任何软件系统都会被许多“次要”的bug破坏。

InfoQ：对于进行复杂工作时如何使自己专注您有没有什么建议？您是如何处理这种细节的？

Olsen ：在演讲中我试图表达的观点是当你构建某种复杂度类似登月火箭或者一个中度大小的企业信息系统时，肯定会有失败。我再说一遍：肯定会有失败。软件开发者终日试图得到正确的细节，花费整晚和周末寻求新方法以确保细节实际上是正确的。但如果我们在过去半个世纪的编程中学到了什么，那就是你可以降低缺陷率，但是你不能将其降低为零。因此我们需要让我们系统、组织和自己做好准备接受即将发生的失败，并准备好解决失败。正确的态度是尽你所能，确保功能、服务和系统是可靠的。然后当它失败时继续你的工作。US太空计划的名言“失败不是一种选择”，其实，名言完全错误。当涉及到大型软件系统时，必然会发生失败。唯一的问题是，当失败时你和你的系统是否做好了准备。

InfoQ将会报道12月3日和4日举行的 GOTO Berlin会议。

查看英文原文： To the Moon:Parallels Between Space Missions and Developing Software

正文到此结束