《梦断代码》读后感 by 付浩

梦断代码这本书通过作者自身的经历，向我们展示了Chandler漫长而痛苦的开发过程。

最初，Chandler被设想为包含邮件、约会、地址簿、任务和备注的个人信息管理器，它能支持多种操作系统。

Chandler无意挑战微软的Outlook等软件，但它应当做得一样好。这个想法本身就已经很有挑战性了，但是真正的麻烦才刚刚开始。

Chandler是一个开源项目，由OSAF开发。与其他商业软件不同，Chandler的开发过程缺少那种“强有力”的管理和约束，几乎没有人为整个项目负责，直到项目开始后一年多，才有了软件开发经理。

项目所有的成员都应该尽可能地发挥自己的创造性，但是不加节制的创造只会带来不切实际的项目需求和无法实现的功能。应当有人手握大权，及时砍掉一些可能会把项目引入歧途的想法。Chandler项目就是缺少这种对创造性的“约束”，这是所有问题的根源。

Chandler的无约束表现在很多方面：

漫无边际的需求

　　　起初，Chandler只是一个个人信息管理器，它集成了邮件、约会、地址簿、任务和备注等功能。这样的需求虽然有些挑战，但是已经有人做到了，比如微软的Outlook，所以还是靠谱的。

　　　不过后来不断引入的需求就有点乱搞了。

　　　首先，Chandler本来是面向个人和小企业用户的，后来又需要考虑学校等大型机构。

　　　Chandler还被要求使用P2P方式，不依赖服务器就能同步不同地点间的数据，但同时还要保证用户数据的安全。

　　　Chandler应当是一个个人信息管理，但也应该是个像乐高积木一样的可扩展开发者平台。

　　　Chandler是个开源项目，要迭代地构建，但是软件的界面和效率也要非常好。

　　　所有这些需求看上去都很好，但是自相矛盾，而且存在很多技术难点。

使用不成熟的技术

例如，Chandler放弃使用成熟的关系型数据库，而去使用对象数据库。然而一直没有找到一个成熟可以信赖的对象数据库系统。

又如，Chandler希望能够用乐高积木的方式构建起来，即制作很多标准件，然后简单地组装起来。事实上这几乎不可能。

　　　Chandler还放弃了使用Mozilla工具构建界面，而去使用wxWidgets。问题是，那时的wxWidgets还有很多缺陷……

项目成员想法过分地“百花齐放”

起先大家为使用怎样的数据库，制作怎样的后端而争论不休，然后是界面，等等……

总的来说Chandler项目的诸多需求自相矛盾，而且使用的技术也有些超前，最重要的是，缺乏一个强有力的管理核心来对项目的诸多事宜做裁决。

我们总是希望自己的项目能做到最好，但实际上，只要各个部分比较好就足以让整个项目最好了。要让局部也最优的话，项目不可能完成。

很多时候，一些看上去比较保守的做法恰恰是最好的。例如，Linux内核是基于传统的单内核架构，虽然有些庞杂，but it works；而FSF优先资助的Hurd基于微内核架构，理论上应该比Linux更加先进，但其调试开发异常困难。这是Linux比Hurd更为流行的一个主要原因。

理论最好的实际中不一定最好，软件的开发过程其实就是个折中的过程。