1.1 作者用商用民航发动机来对比普通的商用软件，是否合适？

[GreyZeng]

软件工程概论一节中：

在成熟的航空工业中，一个飞机发动机从构思到最后运行，不知道要经历过多少人, 多少工序，多少流程，多少相关知识的验证。我们无法想象，如果最后某个商用型号的发动机在飞行时发现问题，最初的设计师会自己爬到引擎中敲敲打打，然后钻出来说，“继续飞吧，我搞定了”。然而, 在软件行业中, 很多软件工程师往往以做这样的事而自豪。

这一段中，作者将航空工业与软件工程进行了类比，并指出两者之间在维护层次上的差异性。据我理解，作者的意图是指出维护软件对软件工程师来说是一件值得自豪的事情，因为这意味着软件可以不断迭代完善。但是显然，商用民航发动机应当对标的性命攸关的软件，而不是普通的商用软件。

《Code Complete》一书中曾提到商用系统是高度迭代的，这意味着允许错误是必要的。然而性命攸关系统，比如医疗系统和航天系统，是需要进行序列式开发的（正如航空发动机一样）。我很难不去怀疑，1996年Ariane 5火箭系统的最初设计者，在火箭爆炸后修复软件BUG时，会感到的是自豪还是自责。

 

原文地址

[GreyZeng]

在我自己实际参与的软件开发过程中，团队经常要发现并修复BUG，这是不可避免的。但是，请注意非常重要的一点，测试阶段与发布阶段是截然不同的。我们所说的“发现BUG并修复”如果发生在测试期间，那么这属于一个软件工程师的正常期望范围，“我们期待着BUG的发生并修复它”，因此软件工程师确实会因此而自豪，因为ta能够真正地发现BUG并在交付前修复它。但是，如果BUG发生在生产期间，当软件真正地交付给了用户之后，任何一个软件工程师都不会期望用户拿着人员财产损失报告来找自己算账。

原文地址

[SoftwareTeacher]

商用民航发动机应当对标的性命攸关的软件，而不是普通的商用软件。

---

我们的很多软件，也是非常关键的，例如我们现在正常活动都需要的 “绿码” 的小程序 app，如果这个小程序有崩溃，那么一个城市的几十万人的正常生活都受到极大影响。