随便的感想
![](https://img9.doubanio.com/icon/u2793128-4.jpg)
这篇书评可能有关键情节透露
看的是这本书的中文版《梦断代码》,公司图书角借的。
一边读,一边感慨 --- 一个好的愿景,一帮牛人,不缺技术不缺钱,最终的结果却不如人愿。
对于书中的很多牛人来说,Chandler可能是他们的第二个系统,难道这就是人月神话中的The second-system effect?
在开发之旅中的遭遇的无数条“大蛇”,成为了几乎不可逾越的障碍,也使得项目的目标与计划一变再变。仅有好的愿景不够,仅有牛人不够,成功的系统首先必须是能够实现的系统,否则要么失败,要么事与愿违。
看完后,还特意找了下chandler这个产品,到1.0了,稍稍用了一下web client,还是不太好用。
-----
即使这本书没有完整地告诉我们“软件难做”的原因,chandler的经历仍然提示在哪些方面我们可以改进。
大致地为这本书做了个梗概,列了chandler开发之旅中遇到的一些问题和突破这些问题的方式,希望能够从中借鉴些什么:
第0章 软件时间
1. 抛出问题 - "软件难做",为什么?
第1章 死定了 [2003年7月]
1. 黑洞式的BUG
2. 一系列“蛇”难题:大家没能一致同意如何解决的问题
3. 黑洞与蛇造成进度延误
4. 加人解决不了:布鲁克斯法则 - “往延误的项目中补充人力,只会使其继续延误”
5. 大教堂的僵局
6. 开源集市并未解决问题
7. Chandler在最初的9个月,产出的幻想多于代码,因为:“每个决定都包含不确定性。地面还没有凝固,怎么能站得稳?”
第2章 Agenda之魂 [1968年~2001年]
1. Chandler为改变世界之梦驱动-超越Exchange,成为像Memex一样,扩展人类大脑的工具
2. 领导者卡普尔是Lotus 1-2-3的创造人
3. Agenda是卡普尔在Lotus参与的最后一个项目,打造了一个梦幻的信息管理软件
第3章 原型与Python [2001年~2002年11月]
1. chandler的愿景问题: 我们如何组织信息?如何对这种信息组织法建模--需要怎样的数据结构才能让计算机也能回答这个问题
2. chandler的功能需求: PIM,管理邮件、约会、地址簿、任务与备注
3. chandler的非功能需求: 跨平台、开放架构
4. 采用RDF作为核心模型
5. 构建原型Vista和Shimmer,Vista是一个前台程序,有音乐库管理功能, Shimmer是一个后台的基于RDF的数据库
6. 选择Python作为开发语言: 开源并且跨平台、成熟、有大量工具与库。
7. 卡普尔作出重要设计决定:不使用基于浏览器的客户端,因为认为实现不了丰富的交互。
8. 2002年9月,命名软件为Chandler,一个推理小说家的名字
9. 2002年10月,对外宣传为outlook杀手,并预估2003年底或2004年初发布1.0版。
第4章 乐高王国 [2002年11月~2003年8月]
1. 后台设计的重大决策1: RDF序列化 vs. 对象序列化? - 采用对象数据化,对程序员友好,而且效率更高
2. 后台设计的重大决策2: 采用现成的Python ZODB作为对象数据库实现
3. 后台设计的重大决策3: 使用互联网协议远程访问数据库,称其为RAP(Repository Access Protocol)
4. 前台程序采用预读方案提高数据获取效率
5. ZODB不能直接实现在多个地方存储同一个项目(非”地窖“式的信息是关键需求)的要求,项目组就是否重用ZODB进行讨论,始终悬而未决
6. 2003年4月发布第一个公众预览版Chandler 0.1,粗糙缓慢,很多功能不可用,数据库还是使用原型时的Shimmer
7. 2003年5月,数据库开发者换人,并再次明确需求:
(1) 以程序员为使用目标,提供革命性的数据模型
(2) 数据可以在任何地方存储
(3) 数据不能被破坏
(4) 数据可被快速取得
(5) 条目尺寸可以很大
8. 数据库设计形成了以“条目"为中心的方案
9. 出于“全盘控制”的需要,放弃ZODB,直接在BerkleyDB上编写数据库,并完成,终结了关于ZODB长达数月的争论
第5章 管束奇客和狗 [2003年4月~8月]
1. 要有人制定进度、要有人拍板做决定-而且言出必行,要有人创建或从别处采纳并修改流程规则。 -- 需要软件开发经理。
2. 决定推迟一些特性,包括一些杀手级特性,将近期目标收窄为基本的PIM软件
3. 开发进度如何度量?很主要的管理困扰
4. 引入WIKI作为沟通渠道,并由专人负责维护
5. 使用BUGZILLA管理BUG与任务
6. 开发了"状态管理器",管理进度
-- 花在工具上的工作,成了一种yak-shaving状态
7. 决定遵循“时钟驱动”的方案,确定2003年9月发布0.2版,但此时还没有完整的设计方案
第6章 搞掂设计方案 [2003年7月~11月]
1. 良好设计的原则:
(1) 坚固 - 良好的结构、没有缺陷
(2) 适用 - 程序就符合其设定目标之需要
(3) 愉悦 - 使用程序的体验应令人愉快
2. 直至2003年夏天,chandler仍处于有一堆原则,热情与许诺的阶段,还没有画出蓝图。设计方案确定,才完成程序宏愿与技术现实间的艰难交易。
3. 确定了第二个重要的领域概念: 文档 - 保存数据,也保存用于处理数据的代码与规则
4. 确定了在wxWidget上搭建CPIA - Chandler Presentation and Interaction Architecture,在前端实现数据驱动的组件架构
5. 2003年9月发布了更失败的Chandler 0.2版,功能比0.1更少
6. 由于0.2版的失败,决定放弃"时钟驱动"方案,还是采用"特性驱动"方案
7. 引入专职的UI设计人员,开始设计基于GTD原则的用户界面
8. Chandler不断重复回归,又回到了基本问题 - 人们如何组织信息?一套创新的工具如何能够帮助他们?
9. 项目经理离开,原因是自感工作没做好,他倾向于尽快交付产品,而Chandler要尽力保证架构上可靠,而且为了有个好架构宁肯无限推迟面世
10. Linus的言论:
"别做大项目,从小项目开始,而且永远不要期望它变大。如果这么想,就会做过度设计,把它想象得过于重要。更坏的情况是,你可能会被自己相象中的艰难工作所吓。如果项目没解决某些眼前的需求,多半就是被过度设计了。"
"别指望在短时间内达到大成就,我致力于Linux达13年之久,我想后面还得花上好些时间。如果一早就妄想做个大东西,可能现在还没动手呢。"
第7章 细节视图 [2004年1月~5月]
1. 2004年1月,基础架构的投资有了收获: CPIA、自动测试系统、能处理大量数据的数据库、Lucene与数据库协同工作
2. 开发者开始渴求一张更彻底、更接近最终需求的Chandler外观和行为的路线图,需要细节,需要蓝图,需要规格说明。
3. 但规格说明暂时还写不出来 - "开放性问题"始终没有答案:
(1) 共享信息引起的n向同步难题
(2) 围绕“条目组”管理的难题
(3) 条目的多态性难题
- 既希望chandler易于使用,也希望它能解决一些著名的软件难题 - 两者皆想要
4. 细节视图成为设计中的另一个障碍
5. 形成了通过"打戳"实现条目的多义性的设计想法
6. 术语的多义性成为项目组的障碍
7. 实行了通过在WIKI上维护术语表的方法,但流于形式:跟不上变化,成员对术语表不够关注
第8章 白板上的即时贴 [2004年6月~10月]
1. 让Chandler成为可以吃的狗食(内部可用版本)成为目标
2. 方案大逆转: 由P2P的共享到到基于服务器的共享
- 卡普尔解释: 我的观点有了重大变化。原来我太过前卫和理想化,立意虽好,奈何不实用。重要的是授人以能,而非架构本身。
3. 扩展WebDAV,设计CalDAV,用于基于服务器的日历共享
4. 为了能够在合理的期限得到狗食版(称为kibble版),只有砍特性。
5. 在即时贴上列出特性,在白板上画版本格式,然后在白板上排应该在每一个版本中的实现的特性:
- 0.4版: 27张
- 0.5版: 45张
- 0.6版: 33张
- >= 0.7版: 33张
6. 决定在狗食版中暂时只实现日历功能:
(1) 不再按照期望和断言能做的事“自顶向下”做计划了;现在是根据经验及证据“自底向上”做计划
(2) 延误与特性削减给团队带来了不良的影响,一些人离开了
第9章 方法
关于各种软件开发方法论的一个综述
第10章 工程师与艺术家
程序员的双重身份:工程师与艺术家,至今未变
第11章 通往狗食版之路 [2004年11月~2005年11月]
1. 服务器项目单独设置,称为Cosmo,由一个程序员负责,由于边界定义清晰,进展顺利
2. 通向狗食版道路上的一些进度杀手:
(1) 一个日历控件
(2) 难题: 重复任务
-- 侯世达法则: 时间总会比想象中用得多,即便你考虑到侯世达法则亦然
3. 开启浏览器版本项目,称为Scooby
4. 2005年11月终于发布Chandler 0.6
尾声 长赌
2029年能有机器通过图灵测试吗?
一边读,一边感慨 --- 一个好的愿景,一帮牛人,不缺技术不缺钱,最终的结果却不如人愿。
对于书中的很多牛人来说,Chandler可能是他们的第二个系统,难道这就是人月神话中的The second-system effect?
在开发之旅中的遭遇的无数条“大蛇”,成为了几乎不可逾越的障碍,也使得项目的目标与计划一变再变。仅有好的愿景不够,仅有牛人不够,成功的系统首先必须是能够实现的系统,否则要么失败,要么事与愿违。
看完后,还特意找了下chandler这个产品,到1.0了,稍稍用了一下web client,还是不太好用。
-----
即使这本书没有完整地告诉我们“软件难做”的原因,chandler的经历仍然提示在哪些方面我们可以改进。
大致地为这本书做了个梗概,列了chandler开发之旅中遇到的一些问题和突破这些问题的方式,希望能够从中借鉴些什么:
第0章 软件时间
1. 抛出问题 - "软件难做",为什么?
第1章 死定了 [2003年7月]
1. 黑洞式的BUG
2. 一系列“蛇”难题:大家没能一致同意如何解决的问题
3. 黑洞与蛇造成进度延误
4. 加人解决不了:布鲁克斯法则 - “往延误的项目中补充人力,只会使其继续延误”
5. 大教堂的僵局
6. 开源集市并未解决问题
7. Chandler在最初的9个月,产出的幻想多于代码,因为:“每个决定都包含不确定性。地面还没有凝固,怎么能站得稳?”
第2章 Agenda之魂 [1968年~2001年]
1. Chandler为改变世界之梦驱动-超越Exchange,成为像Memex一样,扩展人类大脑的工具
2. 领导者卡普尔是Lotus 1-2-3的创造人
3. Agenda是卡普尔在Lotus参与的最后一个项目,打造了一个梦幻的信息管理软件
第3章 原型与Python [2001年~2002年11月]
1. chandler的愿景问题: 我们如何组织信息?如何对这种信息组织法建模--需要怎样的数据结构才能让计算机也能回答这个问题
2. chandler的功能需求: PIM,管理邮件、约会、地址簿、任务与备注
3. chandler的非功能需求: 跨平台、开放架构
4. 采用RDF作为核心模型
5. 构建原型Vista和Shimmer,Vista是一个前台程序,有音乐库管理功能, Shimmer是一个后台的基于RDF的数据库
6. 选择Python作为开发语言: 开源并且跨平台、成熟、有大量工具与库。
7. 卡普尔作出重要设计决定:不使用基于浏览器的客户端,因为认为实现不了丰富的交互。
8. 2002年9月,命名软件为Chandler,一个推理小说家的名字
9. 2002年10月,对外宣传为outlook杀手,并预估2003年底或2004年初发布1.0版。
第4章 乐高王国 [2002年11月~2003年8月]
1. 后台设计的重大决策1: RDF序列化 vs. 对象序列化? - 采用对象数据化,对程序员友好,而且效率更高
2. 后台设计的重大决策2: 采用现成的Python ZODB作为对象数据库实现
3. 后台设计的重大决策3: 使用互联网协议远程访问数据库,称其为RAP(Repository Access Protocol)
4. 前台程序采用预读方案提高数据获取效率
5. ZODB不能直接实现在多个地方存储同一个项目(非”地窖“式的信息是关键需求)的要求,项目组就是否重用ZODB进行讨论,始终悬而未决
6. 2003年4月发布第一个公众预览版Chandler 0.1,粗糙缓慢,很多功能不可用,数据库还是使用原型时的Shimmer
7. 2003年5月,数据库开发者换人,并再次明确需求:
(1) 以程序员为使用目标,提供革命性的数据模型
(2) 数据可以在任何地方存储
(3) 数据不能被破坏
(4) 数据可被快速取得
(5) 条目尺寸可以很大
8. 数据库设计形成了以“条目"为中心的方案
9. 出于“全盘控制”的需要,放弃ZODB,直接在BerkleyDB上编写数据库,并完成,终结了关于ZODB长达数月的争论
第5章 管束奇客和狗 [2003年4月~8月]
1. 要有人制定进度、要有人拍板做决定-而且言出必行,要有人创建或从别处采纳并修改流程规则。 -- 需要软件开发经理。
2. 决定推迟一些特性,包括一些杀手级特性,将近期目标收窄为基本的PIM软件
3. 开发进度如何度量?很主要的管理困扰
4. 引入WIKI作为沟通渠道,并由专人负责维护
5. 使用BUGZILLA管理BUG与任务
6. 开发了"状态管理器",管理进度
-- 花在工具上的工作,成了一种yak-shaving状态
7. 决定遵循“时钟驱动”的方案,确定2003年9月发布0.2版,但此时还没有完整的设计方案
第6章 搞掂设计方案 [2003年7月~11月]
1. 良好设计的原则:
(1) 坚固 - 良好的结构、没有缺陷
(2) 适用 - 程序就符合其设定目标之需要
(3) 愉悦 - 使用程序的体验应令人愉快
2. 直至2003年夏天,chandler仍处于有一堆原则,热情与许诺的阶段,还没有画出蓝图。设计方案确定,才完成程序宏愿与技术现实间的艰难交易。
3. 确定了第二个重要的领域概念: 文档 - 保存数据,也保存用于处理数据的代码与规则
4. 确定了在wxWidget上搭建CPIA - Chandler Presentation and Interaction Architecture,在前端实现数据驱动的组件架构
5. 2003年9月发布了更失败的Chandler 0.2版,功能比0.1更少
6. 由于0.2版的失败,决定放弃"时钟驱动"方案,还是采用"特性驱动"方案
7. 引入专职的UI设计人员,开始设计基于GTD原则的用户界面
8. Chandler不断重复回归,又回到了基本问题 - 人们如何组织信息?一套创新的工具如何能够帮助他们?
9. 项目经理离开,原因是自感工作没做好,他倾向于尽快交付产品,而Chandler要尽力保证架构上可靠,而且为了有个好架构宁肯无限推迟面世
10. Linus的言论:
"别做大项目,从小项目开始,而且永远不要期望它变大。如果这么想,就会做过度设计,把它想象得过于重要。更坏的情况是,你可能会被自己相象中的艰难工作所吓。如果项目没解决某些眼前的需求,多半就是被过度设计了。"
"别指望在短时间内达到大成就,我致力于Linux达13年之久,我想后面还得花上好些时间。如果一早就妄想做个大东西,可能现在还没动手呢。"
第7章 细节视图 [2004年1月~5月]
1. 2004年1月,基础架构的投资有了收获: CPIA、自动测试系统、能处理大量数据的数据库、Lucene与数据库协同工作
2. 开发者开始渴求一张更彻底、更接近最终需求的Chandler外观和行为的路线图,需要细节,需要蓝图,需要规格说明。
3. 但规格说明暂时还写不出来 - "开放性问题"始终没有答案:
(1) 共享信息引起的n向同步难题
(2) 围绕“条目组”管理的难题
(3) 条目的多态性难题
- 既希望chandler易于使用,也希望它能解决一些著名的软件难题 - 两者皆想要
4. 细节视图成为设计中的另一个障碍
5. 形成了通过"打戳"实现条目的多义性的设计想法
6. 术语的多义性成为项目组的障碍
7. 实行了通过在WIKI上维护术语表的方法,但流于形式:跟不上变化,成员对术语表不够关注
第8章 白板上的即时贴 [2004年6月~10月]
1. 让Chandler成为可以吃的狗食(内部可用版本)成为目标
2. 方案大逆转: 由P2P的共享到到基于服务器的共享
- 卡普尔解释: 我的观点有了重大变化。原来我太过前卫和理想化,立意虽好,奈何不实用。重要的是授人以能,而非架构本身。
3. 扩展WebDAV,设计CalDAV,用于基于服务器的日历共享
4. 为了能够在合理的期限得到狗食版(称为kibble版),只有砍特性。
5. 在即时贴上列出特性,在白板上画版本格式,然后在白板上排应该在每一个版本中的实现的特性:
- 0.4版: 27张
- 0.5版: 45张
- 0.6版: 33张
- >= 0.7版: 33张
6. 决定在狗食版中暂时只实现日历功能:
(1) 不再按照期望和断言能做的事“自顶向下”做计划了;现在是根据经验及证据“自底向上”做计划
(2) 延误与特性削减给团队带来了不良的影响,一些人离开了
第9章 方法
关于各种软件开发方法论的一个综述
第10章 工程师与艺术家
程序员的双重身份:工程师与艺术家,至今未变
第11章 通往狗食版之路 [2004年11月~2005年11月]
1. 服务器项目单独设置,称为Cosmo,由一个程序员负责,由于边界定义清晰,进展顺利
2. 通向狗食版道路上的一些进度杀手:
(1) 一个日历控件
(2) 难题: 重复任务
-- 侯世达法则: 时间总会比想象中用得多,即便你考虑到侯世达法则亦然
3. 开启浏览器版本项目,称为Scooby
4. 2005年11月终于发布Chandler 0.6
尾声 长赌
2029年能有机器通过图灵测试吗?