梦断代码 读后感（III）远虑和近忧

原文地址:http://yishan.cc/blogs/xin/archive/2008/11/18/iii.aspx

[part 3]

几个星期前，我给《现代软件工程》课的每一个团队都发了一本 《Dreaming In Code》的中文版 《梦断代码》，要求写读后感。这本书讲了这样的故事：一群很有经验的代码牛人在先进软件开发模式的指导下，没有资金压力，在更多大牛的带领下，原计划用一到两年的时间开发出一个备受期待的个人信息管理软件(PIM)，后来花了七年时间才完成这一创举，但是已经无人喝彩。我是9月份读的英文版，后来又翻阅了中文版，也有一些感想如下。

Kapor 的团队看起来非常重视“远景”， 他们似乎没有近忧 - 这也许是致命的。

他们对于软件的基本架构/infrastructure 非常关心，例如对于存储系统，它们提出了下列需求：[p103]

1. it has to make life easy for the Python programmers
2. it has to operate efficiently over a network
3. it needs to be able to handle very large individual date items and very large numbers of items
4. it has to be reliable, using database "transactions."
5. it has to support searching and indexing
6. [0] User experience  //Kapor 后来加上去的，似乎不相干的一条远景。

后来对于Data Storage，又有如下构想：[p109]

1. Provide programmers with as revolutionary a data model as users
2. data can live anywhere.
3. Data is safe from corruption.
4. Data is quick to get.
5. Data can be large.

非常令人佩服的远虑。 如果一个项目能同时实现其中3个目标，就已经能实用并吸引客户，开始赚钱了。 但是Chandler 项目的同志们不满足于只实现两三个，他们要实现全部5个梦想。

一群牛人在 “没有近忧，只有远虑” 的条件下讨论问题，最后只能议而不决。 在一次次延续到深夜的讨论中，有人感慨 - "How is this night different from all other nights?" //[p110]

没有近忧，或者说不用为近忧而负责 - “我们这个月的目标没完成不要紧，但是我们的远景一定要讨论好”。 导致了项目不能收敛 - 一个项目的一个里程碑中，不确定的事情应该越来越少，bug 也越来越少，直到产品发布。

Making firm technical choices was hard in the absence of a settled design, and settling on a design was hard in the absence of a technical roadmap. [p150 - 151]

正因为大家没有近忧，所以大家可以继续等待，设计要等技术决定后才好做，而技术的选择要等设计决定后才好开始。就这样，大家折腾到2005年的时候，他们才从高瞻远睹的远虑的云端中下来，有了第一个脚踏实地的计划：

But for the first time, at least, they could see they had a plan grounded in reality, rooted in estimates that ... [p232]

Kapor 毕竟是聪明人，很多年以后，他说到了教训：

We've consistently overinvested in infrastructure and design... [p342]

收敛的另一个特点是 - 做过了的决定，就要执行，不要反复。事实上，Chandler 团队在很多决定上摇摆不定。 架构师Hertzfeld 度假回来，发现他带领其他同事奋战一个夏天得到的 Document Architecture 被扔到一边，原来 Kapor 决定 “We'll have to come back and realign things”  [p168]。 如果你是做义务劳动的 Hertzfeld，你还能做下去么？

回到 “远景”， 我相信几乎没有合适的解决方案能满足“远景” 中的所有要求，很难找到 “多快好省” 的解决方案（书中提到 fast|cheap|good 不能兼得，这也是MSF 中 time | resource | feature 三个元素的矛盾）。但是往往存在若干方案，从不同的角度逼近最优，但是有各自令人讨厌的缺点。我们能否有智慧来选择这样一个方案，把近忧，远虑都慢慢解决？

我自己在微软正在做一个创新项目，前几天一位加入这个项目不久的优秀的开发人员对我说，我们去年设计的数据库问题太多了，如果我们早就像我这样设计，估计会好很多。我不是数据库的专家，我只能对他说，如果我们当时坚持要做到今天这样才发布，这个项目也许就做不到今天了。

换句话说，正是因为早期那些不完美，但是及时的设计，让后来者有挑剔这些不完美的奢侈机会。

我们每个人在使用这些不完美的软件（Windows, Outlook, 甚至Linux）的时候，都应该感谢当初设计者做出了正确决定，而那些坚持完美设计远景的项目，它们都到哪去了？