随便的感想
该信息来源与 豆瓣网
看的是这本书的中文版《梦断代码》，公司图书角借的。
一边读，一边感慨 --- 一个好的愿景，一帮牛人，不缺技术不缺钱，最终的结果却不如人愿。
对于书中的很多牛人来说，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年能有机器通过图灵测试吗？