十年，我依然Dreaming in Code

 

读书 《Dreaming in Code》

十年，我依然Dreaming in Code。上一次读这本书是在十年前此书中文版刚刚出版之时。十年后，自己经历了互联网行业的风风雨雨后，再重读此书，里面描述的那些混乱场景，就如同自己亲历一般。恰好书中提到的技术都是自己曾经实际折腾过的，感触尤其的深刻。

本书作者功力深厚，对技术的来龙去脉，各种复杂的历史掌故都能恰到好处的穿插进文中。一本好书，不单是讲一个商业大败局的八卦故事，而要更像是一个寻宝图，通过一个故事，把前尘往事、千头万绪串接起来，让那些湮没在历史尘埃中的思想有迹可循。我沿着这份藏宝图去考古，寻获了很多的智慧闪光。

另外还要表扬一下本书的中文翻译，译文非常流畅，而且技术术语的表达没有什么显著的问题，非常难得。

高德纳说：software is HARD。

这就是本书的主题，这本书可以让非技术人员了解到“软件开发”为什么那么难。

作者在开篇就讲到：在开发软件的过程中，时间确乎时快时慢。如果一切顺利，就会进入“心流”状态；如果不顺利，则会陷入困境，举步维艰。这给全书定下了基调，软件开发的时间估计，是个大难题。为什么码代码不能像码砖一样定时定量呢？确实，如果你没有实际做过开发，会有这种疑问。一个人码一堵墙要十天，十个人就应该一天能完成啊。为什么开发软件就不行呢？这就是软件开发的一个本质困难性所在。过去几十年里，软件失败太多太多了，因为程序里错几个字符而炸掉的火箭就有好几发了，更别提大量乱成一团的政府软件项目了。

本书作者跟踪了一个叫做Chandler的个人信息软件的开发过程，给我们描述了这个大型的失败现场。

本书主角卡普尔是传奇软件Lotus 1-2-3的创始人。在PC时代的早期，是与比尔盖茨齐名的人物。卡普尔在Lotus时，曾经发布过一个叫做Agenda的个人信息管理软件。他后来离开Lotus，做过一段时间的投资，但他依然对做软件念念不忘，尤其是对Agenda这个软件魂牵梦绕。他想重新延续Agenda之魂。

卡普尔自己掏了几百万美元资助发起的OSAF（开源应用基金会），OSAF召集了一群非常资深的开发者，他们很多都曾在苹果，NeXT等公司工作过多年。OSAF的主要目标就是开发Chandler这个个人信息管理软件，卡普尔希望在这个软件里复活Agenda。

然而就是这么一个精英团队，在几年内却把Chandler的开发变成了一个大型失败现场。开发团队在不断的延迟下，艰难的发布了几个不太成熟的版本。就在本书作者离开这个团队去写作出版本书的第二年，卡普尔撤回了他的投资，Chandler项目彻底失败了。

从事后来看，OSAF团队在开发Chandler的过程中，犯了很多错误，卡普尔似乎完全忘记了他赖以成名的Lotus-1-2-3的成功经验了。我认为最重要的几条如下：缺少Constraints；目标过多；一些技术上的选择问题。

OSAF团队不缺钱，也不缺经验丰富的开发者，也不缺早期用户。OSAF有个金主爸爸，没有商业上的目标和压力，纯粹是为了爽去写软件。然而，没有限制反而让团队一事无成。伟大的作品，都是在有限制的条件下完成的。另外，团队里大牛实在太多了，大家在技术方案上讨论太久迟迟做不出决定。

OSAF在开始时，将Chandler描述为：跨平台、开源、P2P的个人信息管理器（PIM），重点功能是电子邮件和日历，全面贯穿来自Lotus Agenda的动态主义精神。它同时要追的目标太多了，而且其中很多目标与做一个成功的PIM软件并不相关。为了实现这些次要的目标，很多技术上的选择要为这些次要目标去纠结，走了很多弯路。在开发过程里也是难以突破，频频陷入失速的状态。

里面几个次要目标尤其影响恶劣，因为这些目标造成的技术选择也出现问题：

- 开源。使用开源软件开发模式，为了开源而开源。事后看，开源对这个软件对开发几乎没有任何的帮助。运行一个成功的开源组织，开发一个软件，其实是两个不相关的目标。

- P2P。浪费了太多时间，影响了最初的设计，最终还是回归到中心服务器的模式。

- 统一邮件、日历、联系人、TODO List等多种功能。它开始想干的事情太多了，心太大了。

- 数据的分布，同步与分享功能。这绝对是个大坑。凡是涉及到数据分布的系统，数据的一致性都是个大难题。比开始预想的要复杂的多。

- 跨平台本地应用。一个成功的应用，首先应该有用好用。一个能在三个操作系统上运行的垃圾，并不会因为是跨平台的而变成一个好的应用。跨平台GUI也是一个大坑，为了能在Windows，Mac，Linux三个平台上都能运行本地应用，团队选择了wxWindows这个库。wxWindows是C++开发的，要与Python相结合有很多工作要做，而且这个项目当时本身也不稳定。团队付出了极大的工作量，中途还自己搞了一套数据驱动的界面库。这一幕太眼熟了，我之前在工作中也遇到过类似的场景。在Chandler开发了两年后，基于Web Ajax技术开始兴起，团队错过了时间。我想哪怕不是用后来的Web技术，而是在三个平台上分别去开发，而不是搞一个统一的可移植版，或许都能更快。也许这里还有开源方面的考虑，团队可能直接就把VC/Delphi/ObjC这些平台专有技术直接排除了。

- 底层数据模型的表示与存储方案。在最初，团队曾经考虑使用一种主语-谓语-宾语三元组形式的数据描述。这就是之前语义网RDF的方式，也与Prolog，Datalog之类逻辑语言的Fact Database类似。但是最终团队选择了面向对象的数据库ZODB。ZODB是Python社区的一个古老项目，属于Zope项目，用于Python Object的磁盘存储与查询。我曾经在Zope技术上折腾过很久，ZODB确实不太适合这个项目，尤其是要用它来支持分布共享同步等功能。当然，这是个次要的问题。

这里要赞叹一下书里不断提到的Agenda软件。读书期间，我专门装了这个近30年前的DOS软件Agenda，在玩了一个晚上后，我惊奇的发现这个只有2M大小的软件，确实是非常的精巧。它的特性即时在现在也是非常的独特的。虽然Agenda在商业上没有取得成功，但它无疑是一个成功的软件项目。这个软件不像现在流行的各种GTD软件那样给用户限定一个框子，而是给用户充分的自由去输入和管理自己的信息块。

信息Item属于多个Category，用户可以自己定义各种View去灵活的查看管理信息。

软件的基本规则集足够小，而可能性无限。这就像围棋。或许就是这种自由度吓坏了用户。

Agenda在商业上没有成功，但是作为一个软件，它是非常精美的，堪称艺术。在掌握了它的精髓的人手里，会爆发出无限的可能性。但是对大众用户来说，上手太难了，人们无所适从，连Lotus公司都不知道该拿这个软件怎么办，最终只能将它抛弃。在二十年后，依然有一些死忠粉通过DOS模拟器，去使用这个三十年前的软件。

Agenda 与 Chandler真是形成了鲜明的对比啊。

卡普尔在担任OSAF主席期间，成为了Mozilla的主席，而Mozilla的Firefox浴火重生，成为非常成功的浏览器。这无心插柳的结果对卡普尔这位老英雄来说多少是个安慰吧。

书里后半段，讲述了人们几十年来，为“软件危机”所困扰，不断寻求解决方案的各种尝试与无奈。

在50年前讨论软件工程的一个国际会议期间，一位参会的IBM的程序员辛普森写文章嘲讽，这段实在有趣，我全文摘抄如下：

“辛普森假想了在公元1500年召开的一次旨在将艺术杰作‘科学化’的会议。会议试图定下《蒙娜丽莎》的创作标准，并建立一间研究所，推进伟大画作的有效生产。‘他们着手给杰作工匠们配备高效工具，帮助他们创作杰作，’辛普森写到，’他们发明动力凿、颜料自动挤压器等等……生产仍未达到满意程度……研究所花了两个星期计量一组画家每天绘制多少笔，而且很快将这一标准应用到对其他人的评估上。如果某位画家一天画不了二十笔，那他将明显没有达到生产力要求。很遗憾，这些知识进步对杰作的产出看来没什么作用，最后，委员会判定，难就难在管理上。他们很快就认命一位聪明的学生（名为莱昂纳多.达.芬奇）担任项目经理，让他负责为组织的其他成员分派颜料、画板和画笔。”

每一个被推上管理岗位的老程序员看到这一段都会会心一笑。而在这个文章里把软件与绘画创作类比，把程序员替换成画家，这在另一篇四十年后Paul Graham的文章《黑客与画家》中遥相呼应。

或许，本来就没有什么”软件工程“，这个词只是商业或官方的一个需求，并不是程序员的需求。Brooks在另一本书《设计原本》里提到过，瀑布模型的提出者开始是把这个模型当作一个假想的批评对象的，而最初的北约”软件危机“会议，提出软件工程，也可能是说软件和工程不是一回事。

写程序做软件，更像是绘画或写作。应该从好的作品中去学习，去临摹，通过模仿练习提高自己的绘画或写作水平。

软件开发更像是一种艺术，一种手艺。而学术界还有商业界，却对小作坊式的个人英雄主义式的开发方式心存鄙视，非要搞出一套正规软件工程方法。Joel Spolsky(Excel的项目经理)就讽刺说，这些人真正的目的是卖书。

软件开发或许应该维持在手工作坊的状态，用老师傅带学徒的方式。好的软件师傅就像庖丁那样，提刀而立，为之四顾，为之踌躇满志。

《人月神话》作者Brooks说：没有银弹。布鲁克斯规则说：往一个已经延误的软件项目中添加人手，只能让这个项目更加延误。

管理大师德鲁克也强调“知识工作者”的特殊性，管理艺术胜于管理科学，对人的关注胜于对定量的关注。

高德纳说：software is HARD。

如何避免陷入软件开发的焦油坑？Linux的作者Torvalds的回答是：别做大项目。

多少英雄所见略同。

计算机的硬件有摩尔定律加持，性能在稳步提高。而我们人类的认知能力，还有那更加本质的困难性：人群的协作，在过去几十年里，进展并不大。而每一代的年轻人，都要一遍遍的去踩过前辈踩过的坑，才能学到一点人生经验。

我记得在十几年前我刚刚入行时，“作坊式”开发方式是人们一致口诛笔伐的对象，只有微软那样严谨的开发方式才是先进生产力的代表。你的公司如果没有达到CMM5级，简直就是一种耻辱。大家张口都是“企业级”，“最佳实践”，流程，敏捷方法。

潮起潮落，十年过去了，我们这个行业有哪些进步呢？或许更好的编程语言、函数式编程理念、更好的软件库的出现，这些都推动了行业的发展。但要说这些能带来多大的改观却很难讲。过去十年，是资本推动下的流量商业游戏。在汹涌的资本大潮下，市场的喧嚣掩盖了程序员的呻吟。在市场热钱的涌动下，大量年轻的连学徒都没有当过的“程序员”进入这行。但总有新芽在寒冬的废墟中成长起来。

我这个老家伙，依然Dreaming in Code。

===========

一年多后回头看，我过去一年还是掉进了自己说过的坑。。。。。让一个画画的去负责分派颜料了。

(DOSBox下运行Agenda）

Chandler：