“两打程序员，三年，4732个bugs，和对非凡软件的不懈追求”手机版团队竞技scar。Scott Rosenberg的新书Dreaming In Code 寄到了，果然没有辜负俺的期待和这句带有宿命意味的题记激发出的强烈好奇心。连花了两个晚上读完这本精彩作品。强烈推荐。作者把Chandler的开发历程，软件开发的历史，和软件开发的基础概念精巧地编织起来，只为探索一个问题：为什么软件开发那么困难？
先说说安逸的地方手机版团队竞技scar。首先是文字。作为多年文青，资深记者，Salon的主编，Scott Rosenberg的笔头没得说。三年漫长写作和Chandler项目的艰辛曲折并没有消磨Scott的热情。相反，他的文字蕴涵着他对软件开发的强烈热情，很有感染力。书里涉及大量技术概念，从OOP到Literate Programming到停机问题，作者都科普得浅显明白。看局外人怎么理解软件开发，也是颇有意思的事情。
其次是资料翔实手机版团队竞技scar。光靠Wikipedia和Google随意搜寻是绝对写不出这样一本书的。大量的采访，连续三年实地跟踪Chandler项目组开会讨论，几百篇参考资料，包括大量经典论文和访谈录，和作者细心的整理，方才构成这本书丰厚的肌理。
第三当然就是八卦满天飞了，尤其是著名项目和大牛们的故事及观点手机版团队竞技scar。呵呵。非常符合俺这种八卦爱好者的口味。虽然绝大部分八卦俺都知道，但放在软件开发这个大题目下系统读一次感觉还是不同。Alan Kay, Don Knuth, Alan Turning, Charles Simoni, Bill Joy, Frederick P. Brooks, David Parnas, Peter Drucker, Gerald Winberg, Douglas Engelbart等等等等。颇有新的领悟外，也是享受。书里也有一些俺从未听说的八卦。比如这条：一位叫Robert Britcher的程序员写了本回忆录，The Limits of Software，记录了美国航空管理局(FAA)1981年上马的AAS（Advanced Automation System）项目的悲惨过程。用Scott的话说，就是“没有人—哪怕作者—可以全身而退（No one—including, plainly, the author—escape scar free）。项目高峰期，1500名IBM程序员为FAA工作，每天花掉政府100万美元。项目最终失败了，因为项目的要求超出了当时技术和人力的极限。巨大的压力给参与项目的程序员带来心理上的严重创伤。有人砸烂自己的汽车。有人疯掉（我靠！），有人自杀。有个项目经理开始吃纸上瘾。项目拖后得越多，他在开会时嘴里的塞的纸就越多（靠靠靠！）。当初我读Ellen Ullman的小说The Bug的时候还对文中主角在地下室自杀有点不解。看来那也不是女文青Ellen自己的想当然。
书里记述了OASF(开发Chandler的组织)犯下的大量错误手机版团队竞技scar。这些案例值得我们学习。我觉得比较出奇的是Chandler项目成员开始决定用P2P架构这种来共享日历。虽然用P2P共享个人信息时非常困难的问题，但他们居然不全力设计相关算法或协议，而是花大量时间去讨论Chandler的界面。这一拖就是几个月。最后P2P架构被彻底放弃。Damien以一人之力搞出了基于文档的分布式数据库。不知道如果OASF找到Damien，情况会不会有所改观。Joel Spolsky已经写了篇关于OASF错误的详尽评论。强烈推荐。我就不饶舌了。
再说说让人遗憾的地方手机版团队竞技scar。书的背面有若干书评。第一条是The Atlantic的James Fallows写的，说Dreaming In Code可以和Tracy Kidder的《新机器的灵魂》（The Soul of a New Machine）媲美。Tracy Kidder的书是一代经典，写尽工程师的光荣与梦想。《新机器的灵魂》里电脑工程师为了做出新一代电脑同DEC的VAX竞争，破釜沉舟，灵魂冲突激荡。历经曲折后，项目终于成功。一时间彷佛东方有日出，喷薄欲破晓，好不酣畅淋漓。可惜，这种痛快的阅读感受在Dreaming In Code里体会不到。我想原因有二。一是Chandler是个失败（至少前途还不明朗）的项目。5年过去，几百万花掉，Chandler才到0.7版。当年的设计被一次又一次的更改。当年Mitche Kapor心目中的杀手特性被一个又一个地去掉。看到书的后半部分，俺甚至觉得有些郁闷。正因为这样，Dreaming In Code缺乏戏剧性。我们看不到有独特魅力的灵魂人物，比如《新》书里的Tom West，比如Show Stopper里的Dave Cutler。二是作者把Chandler的项目当作讨论软件开发为什么那么难的案例来写。这样做人物形象就显得比较单薄。书里很少描写Chandler项目组里的成员的心理和行为。我甚至不记得里面有谁曾经意气风发过。问题是，谁没有在设计自己心爱的软件时浑然忘我，神情激越过？这点更远远比不上《新》和Show Stopper。这两本书里的工程师有非常突出的个性。Dreaming In Code里看不到像Show Stopper里微软的愤青们鄙视IBM，决定中止同IBM OS/2团队合作的戏剧性场面的，看不到Jim Alchin早上五点钟跑到高尔夫球场与同事开会的疯狂场景，也看不到两个微软工程师决定到加勒比海边设计Windows NT的API，把他们的经理气得发疯，结果两人一周就搞定了1000多个API的初稿这样的传奇故事。甚至Mitch Kapor在Dreaming In Code里也像个好好先生。
另外一个小小的瑕疵（如果算的话）是Scott有时候会穿插大段软件开发的基本概念手机版团队竞技scar。有时候穿插得太多了一点。第八章和第九章基本全是软件开发的科普，显得有些游离主题。又比如Scott谈到在Chandler里处理可以反复发生的事件（比如说我在日历上加了一个会议，希望这个会议每周定时举行）不是件容易事。紧接着就引申到递归和图灵的停机问题。且不说这都是哪儿跟哪儿啊，至少我怀疑有多少读者对停机问题感兴趣。
Dreaming In Code里还有一些小错误手机版团队竞技scar。比如说作者提到Chandler的前身Agenda可以处理自然语言：用户输入”From year 2006-01-03 to next week”，Agenda能自动算出对应的日期。这没什么问题。可作者紧接着说，太多的软件不允许用户在电话号码或身份证号码中间加空格，加破折号什么的，可见这个问题的多么困难。这就搞笑了。识别日期的自然语言描述是个困难的问题。可不允许用户在一串号码中加分隔符就纯属程序员懒惰了。二者根本不能相提并论。
不管怎么说，Dreaming In Code是本非常不错的书手机版团队竞技scar。俺小声说一句，每个程序员都可以读一读。
blog.csdn.net/g9yuayon
