读《梦断代码》的感想

《梦断代码》详细叙述了OSAF的Chandler项目从2001年开创以来直至2005年间的进展状况，真实展示了Chandler项目的艰难的开发过程，通过Chandler项目中遇到的各种问题展现了现代软件开发中的种种困难，最终归结到一句话就是“软件难做”。

在软件项目开发的历史上，失败的例子比比皆是。作者Scott Rosenberg作为媒体工作者，见证了软件世界中无数个悲惨的故事——“无论是跨国公司、政府机构，还是军工大鳄，都曾一头撞上过代码的冰山。”其中比如FBI投资4亿美元，花费10年时间，开展的名为Trilogy的计算机现代化项目，当进行到耗资1亿7千万美元的第三个模块时，撞上了冰山，1亿7千万美元也就此打了水漂。美国国内税务局（IRS）是另一个活生生的例子。IRS在过去40年里，曾3次尝试改造计算机系统，但至今仍一事无成。再如联邦航空管理局（FAA）的先进自动系统（AAS）项目，从1981年启动到1994年宣告终止，花费了几十亿美元，结果颗粒无收。麦当劳的"Innocvate"项目耗资1亿7千万美金，也以失败告终。福特公司耗资数亿美金的"Everest"采购系统，也成了一个历时5年的黑洞。1995年一家名为斯坦迪矢的咨询公司做过一个关于软件项目失败的研究报告，发现只有16%的项目获得成功，其余的项目中，31%被削减或被完全取消，剩下的53%预算超支、延误或者不能交付计划中的全部功能特性。

软件为什么如此难做？如果没有亲身经历过真正的软件项目开发，也许很难回答这个问题。作为Chandler项目的记者，Scott Rosenberg亲历了该项目开发过程中的各个环节，真切地感受到了软件开发的种种困难。

如果以软件开发的流程为线索，第一个要解决的问题是“要做什么”的问题，也就是项目的目标。项目的目标要明确，并且可能实现。如果项目的目标过高，也许根本不可能实现。Mitch Kapor很清楚自己想要的软件是什么样的，他对Chandler项目也有着很高的目标——管理各种个人信息，灵活的输入方式，动态的数据组织方式，P2P网上共享数据模式等等。

在确定了这样一些目标之后，项目的总设计者就需要定下一些基础框架性的实施方案，比如实现的语言，构造GUI的工具集，存储各种数据的数据库等等。对于一个大项目，做出这样一些决定往往是很难的。因为一些决定一旦做出，其影响就会作用到工程的整个开发过程中。比如确定用何种语言来实现，各种语言都有自己不同的优点和局限，如果定下一种语言，其局限性就将作用于整个工程。因此，项目的架构师需要对整个项目有一个全局的把握，并且熟悉已有的各种语言和技术的功能特点，这样才能合理地根据项目的目标做出正确的决定。

Chandler项目的设计者们就面临这样的一些重大的抉择。他们最终确定用Python作为项目的编程语言，因为虽然Python是一种解释执行的语言，但它能极大地节省程序员的编程时间，并且它在跨平台方面具有天生的优越性，还有其他各种优点：比如开源、有大量的工具可以使用等等。另一个重要问题是用何种GUI构造工具集。OSAF的设计者们考虑了各种可能的选择，最后一个叫做wxWidgets的构造器脱颖而出。然而，在确定存储各种数据的数据库的原型时，Chandler项目的设计者们遇到了麻烦。为此，他们开了无数的会议，提出了无数种数据库的实现方案，但总是不能满足所有的需求。Chandler项目就在这个十字路口上徘徊不前，举步维艰。最后，为了能按时发布一个可用的版本，程序员们临时确定了一个数据库的方案，并在此不稳定的基础上开始编程，并发布了Chandler0.1版。直到一个叫做Andi Vajda的“牛仔程序员”加入这个项目后，正式的数据库原型才逐渐确定下来，整个项目的基础才得以夯实。可见，在一个大项目中做出这样一些基础性的重大的决定有多困难。

软件开发中最重要的一个方面是组织和管理。如何让程序员们高效地协作，为最后的项目目标共同努力，是一个值得研究的问题。当以合理的方式组织时，一个团队可能发挥最高的效能，达到的效果是1加1大于等于2。然在相反的情况下，一个团队发挥的效能很低，这时1加1小于2。在极限情况下，整个项目只有一个程序员，该程序员掌握整个工程的所有信息和知识，虽然该程序员免去了与他人交流协调的额外时间，但由于只有一个人，开发时间将会相当长。如果有多个程序员，看似可以并行地开发，但实际上在软件项目中，很多工作并不是可以充分并行化的，这使得一个人的工作必须以另外若干个人的工作为基础，并且由于单个人对整个工程可能不具有完整的信息，工程进行时各个人间还要不断地协调。合理地划分并分配任务，并使每个程序员间可以高效地共享项目信息，是提高团队运行效率的重要途径。

Chandler项目有着比较明确的分工，比如约翰·安德森是架构师，麦卡斯科等人负责数据库等。在共享信息和记录项目的状态方面，他们最初采用了邮件列表、blog，和wiki等多种方式。wiki在格式上的随意性给信息的查找带来了相当大的不便。另一方面，由于有些开发者在wiki页上贴便签，有些向邮件列表发信息，另一些在blog上贴进度。不同的信息共享方式导致整个项目的状态无处可寻。后来，他们又用Bugzilla来统一管理工作，但支持者很少。最后，摩根·萨奇为团队开发了一套状态管理器，才使得项目可以统一正式地管理。

Chandler项目聚集了顶尖的程序员，但耗时多年，最后不了了之，Kapor也在他的blog上承认了失败。原因是多方面的。我想第一个原因可能是Chandler的目标太高了。他们想做一个几乎是万能的信息管理器，前无古人后无来者，这个目标实在太难达到了。另外一方面，在某些基础性的重大决策方面，他们也许做出了错误的决定。比如用wxWidget作为构造GUI的工具集，这导致了他们在GUI上很多bug，比如窗体闪烁问题。在组织和管理方式方面，他们采用的方式是大教堂模式与集市模式的混合模式，一方面想利用开源软件开发中的依靠程序员的热情进行自发的开发，另一方面又制定了详细的工作进度，并有明确的分工，但也许这并没有真正集成两者的优点，并没有真正地提高效率。

总之，我们可以从Chandler项目学习到诸多经验，总结许多教训。虽然“软件难做”，但通过科学的开发方法，应该可以有效地降低软件开发的复杂度。