顶级程序员的心得 Coders at Work (II)

移山之道 作者

像 Tony Hoare 说的那样 – 它们明显没有 bug; 而不是没有明显的 bug.

 

 

 

但是“漂亮”并不意味着看着源代码就能马上读懂。 例如 AVL 树, 光看代码你不懂为什么这些子树要转来转去。但是如果你理解了它的核心思想，看到它维护了这个不变量 (invariant) 从而保证 log 级的访问速度，你就会说，”啊，明显理当如此。”

学校教育:

 

 

应该教更多的团队合作，“我上学的时候，团队合作被认为是作弊” (现在有些学校还是这样)。

 

 

 

 

 

 

 

成功的程序员:

 

 

他们更多的是“我只要懂得我需要的，就可以开始干活了”， 而不是“我得完全理解某个领域，才能开始”。

 

 

 

Peter Norvig 同学在NASA 工作的时候，参与了NASA 的一个著名事故的调查 ( 1999 年“火星气候卫星” 因导航出现重大错误而坠入火星大气层)。  从他在这本书的问答中，我们可以看到一个大略的错误发生过程: 

 

 

(1)      软件外包公司对于 mission-critical 的软件模块有很完备的检查和测试，但是对于其他模块则没有完备的管理。

 

 

 

(2)      程序员写了一个不重要的log 功能，其中用英制 (磅* 英尺) 表示力,  但是 NASA 用“牛顿”=  千克*米/(秒*秒)

 

 

 

(3)      外包公司接到一个新的工程，他们进行了软件重用，log 功能中记录的力被重用为导航功能的输入参数，成为 mission-critical 的模块。 //错误: 一个模块从 non-mission-critical 变成 mission-critical 没有经历必要的复审和测试。

 

 

 

(4)      这个新的工程由发包公司 Lockheed (洛克希德公司) 交给了客户 JPL (喷气推进实验室)

 

 

 

(5)      火箭带着卫星发射了，在10个月的飞行中，JPL  可以每天两次启动小推进器，来调整太空船的航向，在这一过程中，有人发现了导航功能的一些不正常现象, 于是 -

 

 

 

a.       JPL 发邮件给 Lockheed, 说 – 这个模块有些参数看起来好像不正常…

 

 

 

b.      Lockheed 回邮件...

 

 

 

c.       JPL 再发邮件…

 

 

 

d.      最后没有人再发邮件了

 

 

 

e.      JPL的同志认为， Lockheed 的同志们估计已经搞定了。

 

 

 

f.        Lockheed 的同志认为， JPL 的同志们没再追问这个问题，可能已经不是问题了。

 

 

 

错误: 这个问题从来没有收录到NASA 的错误跟踪系统 (Bug tracking system)，只是在email 中交流，导致最后没有人对这个问题负责。在错误跟踪系统中，总得有一个人“拥有”这一个bug，这样可以避免推诿责任。 (MSF 也很重视这一点)

 

 

 

十个月之后， 1999年9月23 日，卫星抵达火星大气层，错误的导航参数造成卫星坠入大气层烧毁。 单单卫星的造价就高达一亿两千五百万美元。