梦断代码

刘二狗 2012-07-18 0

又见锥心系列，等忙完这段好好看看。

kasn 2014-11-26 0

了解下大牛开发项目的经历

limmylee 2010-03-13 0

这是一本残酷至极的书，让软件人都认为只要有足够的可用资源就可完成伟大的软件时，这本书给出相当大的否定答案。一群技术框架精英为了一个梦想奋斗两年最终以失败结束。这本的残酷之处还在于他给了我们这样的一警示和活生生实例，并没有办法告诉我们怎么避免和解决这些问题。

Young 2014-12-08 1

学习枯燥时看看这本书...

杨廷昱 2017-04-24 0

做软件仍然真的很难。然而，养孩子难，葬先亲难。出生和成长，与人同住和无人相伴，尝试去爱和无法去爱，接受他人致死或是接受自己之死－都很难。软件的困难是另一个世界，它自足，它理性，它不会心存怨恨。愿今生可为软件大厦添以某种全新之物，梦之所寄，行之所为。

Royee 2011-09-04 0

讲述了PIM工具Chandler开发的艰辛历程；作者行文比较散，读起来相当头痛，常常读了十几页不知道究竟发生了什么。也许只有一半多些的内容在讲项目的事，其他展开讨论或者引述的内容对从事软件开发比较久的读者没多少用处反而破坏了行文的流畅。另外翻译的质量实在不敢恭维，半文半白的读起来难受。比如非要用“拥趸”这个词吗，翻译拥护者或者粉丝难道不行吗，难道为了显示有文化？

LSJ 2017-03-28 0

甚至有点让人联想到伯罗奔尼撒战争，思考在软件项目中是否要民主公平。好的团队应该像一个优秀的球队，但显然钱德勒团队中的球星太多，或者自视为球星的人太多，球不够玩儿了。书中有很多有意思的细节如PHB等，都能让程序员会心一笑。花了半年的时间走走停停看完了。

lxy 2012-05-11 0

前一半很好，读到中段就读不下去了，因为作者给这个项目附加的条件太多了，假了。

夏草 2013-03-23 0

软件就一个字难！

Young 2014-12-08 1

学习枯燥时看看这本书...

Tony Yet 2011-12-02 1

没想到原来这本书包含了如此多个计算机领域的经典人物的故事，实在让人回味无穷。

刘二狗 2012-07-18 0

又见锥心系列，等忙完这段好好看看。

kasn 2014-11-26 0

了解下大牛开发项目的经历

limmylee 2010-03-13 0

这是一本残酷至极的书，让软件人都认为只要有足够的可用资源就可完成伟大的软件时，这本书给出相当大的否定答案。一群技术框架精英为了一个梦想奋斗两年最终以失败结束。这本的残酷之处还在于他给了我们这样的一警示和活生生实例，并没有办法告诉我们怎么避免和解决这些问题。

杨廷昱 2017-04-24 0

做软件仍然真的很难。然而，养孩子难，葬先亲难。出生和成长，与人同住和无人相伴，尝试去爱和无法去爱，接受他人致死或是接受自己之死－都很难。软件的困难是另一个世界，它自足，它理性，它不会心存怨恨。愿今生可为软件大厦添以某种全新之物，梦之所寄，行之所为。

Royee 2011-09-04 0

讲述了PIM工具Chandler开发的艰辛历程；作者行文比较散，读起来相当头痛，常常读了十几页不知道究竟发生了什么。也许只有一半多些的内容在讲项目的事，其他展开讨论或者引述的内容对从事软件开发比较久的读者没多少用处反而破坏了行文的流畅。另外翻译的质量实在不敢恭维，半文半白的读起来难受。比如非要用“拥趸”这个词吗，翻译拥护者或者粉丝难道不行吗，难道为了显示有文化？

LSJ 2017-03-28 0

甚至有点让人联想到伯罗奔尼撒战争，思考在软件项目中是否要民主公平。好的团队应该像一个优秀的球队，但显然钱德勒团队中的球星太多，或者自视为球星的人太多，球不够玩儿了。书中有很多有意思的细节如PHB等，都能让程序员会心一笑。花了半年的时间走走停停看完了。

lxy 2012-05-11 0

前一半很好，读到中段就读不下去了，因为作者给这个项目附加的条件太多了，假了。

我想说两句

梦想有时照不进现实

萧秋水 2009-10-20 0赞

我花了大概四个晚上（也包括白天的一些时间，不过白天的时间还是较少）阅读完这本书，说“完”，不算很确切，因为，有些地方是跳读的，有些读过的地方也并读不懂，毕竟我不是程序员，而且也不要求自己一定要读懂，我的目的在于了解chandler开发的历史，探究项目失败的原因。

说到缘起，还是和近来研究的GTD有关。在试用了多种GTD软件之后，我开玩笑地说，这些GTD软件都不好用，还不如自己设计一种。在对某位同事提及时，同事立即推荐了一个软件，chandler，一本书，《梦断代码》。

我很喜欢这种方式。他支持你的想法，但是，又能够给出适宜的建议，提醒你有可能面临的问题。相比完全不考虑风险的支持，以及毫不考虑成功可能性的大泼冷水，这是中庸的路线。

我从来不会自信到认为同样的事情，别人做会失败，唯有我可以成功；也不会因为同样的事情别人失败了，我就认为自己一定不会成功。GTD软件，是一个玩笑，可能做，也可能不做，尤其不会是放在今年做，因为今年我很清醒地知道除了我的工作要倾注大量心血之外，还有个人知识管理的研究要进行，这都是需要专注的事情，要得，就必须舍。

但是，这不妨碍我阅读这本书，事实上，我对这本书充满了期待，因为，诚如这本书的封面上所写的，“两打程序员，3年时间，4732个bug，只为打造超卓软件”，这样好的条件，为什么还会失败？从梦想到失败的路线，未必仅适用于一事，我相信，对于我所正在探究的个人知识管理，同样有借鉴作用。

当然，在读完这本书之后，我还是认为，我读这本书时间晚了，它最适合我的时间，应是在2004年至2005年间，当时我还在从事产品经理工作，正属于软件开发的一部分，我懊丧地发现，在离开产品规划4年之后，这个领域对我已经颇为陌生，可能对我来说，最具体的技能仅剩下项目管理——让我不要为我失去的而悲伤，反之，为我还拥有的而庆幸吧，幸而还有项目管理——也是因为有这点底子，我的确为chandler的开发过程感到惊异，有着美好的愿景，却没有良好的项目组织结构，也没有项目进度管理，过于宏伟的目标，不断转换的方向，不断推迟的进度，这些都是开发的大忌，却在一群优秀的人们之中上演达数年之久。

目前，很多开发人员，往往都在抱怨项目时间紧张，压力巨大，如果他们看过《梦断代码》，可能就会明白，没有时间压力，未必是能够制造出完美软件的必要条件，相反，那可能是一种扼杀，正是基于这个原因，不少程序员离开了chandler项目组，因为他们无法容忍长期制作不出产品。改变世界的梦想，终究需要一个实际的载体，否则，就只是自欺欺人。

这本书我先看到这里，我想目前我想拿到的答案已经拿到，暂时不准备重读，但这是一本好书，也许将来还会用到。

记录一些零碎的火花：

P51，意大利激进分子安东尼奥·葛兰西曾有名言云：要想改变世界，你得“理智上悲观，意志上乐观。”

P240，关于37 Signals的开发经验介绍，和chandler相比可以说是两个极端，但是前者成功了。照他们的做法，“约束是朋友。’约束是打造伟大产品的关键‘，弗瑞德说，’约束产生创意。如果有人说，给你全世界的财富，让你做任何想做的东西，那这东西多半永远发布不了。给我一个月就好！‘”

P254 关于软件工程师、硬件工程师和部门经理的故事，既滑稽也有借鉴意义，尤其是部门经理的那个思维，看后悚然暗惊，感觉和自己目前的状况是蛮象的。如果一味追求战略能力，却无法落实到战术，那么，当遇到危险情况，可能束手无策，或者纸上谈兵。这是需要戒之慎之的事情。

P310，作者提到一种Ecco Pro软件，“你手中的这本书，其全部研究工作的组织、汇整、纲目、交叉引用以及无穷无尽的调整也是用一套基于1993初次发布的Windows程序Ecco Pro来做的”。有机会的话，试用一下这套软件，看是否可用于写书。《名博是怎样练成的》是纯用DOC写成的，应该尝试一种不同的方法，现在是在用OneNote来组织资料，如果有更好的方式，当然是要用用试试。

P314，卡普尔说，“如果感到自己太过绝望，应该置之不理，避免采取行动——因为这种感觉往往是暂时的，多数只是见景生情。我反而会出去一段时间，一个小时、几个钟头、一天或两天。取决于何时能够重新振作精神”。这是一种情绪管理的办法，可以借鉴。

韩磊的翻译非常好。

附记：
我在0：26分开始写这篇文字，0：52分结束正文。我知道我突破了我的规律生活（23：00左右睡觉），但是，计划应该有灵活性，不能一味固执，在初读完此书之后，那种略含伤感的情绪，我希望能够记录下来，否则，到了次日，这种情绪会消散，写的文字的调子，会有不同。文字，很多时候就象钉子一样，能够把流动不止的潮水凝固成一幅画像，在回顾的时候，看到文字，也就看到心情。

重用or复写 that is the question.

云水 2009-10-23 0赞

Chandler的数据存储方式面临一个问题，现有的库不能很好的满足他们的需求，修改已有代码库还是独立开发自己的？于是产生了很有意义的一句话：

“一个已有的库可以满足我们80%的需求，而剩下的20%，恰巧是我们与众不同的地方。”

无独有偶，Subversion也面临同样的问题，最早的SVN服务器采取Berkeley DB作为存储方案，现在同时支持BDB和FSFS两种方式

面对这样的问题，重用or复写，个人认为有三个解决方案：
首先不能放弃与众不同的地方，否则还有什么开发的意义呢？
方案一，不用代码库，完全重写。
这个需要魄力与能力，不是每个人都能成功地快速地重复发明出轮子的。
方案二，先重用代码库完成Demo，然后逐渐替换掉代码库
这个需要良好的设计模式，否则替换到最后可能要完全重写项目。
方案三，与代码库开发者协调。
这个需要良好的沟通和预见能力，还要冒一定的风险。

to be or not to be, that is the question;
重用 or 复写，that is the question.

爱他就要离开他

[已注销] 2011-05-02 0赞

“编程语言有两种，一种是整天被人骂的，一种是没人用的”
——那为毛不用那种没人骂的？

怎样做出一个成功的软件？不知道。
你可以去问问总书记：你是怎么当上国家主席的？
“我没有想过当国家主席，是人民选择了我”

喂！不要这么悲观好不好。其实《三体》更加悲观呢。

---------------------别扯淡了，下面是严肃的------------

做软件从来不容易。但是做什么容易呢？

人类的智力活动从来没有达到今天这样的地步——几乎任何事物都需要编程——虽然你不一定感觉得到软件的存在。这很正常嘛，毕竟所有的东西到最后都归到数学，而面对数学我们就只能用算盘了。嗯，开个玩笑，是用计算机。

计算机本身是一个物理的玩意儿，他所承载的逻辑，也就是软件这一部分，是数学的。数学和物理的搭配就像董永和七仙女，卫斯理和白洁，于谦和郭德纲，潘金莲和。。。啊，走远了，反正就是绝配。但是问题的关键既不是物理亦不是数学，而在于使用计算机、编写软件的主体——人。

俗话说，计算机是高速的笨蛋，程序员是低速的笨蛋。低速的笨蛋用高速的笨蛋妄图造出优秀的作品，这不是扯淡么。且不说软件开发本身，就是最开始的需求，人们自己都搞不清楚。俗话又说了，一千个人眼里有一千零一个需求规格说明书，有一千零一的一千零一次方个设计说明书，有。。。额，所以你懂的，混乱啊！

于是问题就来了。那么怎么做出一个优秀的软件啊？答案就是，不做软件。记得Linus么，做Linux也是“just a hobby”，而“big as gnu”的内核也迟迟未能完成。计算机的历史上有多少优秀的软件是无心插柳而来啊，那些经过认真计划反复斟酌而来的软件反倒像是异类了。

所以？那么到底要怎么做一个好软件呢？不知道。不过我知道怎样做坏一个软件，书里面可都写了。想改变世界？除非你姓乔。还是先安安心心学好数据结构和算法设计吧，Linus写系统内核的时候可是已经敲了好多年的键盘了。这个，可不是偶然。

你越懂软件，就越不会去做软件

fatcong 2009-02-04 0赞

这是这本书正文的最后一句话，出自chandler项目的投资人和发起人。书其实很一般，一边讲chandler的开发过程，一边讲软件工程涉及到的历史，技术等等。总而言之，软件不是一种几个大牛合在一起就能作出来的东西。“做软件难”，这是文中Tex的创造者，也是计算机编程艺术的作者，高德纳做了十年Tex之后发出的肺腑感言。既然这样的大牛都说做软件难了，我们这等平凡之辈有什么底气能征服软件呢。文中还把编程和文学都当做一种创造性工作来比较，诗人会去不停地研究其他的作品，而且都会把自己的作品共享出来，而编程呢，有人不停地去精读经典的架构么，除了开源项目，好像很赚钱的项目都是闭源的，也许大家应该从中能学到点东西。其实看完这本书，我觉得还有一点，就是做软件难，管理软件项目更难，一点点感慨

少壮不努力，老大写程序

小魔@优雅穿梭 2011-12-28 0赞

一家美国软件公司的成员正围坐在办公桌前，愁眉苦脸地对着笔记本电脑，数落着软件Chandler所遇到的问题。突然，一个高个子、身穿蓝色外套的人推门而入，竟然是2000年竞选美国总统的戈尔！

    灰头土脸的程序员们看着神采奕奕的前任副总统，惊讶得一动不动，倒是一只偷偷溜进来的小狗欢快地摇着尾巴。这让应邀为程序员鼓劲儿的戈尔有点不知所措。他高声夸赞了一句“继续努力！你们正在改变世界”，随即逃跑似的离开了。

    别看戈尔看似随口一说，却命中了程序员的理想靶心。20多年，乔布斯游说百事可乐首席执行官加入苹果公司用的也是这招儿：“你是愿意卖一辈子甜汽水呢，还是跟我一起改变世界？”

    以0和1为基础的代码就像咒语一样迷得程序员神魂颠倒。抱着改变世界的伟大理想，每个学习编程的新手接触的第一个程序通常都是“Hello World”——输入一系列代码，召唤计算机，命令它打印出这两个词。

    这个程序其实一点用也没有，却可以唤起程序员的英雄主义乐观精神——瞧，我能叫机器说话，将来我能让它做任何事情！那种感觉像是诗人研好了墨，提笔准备在空白的稿纸上写下第一行诗句，等着瞧吧，传世之作就要诞生了。

    千万别告诉这位诗人，他每写完一行诗，就要花成倍的时间从里面挑错字。编码只占软件项目开发时间的1/6，剩下的一半时间，都花在测试和修正缺陷上面了。

    就算你去了软件帝国，照样要经历这些。在一连串病毒事件后，微软公司从2003年开始停止了所有新的大产品开发，编程人员转而投入到修正安全漏洞的工作上。

    漫漫代码路，绝望特别多，这还只是其中之一。美国工程师布瑞切尔曾经加入了为美国联邦航空管理局（简称FAA）搭建先进自动系统的开发团队。这个项目1981年启动，历时13年，耗资几十亿美元。最后得出的结论是：“这套软件没人写得出来。”

    视代码为命的程序员们被击败了，打败他们的不是工作负担，而是对于软件极限的挫败感。天生乐观的程序员总是相信，世上会有人失败，但那个人不是我。

    可惜，这次还真是你。开头提到的那群开发软件Chandler的24个程序员，花了三年研发软件，修正了4732个漏洞，依然无果。他们的故事被写进书里，叫做《梦断代码》。

    没办法，并非人类厨艺不佳，而是现实胃口太好。从孩子的玩具到大人的汽车，从商业和银行到医疗和国防——人类对软件的依赖像坐上火箭一样以指数级增长，但做软件的技能却像裹着小脚的老太太一样缓慢挪动。

    不幸总是相似的：一群激情燃烧的程序员挥舞着手臂冲向棘手的难题，发誓能够改变世界，后来，他们遇上了不靠谱的管理者，老是改主意的客户，不断变换的需求，以及最要命的，半成品里挑不完的漏洞。

    最后，大大小小的问题把这些技术工作者推向死胡同。在他们背后，会计师和律师摇着头收拾残局，脸上表情似乎在说：“我就知道，你们每次都这样。”

    在FAA的这场“可能是有组织工作史上最严重的崩溃事件”中，许多程序员崩溃了，有人砸烂自己的汽车，有人亲手了结自己的生命，一位项目经理靠吃纸来平复内心的挫败感。

    其实早在1949年，计算机先驱莫瑞斯·威尔克斯拖着打孔纸，带上楼装载程序的时候就预料到了这种未来：“我强烈地意识到，生命中剩下的好日子，都要耗费在给自己的程序找错误上头了。”

    没错，这就是事实，就像编程界经典教科书上所写的“软件难做”。我有一位同学很发奋，当上了某网站的产品经理。每当有人给他报错，他就会面不改色地咬着牙冷冷甩出一句程序员口头禅：“这不是漏洞，而是特色。”

    《梦断代码》

    [美]斯科特·罗森堡著韩磊译

    电子工业出版社

刊于2011年12月28日冰点周刊，本年最后一期影音书画
原文地址：http://zqb.cyol.com/html/2011-12/28/nw.D110000zgqnb_20111228_2-11.htm

软件开发，大抵如此

ConeZXY 2008-07-22 0赞

你住在一所还算舒适的房子里，发现冰箱可能有问题。冰块有时会融化，门也关不严实。修理工差不多个把月就得过来修一次。你注意到，这冰箱既笨重又费电，你看上了希尔斯百货公司（Sears）里面陈列的那些新款冰箱。是时候了。你立即出发，先到几个州看地块，考虑建一所新房。你请到贝聿铭和另外几位大建筑师，做了个初步设计。做这个花了点时间，所以你还得继续忍受那台旧冰箱，它发出烦人的噪音，在夜里叫人难以成眠。你看了几套方案，甚至建造了一、两个原型。时间流逝，你终于选定了设计方案。开始建造前，举办了一场狂欢宴。开工。建屋。庆祝继续进行，每块砖都令人激动。然后你改变了注意。你其实是想要一所铺着红木地板、有花园的日式房屋。你改造了已建好的部分。搬开一些砖块，铺上草皮。新房看起来真不错。某天晚上，你在新屋床上躺着，没听到冰箱发出的噪音。出问题了。安静令你无法入眠。花了太多钱！你压根就不想搬家！孩子们也不喜欢住到新房里。你女儿还说：“我恨它。”你只好改弦更张，不搬了。15年过去了，还花了几十亿美元，那老冰箱依然运转。大抵如此。
　　　　
—— 书中引用的一名工程师对IBM AAS项目的形容，该项目从1981年启动，在花费了几十亿美元后于1994年宣告终止，颗粒无收。

满书尽是大牛

Moskva 2008-09-06 0赞

咱不是搞软件开发的，当初在当当网订这本书，只不过是想了解一下一直在我心中比较神秘的软件开发是个什么样子。

虽然不是程序员，不过看得还是津津有味，尤其当读到项目发起人米奇.卡普尔是Lotus的创始人后，又感觉到了一些亲切：93年在我那一千多美金的386长城电脑上装的第一套盗版办公软件就是Lotus的办公套件，当时用得最多的lotus 1-2-3和wordstar估计现在已经很少有人能知道了。

书还没看完，书中陆陆续续登场的早期互联网编程大牛们让人感到精神振奋，诚如译者所说，书中充满了“古往今来的典故、软件领域的轶事”，让人读起来大开眼界！

心酸的感觉

看清楚了 2008-11-28 0赞

当一口气把这本书读到一半的时候，我突然有一种冲动：
给东哥发个短信吧，看看他是否看了这本书：《梦断代码》。

chandler 和竞开有着惊人的巧合。

产品希望解决的问题，计划采用的技术架构，创业初期的NB开发者。
做起来之后项目碰到的问题，反反复复的细节讨论，产品初期的媒体关注，产品release时候的效率瓶颈，发布的时候很多人认为是在做outlook，P2P技术的发明性应用。。。。。。太多的东西，想放电影一样，把3年前在点击的经历又温习了一遍。chandler开始于02年底，而东哥的构思则整整提前了一年是在01年，也许Kapor在点击8月份的发布会之后偷走了想法也说不定，那次发布会吸引了400多国内外媒体，济济一堂，马云那时候还来凑热闹呢。

老王拿着那个经典的牛皮笔记本，一遍一遍的翻开：我就是要这么一个活页夹，什么都能朝里面插，想要的时候，方便的取出来。。。。

佩服书的作者能在讲述一件事的时候，贯通古今的写法。看似在讲chandler的发展，实际上应该是在讲软件开发理论的发展吧。

软件这东西天生就是软的，硬来，怎么都不成！管好人，比什么都重要。

现在点击做的东西比OSAF chandler牛逼多了，距离最初讨论的东西也成熟多了，现实多了。

点击 02年做P2P的时候，那玩意刚开始提出来，还没有成熟的可以拿来用的协议，硬是自己写了一套，现在感觉还在用那个基础的通信DLL。

gmail 实现了部分chandler的NB想法

读后感（III）远虑和近忧

xinz 2009-01-25 0赞

完整评论：
http://yishan.cc/blogs/xin/archive/2008/11/18/iii.aspx

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

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

it has to make life easy for the Python programmers
it has to operate efficiently over a network
it needs to be able to handle very large individual date items and very large numbers of items
it has to be reliable, using database "transactions."
it has to support searching and indexing
[0] User experience //Kapor 后来加上去的，似乎不相干的一条远景。
后来对于Data Storage，又有如下构想：[p109]

Provide programmers with as revolutionary a data model as users
data can live anywhere.
Data is safe from corruption.
Data is quick to get.
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）的时候，都应该感谢当初设计者做出了正确决定，而那些坚持完美设计远景的项目，它们都到哪去了？

You're cursed and doomed!

Marius 2009-04-18 0赞

如果你懂软件可以读读这本书，如果你不懂软件更要读读这本书，因为我觉得你有必要了解生活中各方面所依赖的软件是如何“制造”出来的；就像想了解你喜欢吃的臭豆腐是如何做出来的一样。

我觉得软件是一件很有意思的事情，主要是因为我对形式化、抽象、复杂的人工物更能升华出一种美的体验。我固执地认为这种美在其他地方是难以重现的；有人认为人之间的事情是其乐无穷的，那么他在这种事情上面一定也是体验到了美的感觉。

其实这只不过是你的“一厢情愿”罢了。就像当你对一个美妙的Idea兴奋无比的时候，当你认为你在“创造奇迹”或者“改变世界”的时候，雪琳琳“焦油坑”正在不远的前方等着你，你获得的短暂的快乐将被无穷尽的针扎与痛苦湮灭。不过，程序员的“伟大”与“乐观”正在于此，忍受常人之不可忍受，并陶醉于等待快乐的痛苦之中。

用一句简单的话来讲，软件是由巨量的决定（策）组成的。当你越是认真地思考这个决定，你便越痛苦。因为你面对的是无知和完美倾向的双重挑战。

我希望我可以仔细地分析阅读这本书，以及书中提到的软件的方方面面，并分享给大家，但不是现在，因为实在是没有时间。这本书除了没有讲到软件项目管理方面的事情（那种大公司软件团队开发过程，可以参考Hard Code这本书），基本上是关于开发过程的内部微雕。如果你和作者对软件的理解不是相隔太大（知识层面或者是价值层面的），你可以透过这本书中的每一句话来感受到处于这个项目中的实际开发状态和人员心理状态（我在称赞作者的写作水品）。另外，这本书也是软件技术及其背景的普及之作，不是给大众普及，而是给软件业内人士普及（大多数的这些人很需要这种普及，不要以为软件就是条件判断、循环、返回或者打印）。

我不知道用什么话来总结这本书，因为这本书讨论了软件中太多的问题和因素，不是一两句话可以概括的。不过，我仍然想尝试一下：当我们试图从软件的内部去寻找成功的定义的时候，这是否就是一个方向性的错误？但是，若不这样，人类孱弱的理性就找不到一块相对牢靠的基石，便会——DOOMED！

human beings ……

Dreaming In Code

g9 2007-02-14 66

当年Lotus Development的创始银，Lotus 1-2-3的设计者Mitchell Kapor，离开Lotus后拉开单干，成立了开源应用基金会(OSAF)。他招募了一堆牛程，开发号称革命性的下一代个人信息管理系统－－Chandler。我还记得Mitchell Kapor宣布要开发Chandler的时候，开源社区一片鼓噪，媒体报道铺天盖地，哭喊终于有人出手，搞死天杀的Outlook，抽翻恶心的Lotus Notes了。那是2001年6月前后，黄历上写“忌：诸事不宜”。

一瞬间，6年过去。当年风头一时无二的Chandler勉强挣扎到0.7版。除了几个无聊的八卦银，比如我，和一堆开源的拥泵，比如Ted Leung，大多数人只知道《老友记》里有个Chandler胖了瘦，瘦了胖，搞定了人见人耐的Monica，2003年在新泽西乡下买了房子逍遥去了，导致老友们彻底散伙。

怎么回事呢？Mitchell Kapor算是当代最牛B的程序员兼管理者之一。OSAF下招募的老大们也是开源干将。大家不缺钱，不缺技术，不缺经验，不缺雄心，偏偏不能发布一款看似简单的软件，搞得中国足球队见球迷时的胆气都壮了不少。今年Scott Rosenberg的新书上架：Dreaming In Code。这本书详细讨论了一群牛人在长达6年的马拉松里面，犯了什么样的错误，导致一坨本来很有希望的项目半死不活。书里有八卦，有技术，有项目管理；有冷静的分析，也有狂热的布道；有编程高手泪洒键盘，也有商业奇才魂断开源。。。嗯，其实最后几句是我恶俗地胡说八道。不过书肯定值得一读。已经有人把这本书和史诗般的经典程序员故事Soul of a New Machine ，以及Show Stopper相提并论。当初读Soul Of a New Machine和Show Stopper时被书里的传奇人物传奇故事激动得彻夜难眠。Dreaming In Code真有那么动人，该是程序员的福气。

“两打程序员，三年，4732个bugs，和对非凡软件的不懈追求”。Scott Rosenberg的新书Dreaming In Code 寄到了，果然没有辜负俺的期待和这句带有宿命意味的题记激发出的强烈好奇心。连花了两个晚上读完这本精彩作品。强烈推荐。作者把Chandler的开发历程，软件开发的历史，和软件开发的基础概念精巧地编织起来，只为探索一个问题：为什么软件开发那么困难？

先说说安逸的地方。首先是文字。作为多年文青，资深记者，Salon的主编，Scott Rosenberg的笔头没得说。三年漫长写作和Chandler项目的艰辛曲折并没有消磨Scott的热情。相反，他的文字蕴涵着他对软件开发的强烈热情，很有感染力。书里涉及大量技术概念，从OOP到Literate Programming到停机问题，作者都科普得浅显明白。看局外人怎么理解软件开发，也是颇有意思的事情。

其次是资料翔实。光靠Wikipedia和Google随意搜寻是绝对写不出这样一本书的。大量的采访，连续三年实地跟踪Chandler项目组开会讨论，几百篇参考资料，包括大量经典论文和访谈录，和作者细心的整理，方才构成这本书丰厚的肌理。

第三当然就是八卦满天飞了，尤其是著名项目和大牛们的故事及观点。呵呵。非常符合俺这种八卦爱好者的口味。虽然绝大部分八卦俺都知道，但放在软件开发这个大题目下系统读一次感觉还是不同。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的组织)犯下的大量错误。这些案例值得我们学习。我觉得比较出奇的是Chandler项目成员开始决定用P2P架构这种来共享日历。虽然用P2P共享个人信息时非常困难的问题，但他们居然不全力设计相关算法或协议，而是花大量时间去讨论Chandler的界面。这一拖就是几个月。最后P2P架构被彻底放弃。Damien以一人之力搞出了基于文档的分布式数据库。不知道如果OASF找到Damien，情况会不会有所改观。Joel Spolsky已经写了篇关于OASF错误的详尽评论。强烈推荐。我就不饶舌了。

再说说让人遗憾的地方。书的背面有若干书评。第一条是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有时候会穿插大段软件开发的基本概念。有时候穿插得太多了一点。第八章和第九章基本全是软件开发的科普，显得有些游离主题。又比如Scott谈到在Chandler里处理可以反复发生的事件（比如说我在日历上加了一个会议，希望这个会议每周定时举行）不是件容易事。紧接着就引申到递归和图灵的停机问题。且不说这都是哪儿跟哪儿啊，至少我怀疑有多少读者对停机问题感兴趣。

Dreaming In Code里还有一些小错误。比如说作者提到Chandler的前身Agenda可以处理自然语言：用户输入”From year 2006-01-03 to next week”，Agenda能自动算出对应的日期。这没什么问题。可作者紧接着说，太多的软件不允许用户在电话号码或身份证号码中间加空格，加破折号什么的，可见这个问题的多么困难。这就搞笑了。识别日期的自然语言描述是个困难的问题。可不允许用户在一串号码中加分隔符就纯属程序员懒惰了。二者根本不能相提并论。

不管怎么说，Dreaming In Code是本非常不错的书。俺小声说一句，每个程序员都可以读一读。

外国大牛也不过如此

庄表伟 2008-09-18 37

花了一周的时间，看完了《Dreaming in Code》（梦断代码），看得我心潮起伏。对里面那帮家伙的评价也起起落落。最终的结论是：外国大牛也不过如此。

别看他们名头那么响，做了那么多超有名的项目，实际的能力（软件开发能力与项目管理能力）看来相当有限。感想很多，想到一点说一点吧。

1、以前有一篇文章叫“谦卑的程序员”，有这么一段话：“优秀的程序员很清楚自己的能力是有限的，所以他对待编程任务的态度是完全谦卑的，特别是，他们会象逃避瘟疫那样逃避‘聪明的技巧’”。但是，那些所谓的大牛，却一点的不知道这一点。一开始他们就决定要做一个桌面软件，然后打算用python+wxWidgets来实现。到后来我才知道，这帮家伙居然一个都不懂python的桌面开发。那个他们伟大的梦想——要打通所有的数据间的隔阂——究竟意味着多少技术难度，他们心里也一点数都没有。总之，这些“大牛”，让人想到的是自我感觉良好的“半瓶醋”。他们的目标太伟大了，这是我在看到这本书的中段的时候的体会。技术要最新潮的，软件要革命性的，要平台化以支持插件的，用户体验要最好的，代码要开源的，唯独工期是不确定的。越是伟大的目标，越是需要强有力的风险控制能力。再引用一遍范总的格言：“欲望不要超过能力”。而他们，就根本没有意识到自己的能力严重不足。

2、一个team中，牛人太多了！如何才能良好的合作呢？他们永远在开会，却始终议而不决，大家都是管过“大团队”的。要他们几个人合作起来Coding，就太难了。

3、还有一个证明他们不是“大牛”的证据是，他们缺乏技术决断力，那几年里流行起来的很多技术，他们都有随波逐流的冲动。比如他们尝试过RDF 来描述数据；尝试过Python的ZOPE；憧憬过P2P（但是他们的团队里没有一个懂P2P的）；企图从wxWidgets转到Mozilla的 XUL。。。怎么说呢？这样的摇摆和见异思迁，简直是典型的初哥的作风。真正的大牛，对于技术的趋势，以及如何在项目中运用，心中都自有判断的。

4、据说Chandler 1.0也正式发布了，我去下载了一个，希望能够有惊喜发生~~还是奇慢无比，根本就不具备实用价值！

5、如果是我来做这个项目的话，首先就不会在这么多个方面同时冒险。其次，在项目开始之前会先安排一个技术可行性的研究阶段。最重要的一点，我会早点把不称职的“大牛”开走。

开源的路在何方？

kimi 2008-12-26 25

  在图书馆的阅览室看了这本书，花了我两个小时的时间，午后的阳光透过图书馆的玻璃照进来，很温暖，可是我的心却一点点的凉了下来。
  再过半年我，一个计算机系的学生，就要投身到软件开发这个行业中去了，可没有任何经验，仅凭着那些薄弱的理论知识。边看书边记下自己的想法，害怕那瞬间想法的丢失。
  我看到了我推崇的开源技术的脆弱，我看到了软件工程的重要和繁杂，我看到了一个梦想的破碎。
  一个开源的项目，一个在大教堂模式的开源项目，怎么样取得成功，怎样才能避免失败。
  一开始他们只有一个想法，想建立一个各个平台都可以使用的时间管理软件，他们没有规格，他们确定技术和方向，他们没有确定人员，他们和规格设计，他们测试，他们没有里程碑，他们没有确定开发模型，他们只有各种各样的美好的愿景，纵使他们是天才，也一样要面临失败。
  现在回头看看他们的想法，他们选择了python和wxpython这本来就是不错的选择，可是他们没有中居然没有一个人熟悉python这门语言！什么语言并不重要，重要的是你的项目组里面是否有人特别熟悉这么技术，如果有，有多少人。
  如果一开始就选对人，那么就不会有那么多问题了，如果一开始就根据愿景确立里程碑，确定开发模型，比如说原型演化模型，如果建立了规格说明，建立编码规范，有自己的一套测试体系，而不是一昧地想搞出个超过outlook和exchange的软件，这个项目还会不会失败。
  如果成功，他们怎么盈利？当然，十分可惜我们看不到

  前段时间看到一则报道说有的企业说再穷也不上开源的ERP，感到很不解，现在终于明白了。支持，那么优秀的软件，缺乏支持，用户多了，怎么办，要知道软件最后就是为了服务其他行业，就是为了让那些普通的，不懂计算机的人也会知道使用。
  开源世界那么多优秀的语言，产品，框架，如果没有产商的支持，仅仅靠着几个开发者的热情，他们的使用空间，产品的寿命，在哪里呢？有多少商家采用wxwidget的。开源技术的强大生产力和商家结合起来才能产生更加巨大的威力，比如php之于yahoo，python之于gogole，java之于ibm
  易用性，这会是开源产品软肋吗？我们的开源软件的需求在哪里？好的，即使那是我们美丽的idea，我们希望有一天有很多一起来使用的时候，是否有考虑到用它的是一个不懂计算机的用户吗？
  UI，开发开源产品的都是程序员，他们的美观和大众的审美，相差太大了，王垠居然认为fwm2很美观，虽然我欣赏他的偏执，但是那界面真的很丑陋，优秀的开源项目是否可以吸引到同样优秀的UI设计师。
  文档，是否有足够的文档，Mysql可以成功而postgresql却没有达到相应的高度，不是技术上的问题吧。一个开源的项目的文档谁来维护，程序员的精力有限，谁来维护文档，用户？别开玩笑了。那些bug收集和解决，真的只由程序员来维护吗？
  最后，盈利模式在哪里？时间就是金钱，程序员就不是吗？他们公布他们的源码，他们不应该获得收入吗？如果不通过软件收钱，他们如何从用户获得报酬，他们都是活雷锋，可是我们不能让活雷锋饿死吧。如果是捐赠，是否有相应的工具，当然支部宝的小额报酬是一个不错的选择，那用户的习惯如何培养呢？特别是在中国一个已经习惯了使用盗版软件的国度。使用开源软件，从开源社区获得回报的中国的it企业，能不能也想ibm，sun，google一样回报开源社区呢？他们的付出习惯又如何进行培养？
我一直使用的一种开源笔记软件notebook的作者已经宣布由于个人精力有限停止开发了，有多少人，多少优秀项目由于相似的问题而停止了呢？
就像Raymond在《unix编程艺术》结尾说的那样，我们依然相信开源的力量，依然相信它可以改变这个世界，改进软件的生产力，但是希望的光芒在哪里？
  从接触linux离开，我了解和逐渐试着去理解开源界，有很多人把他们的代码贴出来，很多人热心的解答问题。也看到海威中文化linux的不断努力，看到的更多的一些专家的姿态，他们吹捧，却不干事实，他今天ubuntu，可是明天却会去支持java。
  中国那么庞大的学生，他们本应该是开源运动的生力军，可是有多少人了解开源文化呢？而我们的计算机老师又有多少了解的？还有多少人用linux大学教室和实验室，大学里给计算机系的学生用的实验室里装的linux居然是装在虚拟机里的redhat 9.0，这项在国外开始于校园的运动却不能在中国的校园很好的开展起来。中国的计算机学生，要读那么多的课程，被诱导去参加很贵据说很有前途的语言培训和各式各样的培训。最后一样要努力地去争取自己的职位。还要让IT业界说理论与实际脱节，让他们不爽，他们鄙夷没有实际经验。我们的动手能力在哪里丧失在哪里了？
  我们一直开脱说中国人的英语不好，不能给开源界作贡献，可是开发出nginx的那个俄国人的英语又会比我们好多少呢？难到他会过六级～！但是中国过六级的学生多了去了。我们的市面上有多少优秀的关于书籍是我们中国人自己写的，今天看到的那本开源书籍，只写了两个字，圈钱！
  但是我们依然充满希望，我们中国的开源界，给世界开源界提供了stardict，skyeye，minigui，lvs这样优秀的开源软件，我相信我们还可以提供的更多。

还是回到书里面吧，书里面那个优秀的软件已经出了1.0版了，离卡普尔预计的整整超过了四年！很可惜，当初开发的那些人都不在一起了，我把软件下载了下还是很大，30多M，安装的时候还出现依赖问题。
  GTD（时间管理）在现在显得越来越重要，甚至涌现出了各种各样的软件，有很多基于java的,很优秀，很好用，java的界面也再是当初那般丑陋。mozilla出了一款相似功能的日程管理软件叫做sunbird，有独立的软件，还可以作为thunderbir的插件和thunderbird结合起来使用。网络的迅速发展和ajax的使用催化了google canlendard的出现，可以在线日程管理，也许通过gears，人们可以离线修改日程然后在上传，这不正是分布式的功能吗？浏览器在人们的生活中显越来越重要了，firefox独特的插件开发模式和mozilla基金会的成功运作导致涌现了许许多多优秀的firefox的插件。手机在人们越来月重要了，也许下一个想法就是采用C＋＋或者QT或者python弄出一个在手机上的日程软件抢占先机，下一个战场－－>手机
不知道卡普尔回想起来会有什么感想，但是他作为一个探索者，他不是失败者，他是第二个成功者，他深陷的沼泽，被后来的开源世界一个个记住并且避开了，后世的成功离不开他的探索，所以他是永远的第二个成功者。
谢谢作者，他写了这么好的一个故事，谢谢韩磊他为我们提供了如此流畅的译文，可以让我在两个小时内读完它，虽然英文的译名读起来那么敖口。感谢福大图书馆，可以让我免费阅读到如此优秀的书籍和这样一个精彩的故事。
明天开始收起浮躁。
最后，书可以不可以便宜点啊，好贵。

有关软件工程的焦油坑

大徐 2008-09-25 16

结婚前夕我请假一天，躺在床上看了大半的《梦断代码》，Chandler项目时间从2002年转眼到了2004年，10月26日OSAF发布了 Chandler0.4版。2年时间里，整个项目组的人员从几人上升到了20多人，有人离开，更多的是新人加入。做为一款致力于“无地窖式数据处理”的开源PIM软件，项目组的所有成员似乎经历了软件工程中的一切噩梦。项目的计划不断延后，需求不断变更，技术体系不断调整，功能不断取舍。然而，世界一直在进步，“许多以前为Chandler发布高唱赞歌的外部人员抛弃了它，有些正式参与者认为它迷失了道理“。

2001年，卡普尔办公室外的机房里，放置着一台Microsoft Exchange服务器。“Exchange太过强大，功能远超小机构所需。Exchange也很昂贵：得置办一台服务器、购买Windows许可、购买 Exchange软件许可，如果没有全职技术人员，还得雇个咨询师，请他每月来几个小时作系统调整。在如梦方醒之前，你已经为保持日历同步花费了上千美金。”

人们需要一款超级软件能够帮助自己管理日历、电子邮件、任务、便条……等等个人信息。在2002年到2004年间，微软同样延迟发布了“那个美妙的、听起来与Chandler无地窖式数据处理手段相似的新WinFS文件系统”的发布。但Google发布了Gmail，并迅速赢得了一些用户的欢迎。现在是2008年的9月15日，Gmail发布几年以后的今年，少数人使用并疯狂热爱的现象一直持续到了现在。我身边的同事至少有5人疯狂的使用 Gmail管理日常的邮件和待办事宜，并通过Google一系列的服务完成自己日常的信息管理工作。

Google在Web上的成功好像嘲笑了传统软件行业，但软件工程的诸多问题并没有得到解决。“OSAF工作环境宜人－－午餐很好，工作时间有弹性，气氛非常融洽”。我想象在美国人烟稀少的中小城市的一座几层高的建筑物内，几个人一起密切工作并随时和来自全球的一些志愿者以及关注着在线沟通的情景。想像他们宽大的办公室里跑来跑去的宠物狗以及松散个性的办公桌。想象大家一起喝着咖啡，不慌不忙的讨论着一个又一个的问题的情景。他们几乎不为生计发愁，可以携带家人去国外度假1个月再回来工作。他们每个人几乎都有足够多的技能和经验，甚至某些人还在这个行业内有着举足轻重的履历。整个项目有想法，有钱，有时间，但却失败了。

这让我想起前几个月仅看过开头的《最后期限》，一个梦幻般的开局。富有经验的管理者，足够多的金钱和信任，随便挑选并且足够多的高智商、高能力的开发人员，一个任务甚至可以同时分配给3个开发小组来互相PK。似乎拥有了这一切我们可以作任何项目，开发出任何软件。似乎我们没有理由不成功，我们甚至会想，一定可以干的更好，更快速，更便宜、质量更好！但目前来看，不可能！

看到梦断代码的后半段时，我有一种开练的冲动，想拥有一个自己的工作室或者办公室的冲动。我认为我可以避免他们犯的大多数错误，虽然那些错误我也犯过，或者我曾经经历过的项目犯过。仔细想想其实不然，我现在正在经历的项目已经无可避免的犯了很多书中提到的错误，其中不少是我曾经犯过的错误。我们：

1，想的太多，总想做大事，并且眼高手低；
2，分不清轻重缓急，一上来战线拉的过长；
3，不知道自己到底要做什么，所有人员都陷入迷惘；
4，开会太多，总不干正事，特别是会议缺乏主题和快速达成结论的风格；
5，太多成员缺乏时间计划概念，对自己、对团队成员都没有时间计划；
6，不是缺乏计划就是计划不切实际；
7，需求不断变更并且没有人评估变更对项目整体带来的影响；
8，需求文档不清或者文档过多，产品经理缺乏对产品的构思和描述；
9，缺乏沟通，所有角色人员之间均缺乏有效沟通；
10，过于乐观，无论是领导还是开发工程师，总是过于乐观；
11，项目时间从后向前推，项目计划充满不诚实的欺骗；
12，自上而下的执行方式；
……

随便想想，这里就可以罗列出12条致命的错误，而且这些错误中的大部分我之前都遇到过。有些我有自信可以做好，有些我在发生前可以预知，有些看似没有办法。但这次不一样，我带领一个团队，几个小孩儿，好像并不是那么回事。之前做的几个项目虽然也会很忙，但终究会留下一些文字记录，但这次至今为止写下的文字很少。现在，我有些后悔，从封闭开发到一段时间的放任，到现在的高压，我忙于应付，基本没有留下什么文字记录。我想任何时候开始都不晚，从现在开始，一边记录新发事务，一边回忆并记录。我想找我身边共同经历过整个事情的同事多聊聊也许是正确的，也是应该去做的。

综上所述，我有种感觉，我应该大量记录我的工作情况和我的心理变化，甚至从一个旁观者的角度经常采访我的同事，以便于达到通过不同的角度阐述同一件事情的目的。我开始认为这个项目的经历对我而言非常重要，我需要文字来整理所有遇到的事情。我希望有朝一日有机会将这些文字进行整理，以对我自己和其他人有所帮助，为了达到这一目标，我需要每天抽出至少1个小时的时间来进行写作。

总的来说，这是一个虽然艰难但有前景的项目，是互联网行业和传统电信业的结合的项目。到目前为止已经经历了将近4个月的时间，分别在7月8日和8 月 1日发布了2个测试版本，准备在10月8日发布第一个公开版本。公司中的很多人，包括CEO和市场部的同事都认为我们作出的产品没有任何亮点和竞争力，和他们想象中的相去甚远。他们虽然明白不能一口吃成胖子，但实际的做法确实希望一口吃成几个胖子。

梦断代码的结局有些突然，作者没有再继续跟踪这个项目，但事实上3年的过程记录已经非常有代表性。Chandler项目发布了0.6版本，基本上成为一个可用的“狗食”版，但明显离最开始的目标相去甚远。几年中间已经多次调整过目标，内部和外部的环境也发生了非常多的变化，唯一不变的是软件开发者的精神。看到书中05年整个团队全家福的时候我还是有些吃惊，几年过去了，是什么维持着这个团队？是那几百万美金？是这里惬意的工作环境？是有挑战的工作内容？也许答案就是封面上的那句话，只为打造卓越软件。

可以说，在中国，这样的事情基本不会发生。我们能够承受的时间不会这么长，我们不会不求回报，不求市场化，不求被收购和变现的去长期的做一件事情。我们的工程师也没有机会去休假一个月，相反会每天加班，疯狂工作。我的领导一定会在人手不够的时候考虑快速招人甚至采用外包的形式，整个项目也许会来的快去的也快。总的来说，我觉得我面临的软件工程的焦油坑比那些外国同行们面临的更困难，而我们还经常走一些前人已经走过的弯路，这是更难过的一件事情。

一身一身的冷汗啊

铁观音加枸杞 2008-09-30 13

   这本书看了已经一半多了，就看完的这些部分说点自己想说的。开始看的时候，还是很轻松很调侃的在看老外大牛们的囧事。可是越看越发现这个项目里的很多扯淡的事情其实每天都发生在自己的身边。冷汗啊，一身一身的出，想想以前的很多事情，那真是不停的后怕。
   做技术的人，尤其是对技术痴迷的人，遇到一个问题首先想到的不是用户的体验，而是自己在技术上的快感。好像不用点什么新鲜的技术就对不起客户似的。其实呢？其实客户懂什么叫P2P吗？懂什么叫SOA吗？懂什么叫AJAX吗？这些其实都不是用户关心的。用户关心的是什么？用户关心的只是实现！只要能实现客户的业务需求，那用什么技术用什么方式真的有很大关系吗？
    在国内做项目，尤其是政府项目，都是关系先行。这种形式其实在某个方面给我们带来很大的好处的。其实大家仔细想想如果每个项目都按照合同的约定来完成的话，我们有几个项目是可以收到钱的？我们又有几个项目是可以不失败的？
    客户是上帝。可是我们真的是把客户作为上帝，还是把我们自己的技术欲望作为上帝了呢？

    终于把这本书看完了，大牛们的项目也终于失败了。看到后期一直在想一个问题。程序员到底是建筑工人还是艺术家？
    现在，国内受印度软件外包模式的影响，认为程序员就是建筑工人。一个完整的程序建立过程就是一栋建筑的构建过程。可是在实际过程呢？我们永远无法准确估计进度，就像我们永远不知道下一个巧克力是什么味道。
   “好，没问题，月底肯定能完成！”
   “哦！出了点小问题，再有一个礼拜吧？”
   “程序已经发到测试部了！有没有问题问测试吧！”
   “哦！这个我们没有考虑到等等吧，我们尽快！”
   “什么？你什么时候说过这个问题啊？”
    工程进度！？好像成了一个谜，而且是一个永远无法破解的谜！无法估计，无法考核。程序员总在认为自己的工作不是在累砖和泥！认为自己在从事一个艺术品，可是谁听说过艺术品还有规定工期和逻辑性的？
    所以问题还是绕回到最初，我们到底是在干什么？我是为谁在做？

梦幻一场？

Kiwi 2008-08-07 6

       前两天与同学交流时，同学让我谈谈软件开发与测试的区别，我说撇开技术和工作细节不谈（除了时常辅助地写些Unit Test外，实在对测试不甚了解），二者对待同一问题的心态上本该不同——测试人员大抵悲观而怀疑，开发人员往往乐观而执着。作出这样的推断，一方面作为一名开发者，我既品尝过编写代码的巨大乐趣（源自创造和控制的本能自豪与成就），也都经历过面对蜂拥而至的缺陷与复杂决策的困惑，因此窃以为若非迫于生计，一个没有万丈雄心与执着信念的人很难把编程作为一项长久事业的。反观一个出色的测试者，他必然疑心重重，极力对项目作出种种悲观预期并证明之，也往往只有这样才能挖出隐藏在程序深处的缺陷。

       当然，这里无意深入探讨开发与测试的异同，感兴趣的话dreamhead最近恰好有篇blog（http://dreamhead.blogbus.com/logs/24621087.html）对此做了引申。然而无论认可与否，开发与测试种种看似矛盾的观念恰恰为软件项目的复杂与艰辛做了很好的诠释。在项目漫长而未知的周期中，总是充满太多的偶然与选择，站在不同维度的思考与权衡也很容易推出截然相反的判断，最终除了依赖时间的检验，在决策之初，无论是局内人还是旁观者都很难总揽全局、明辨是非。《梦断代码》就是这样一部记述了OSAF团队（http://chandlerproject.org/Projects/OSAFPeople）心路历程与IT行业兴衰史的奇书。作者Scott Rosenberg凭借自己对OSAF团队那个野心勃勃曾立志超越Outlook的项目Chandler的三年潜心追随，与作为业内久负盛名的技术编辑对 IT行业数十年的洞察与积淀，用优美的文本及独到的视角向我们揭示了做软件为什么会那么难。

      Chandler的产生始于一个简单而美好的愿景——让人们能随心所欲地切合数据，更灵活友善地管理纷繁而琐碎的个人信息。然而诚如译者后记，众多程序员以心血养育它，惜乎全不见成效，六年半时间，上百万美元，几十号顶尖高手，换来梦幻一场，时至今日Chandler仍无定型......

      厌倦长叹，造化弄人！即便如OSAF团队这般衣食无忧、高手云集，在实现其“改变世界的梦想”时仍然受到现实的无情嘲弄，作为新来者，我们凭什么会认为自己与众不同？最让人难以接受的是OSAF团队从始至终一直在努力着，你很难断言究竟是什么过失使项目深陷其中，一切的发生既自然又出乎意外——就像一辆平稳行驶的火车，虽不曾出轨，但从上路的那一刻就已然驶上了一条不归路。资源不够？Mitchell Kapor可不是自私小气的人，6年半时间数百万美元的投资无不显示了其耐心。能力不足？能加入OSAF的队员就算不是功成名就的大师，在业内也算早已扬威立万的高手，何况开发Chandler项目的过程中他们还创建了诸如CVS，pyLucene等一批优秀的开源框架或工具，证明了自己的价值。决策错误？也许您会说Chandler不应该使用python，与其构建基于vxPython的桌面应用还不如构建基于浏览器的应用。但是OSAF团队的每项重要技术决策都是业内专家经过深思熟虑后的选择，当时谁又能料知数年后Ajax技术的风行会带动Web应用的普及？同样的关于项目延误、偏差的设问还能提出许多，但是每一项都没有足够的证据证明其是失败的根源，甚至有些因素在某种情形下对推进项目进展还起了积极作用。

      这真是一种莫大的讽刺——在软件项目中，程序员与管理者都力求以一种理性的方式精确、缜密地安排任务并估量进度，然而现实中本就不存在这种凭空的假设，任何计划都会被意外变化无情地打乱，最后整个项目沦为令人沮丧的一拖再拖，不可收拾。所以对于软件项目而言，没有绝对正确的规范或一成不变的流程，有的只是失败的教训与从中汲取的经验。在我看来，一个成功的管理者一定是经验丰富的（反之不成立），因为他切身经历了众多不同类型亡羊补牢的改进过程，对相似项目的把握至少在方向上不会轻易地重蹈覆辙。

      谈这些，主要源自我在大学时也曾组建并带领过学生开发团队，其间可以说既取得了出人意料的成功又经历了刻骨铭心的失败，就连毕设论文也专门针对软件工程专业四年的学习与团队管理方面的东西进行了反思，虽然多数观点不很被老师们认可，但至少个人以为这样的反思算得上对自己过去经历总结与理念的提升，比较有意义。《梦断代码》这本书是在4月份构思论文时从韩磊老师博客中获悉的，韩老师的翻译没有辜负我几个月的期盼，当然也不得不佩服作者Scott的巧妙构思与妙笔生花，在此一并感谢并极力推荐。

除了中间的跑题外，基本上靠谱

AlbertLee 2008-08-31 6

软件开发是件不靠谱的事。
不管是大教堂还是集市，不管是开源还是自由，都不能改变这个根本属性。
这么说，软件工程的爱好者们以及管理者们肯定要向我扔鸡蛋了。不过，我心目中的软件开发，大抵就是这么回事。
为什么？因为，真正创新性的软件开发总是带有一点艺术与作坊的意味。
我们可以制定计划，我们甚至也可以在规定时间内完成，但我们就是不能让它按我们预想的那样走，或许某些地方慢了，又或许某些地方大大加快了，最后偶然碰上dead line，算是很走运的了，还能奢求更多么？

除了软件工程方面的内容，这本书最吸引我的，莫过于里面对于动态数据软件的理念了：动态适应性的程序精髓。

在这一点上，我要牵强附会一下：I hate SQL。基于二维表，关系结构的数据库，是无法扩展的。至少是很难扩展的。（程序员不说绝对的话）

另外里面对于程序员喜欢研究工具，甚于拿工具解决实际问题的描述。我深有感触。因为这确实说中了我的要害。

对于wiki,我是抱持怀疑态度的，文中叙述的情形与我的想法相切合。
要想要一个wiki系统真正起作用，需要所有参与者知道所有的事情：所有的wiki结构，所有更新。没错，这些东西就摆在狂野里，所有人都可以看到，都可以去了解，但问题是，谁真的有时间或者有意愿去了解整个图景？！这不是使用者的错，也不是wiki的错。而是wiki出现在了不恰当的地方，或者被赋予了不恰当的乐观期待。

ps: 书中的案例项目： Chandler 确实看上去不错，在小组内装了服务器，几个人尝试着用起来。

Computer science is NOT a science, software engine

Joker Lee 2013-06-02 4

看完《梦断代码》以后，我一直在思索这本书的主题是什么，想了半天也没有头绪。翻到书一开始的《作者的话》，看到这么一句：「它提出问题，讲述故事」，啊哈，确实如此，作者回避给任何问题一个标准答案，甚至一点倾向都没有，以一个中立的观察者来讲述故事。好的书不仅在于传递知识或观点，更重要的是引发思考。这正是我给本书五星的原因。

确实，整本书主线在描述Chandler项目的故事，不断从项目的各种现象中挖掘软件开发中的各种问题，并旁征博引其他项目的故事，罗列大家对问题的各种观点和方法，但是几乎所有提到的问题直到今天都没有明确的结论，比如卡普尔和卡兹维尔的对赌：2029年会不会有计算机通过图灵测试。

所有问题的根本是：
软件开发是否能找到一个合适的方法论
软件开发者是工程师还是艺术家。

这个问题，总结了软件开发过程中无数细节问题，这些问题统统没有答案。软件开发领域的圣战比宗教中的还要多。从项目管理到软件设计，只有模糊的建议，以经验性方法为主导，估算工期的方法叫「拍」，拍大腿抑或拍脑袋。从代码到项目形态无不千奇百怪。

这本书隐约夹杂着一种无力又沮丧的情感。虽然成书之时Chandler项目还在继续，但是直到现在也没能推出能用的产品，项目可以说是完全失败了。项目中遇到的种种问题，至今也没有答案。

扯一些自己的理解。到底为什么不能像造桥一样开发软件？造桥和软件开发的区别在哪？软件开发领域惊人的熵，一方面在于所面向问题域的范围广泛，另一方面在于软件本身技术的高速进化发展，这两方面相互推动。

桥梁工程、建筑工程以及其他传统工程行业发展至今，面向的问题域已经非常固定和精确。而软件行业所面对的问题域却是无时无刻在变化的。1000年前的桥现在还在使用，而我们写的软件能用多久，10年？按现在互联网行业的状况，如果一年不做更新就被市场淘汰，10年之后，估计都找不到能运行程序的环境。

计算机技术近20年的发展速度有目共睹，从硬件到软件，技术更新换代速度之快，任何行业都望尘莫及。如今绝大部分的建筑都是钢筋混凝土结构，而常用的通用编程语言不下10种，各类编程框架更是数不胜数，并且在不断变化，如此对比可见一斑。何况写代码只是软件工程的内部方法，横向来看，软件工程的内部问题又包括计算、控制论、系统工程、人机交互等等。

这样来看，软件开发中遇到的问题，一方面是对问题域的理解和抽象的问题，另一方面是对软件开发技术本身的理解。软件开发团队，需要同时应对这两种难题

能不能像造桥一样写软件的问题，被细化分解成了两个问题：
软件工程的问题域什么时候能够收敛？
软件技术本身何时能够稳定？

这又是两个无法作答的问题。。。挫败感顿起

或许软件工程正好处在一个这样的阶段，刚刚兴起，发展迅速，体系模糊。亦或者软件工程并不是一种工程，它只是别的真正的工程领域中解决问题的工具。不过这个工具很复杂，材料是代码，建造方法是计算、系统工程和人机界面。Who knows.

梦断代码

青椒土豆丝 2009-10-22 3

压抑，真的很压抑。

我不是学计算机的，工作三年来一直在想一个问题，软件到底应该怎么开发才好，有标准吗？那些大公司都是怎么做到牛×的？每个项目我都在改进编程的方式，在改进软件设计的流程，修正架构。项目开始时，认为现在的方式很适合，比上一个项目的好，但项目结束时，又产生了新的想法，又开始否定现在的做法，然后满怀希望的在下一个项目中用上新的想法。

这本书很吸引人，或者说吸引做软件的人。总能找到似曾相识的感觉，哦，原来大牛们也在遭遇同样的问题，原来软件开发是这么的让人纠结。那就更迷惑了，大牛们都这样，我的那些想法能怎样？难不成我还真是那个有钥匙的人？那我先去买张彩票。阿门～

很巧，快看完的时候，知道OSAF失败了，我们公司也解散了。去年去北京，在中关村的牛×公司楼群里呆了很久，那个崭新华美的广告上写着“Change The World”。今天，而然间才发现，软件园的大楼里，也写着同样的话，“Change The World”，但破败的字块落满灰尘。

失败总有相似之处，反思我们的失败，寻找新的出路，无论是自己创业还是老团队继续合作，仍然将面对那一堆同样的问题。程序员都是乐观的，有完美情节的，那就继续，继续探寻。也许同样的场景还会重演，也许最终仍将失败，我也会写上墓志铭：“这里躺着一个软件项目，曾立志改变千万人，改变这个世界，却无疾而终。一群程序员以心血养育它，惜乎全不见效果。它是温室中的花儿，有过绚烂的梦想，还未绽放即已枯萎。在那软件的花园中，还有多少次凋零呢？”

时间轴+读书笔记

小萌 2014-05-15 3

        * 读这本书真得是消耗了太多的精力，倒不是书不好，而是自己太浮躁，很多书读不进去。
        * 第一次借这本书应该是2012年，没看几页就满30天，还。
        * 第二次是2013年初，毕业前，还是读不进去。
        * 这一次是2014年2月，在独墅湖图书馆借的，超期60天，终于字啊5月5日看完。
        * 其实真正看这本书，加起来也不到一周时间，27万字的非技术书籍，不需要花太多时间，可我这过去的90个/800多个日夜，都做了些什么呢？
        * 喊了无数遍浮躁，从来没安静下来过。

终于读完了，长嘘一口气，记了3700字的读书笔记，贴上来分享下吧，虽然有点乱。

时间轴

        * 2002-10 第一个官方声明（挖了很大一个坑，群众的期待太高）
        * 2002-10 kapor start to write blog
        * 2002-11后台工作陷入困境
        * 2003-01-底第一次集成~
        * 2003-02-20 pre-alpha发布
        * 2003-03 toy到岗，development manager，制定开发计划
        * 2003-04-21 v0.1 第一个公众预览版，24小时15000次下载
        * 2003-06 roy开博客
        *
                * 1. 反思进度为什么特别慢
                *
                        * 更民主，缺少等级结构
                        * 遵从集体意见，作决定很慢
                        * 等级结构是把顽固程序猿组织起来的有效手段
                        * 在网景，写代码是重中之重，解放人力有助于写代码就是好决定；在OSAF，很难为写代码扫清障碍

                * 2. 新项目，重起炉灶，不确定性大
                * 3. 幻想多于代码；hertz让开发者停止设计，开始编码->先干起来，再变成大东西->激情开干，然后顺其自然

        * 2003-07-17 第一章死定了
        * 2003-09-25 chandler v0.2 比v0.1还差
        * 2003-10 首席开发经理 micheal toy辞职
        * 2004-02-26 chandler v0.3 包括CPIA的工作版和更新的资料库
        * 2004-05-18 老大kapor宣布退出团队会议，不负责细节，授权给经理自治
        * 2004-04-01
        *
                * microsoft宣布longhorn推迟发布
                * google在愚人节发布gmail，包含很多特性，比如邮件不用文件夹，用搜索，AJAX
                * osaf和ms都步履维艰，新一代产品以web形式出现

        * 2004-09-07 开始用贴纸而不是excel记录work item->v0.4 27张，v0.5 45张，v0.5 33张，v0.7以后33张，太多了->此计大秒
        * 2004-秋天 v0.4
        * 2005-03-29 v0.5
        * 2005-11 v0.6

        * 人物表
        *
                * mitchell kapor 莲花创始人,OSAF发起人，资助者
                * michael toy
                *
                        * rogue龙与地下城
                        * SGI部门管理
                        * 网景创始人之一

                * andy hertzfield / matintosh kernel
                * john anderson系统架构师，mac
                * lou montulli
                * jed burgess新手
                * katie parlante，stanford girl , 新手
                * roy & aleks totic，在网景发家，后来在湖边无所事事，又出来干活。干了6个月后离开chandler，“我太具破坏性，想把事情快速地推动起来，组织里有些人希望谨慎，安全的开发方式”，roy去eclipse做python模块, aleks回湖区搞创投
                * chi-chao Lam,PM
                * Pieter Hartsook,PR记者，分析师
                * David McCusker 数据存储
                * jage jibs-stanford GUI
                * mimi Yin，UI designer
                * lisa 杜索特:2004-03加入，负责webDAV标准

读书笔记

        * 我看到了什么：
        *
                * 很多软工的名言/总结（摘录于书中）
                * 硅谷不同工程师的生活

        * 只有任务分工给互相无需沟通的人，人和月才是可以互换的
        * 软件受到“序列约束”，限制了任务的分解程度
        * 开源：
        *
                * 只要有足够多的beta半测试人员和开发者，bug发现很快(这是chrome区别于IE的地方，商业公司也能用开源的思路开发软件)
                * 反对声音：
                *
                        * 技术支持少
                        * 分支，另立山头

        * 莲花的anenda失败
        *
                * 太超前
                * 错过公司的战略，无辜牺牲
                * 创新和灵活性对于用户来说太多

        * 写软件灾难的书很多
        *
                * 《软件开发滑铁卢》《死亡之旅》《软件极限》
                * 故事总是这样的：一群激情洋溢的程序猿，面对棘手问题，被坏经理/需求。。最后等会计师和律师收拾残局

        * 没有银弹
        *
                * 构建软件系统最难的就是精确定义要做什么东西
                * 选项太多，随性而为，心血来潮

        * 后台陷入迷宫后
        *
                * 请别重复发明python和zope，开发者已经创造出来，积累大批绝佳的技术财富
                * 做好项目的关键在于复用，继承成功经验，而不是重造轮子。
                * 看看用多少代码就可以写出来吧

        * 《人件集》
        *
                * 程序员喜欢写代码
                * 而不是看文档，看别人的代码
                * 同等条件下，喜欢重头设计制造
                * 不肯研究别人，甚至都不看一眼
                * =>开源和google改变了这种情况，缩短寻找的时间
                * per/python也提供大量的库，省的耗时造轮子
                * 库多了，也会搞不清哪里有，会重复
                * =>信息过载是最大挑战！
                * sourceforge/github上面肯定有人造好了，只是：找不到/找到太多选择

        * 可复用软件悖论
        *
                * 总能找到满足大部分需要的代码，然后，那部分做不到的，恰好是这个项目需要创新的地方->创建项目的出发点~

        * 他基本上一事无成，不管原因何在，总之就是没做出东西来。
        * 他开始干，而且做到了，尽管有点脆弱~
        * toy他具有衡量好的development manager的唯一资质：有据可查
        *
                * 不擅长处理人员事务：指导、绩效考核等

        * 《硅谷革命》revolution of vally
        *
                * 回忆macintosh岁月

        * 软件开发对【绩效考核】有天然的抵抗力
        *
                * 行数不是衡量好参数
                * 难以划分成难度或尺寸相似的单元，时间也估不准，bug修复的难易也不同
                * 不同程序员生产力差10倍，配置人员和预估时间一样充满挫败感

        * Linux对做大型开源项目的建议：别做大项目
        * demo day很有效果，每次例会让大家演示小进步，使大家欢腾
        * 特性驱动还是进度驱动？两者都有
        * 【布鲁克是法则】人月神话
        * 跟踪进度是为了协调工作，而不是表扬和批评谁。//要求两周发布一次里程碑，但是这也耗掉了很多时间
        * 【招人】如果多招一倍的人呢？第一年会拖慢进度，第三年才会开始有回报->可是我们的work item大概是两年时间->懂了
        * 【工作环境】环境宜人，午餐很好，时间弹性，气氛融洽。mimi yin可以早上去上瑜伽课，晚点到；某人可以在西雅图一个岛上工作，几个月来一次bay area
        * 【软件开发计划】
        *
                * 提供详细计划和日程安排， watts humphrey,IBM OS360项目管理大师
                *
                        * 1. 计划是强制性的
                        * 2. 计划是自底向上，由程序员的经验而来，而不是管理者拍脑袋和市场期望而来

                * 后来watts做出CMM模型
                *
                        * 第一级什么都没做
                        * 第二级组这做些计划，跟踪，配置管理
                        * 第三级定义过程，如何工作，如何完成任务，可训练的事项
                        * 第四级有跟踪自己工作的框架
                        * 第五级持续改进过程

                * 瀑布模型
                * 螺旋模型，更快迭代周期的小瀑布
                * Kent Beck等17人： Agile software development
                *
                        * XP extreme Programming
                        *
                                * 适用于有经验coder组成的小团队
                                * 先写测试
                                * 和客户一起
                                * 结对编程，多人看

                * Joel spolsky on software
                *
                        * joel test: 12 question
                        *
                                1. source version control
                                2. step build?
                                3. daily build
                                4. bug datebase
                                5. fix bug before write new code
                                6. work item match work doing
                                7. rules
                                8. quiet environment
                                9. best tools in the world
                                10. tester
                                11. write code when interview
                                12. 走廊测试（随便拉个人过来做测试）

                        * 12分最佳，11可以接受，10分以下很差，因为微软一直是12分
                        * 微软质量高，但太慢。
                        *
                                * 就像军队内务，保持战斗力，但耗时间。
                                * 微软80%-90%时间都在做内务

                * 37 signals
                *
                        * 一个在丹麦的程序猿搞定，只做web,因为时差，每天讨论时间很少，程序员专心工作
                        * 用ruby，后来把框架抽出，就是ruby on rails
                        * “灵活性被过分高估，约束才是解放”，约束程序员的可选手段，让编程更简单
                        * google也是小团队，开发周期紧迫，上线再根据反馈改进

        * 更多阅读
        *
                * chrome的开发方式
                *
                        * http://en.wikipedia.org/wiki/Google_Chrome
                        * http://www.niallkennedy.com/blog/2008/09/google-chrome.html
                        * 开源的团队！
                        * 每次build，都依赖很多外面的东西

                * cm的开发方式，steve Kondik
                *
                        * 第三方rom,短时间内发布最新android的优化版本
                        * 3000+ development & user
                        * 7人核心core team
                        * 市场
                        *
                                * 很多厂商没精力升级非主力机型的rom，cm吸收这些用户
                                * 硬件成熟使得rom作用越来越大
                                * 中国是主要市场，有一切：用户，rom，碎片化生态圈，没google的控制

附我的短评：
精彩的软件工程故事书，讲的不仅仅是chandler开发的故事，还引经据典，讲述和总结了很多其他软件的开发过程/不同软件开发理念等等。

初期看这本书，其实是想了解基金会+开源这种软件开发模式。

读完这本书，发现看到的不仅仅是chandler的开发，也是很多其他软件的开发过程。

内容很丰富，很适合作为软工入门学生的科普书籍。如果我是老师的话，我会推荐这本书给本科生。

我要写长评

想读在读读过

标签(多个标签以“，”分开):

保存

梦断代码

推荐文章

猜你喜欢

附近的人在看

推荐阅读

拓展阅读