今天再次捡起梦段代码读，又有了一些新的感悟，感觉对自己也有了很多帮助。
第七章，细节视图，2004年OSAF发布了Chandler0.3版，包括了CPIA的工作版和更成熟的资料库，但只是满足了可能对卡普尔及其团队进度好奇的外部软件开发者们的兴趣。这也意味着原来为达此目的而放任设计组自行工作的应用组开发者们开始渴求一张更彻底、更接近最终需要的Chandler外观和行为的路线图。规格是每个成功许愿所必须遵守的东西，所以在编写规格说明就要十分当心。在做新程序时，程序员首先就要为程序使用的变量和对象命名。机器内存要求在变量名和内存地址之间存在一一对应关系。
第八章的题目是白板上的即时贴。在微软和许多态度严谨的软件公司中，长久以来都有一种法规定，即开发者必须使用自己正在做的产品，用来在服务器发布版本中找出最后一些产品缺陷。WebDVD的工作机制是扩展HTTP——Web服务器和浏览器之间的赖以互相通讯的协议——增加了让用户在远端服务器上编译文件的新命令，其内部建有冲突消除的机制——当两个不同用户试图同时修改一份文档时，决定怎么应付。Google类似于Chandler的方式，敲开了信息地窖，提供了简单约的界面，通过某种高超的编程技术，能比其他基于Web的程序更快的相应用户的点击。Gmai减少了桌面应用和Web应用之间的不同。
第九章，方法。在Chandler公布宣告后两年，OSAF在其中任何一方面都做的都不太好。OSAF也许没有足可交付给公众的产品，但却另有收获，开始有了工作流程，还有一套可能让它朝目标行进的可行的方法论。Chandler软件开发者很成组的共同开发一系列项目，他们像是专才们为制作一部电影而临时组合然后解散，在重新为下一部电影组合起来。所以，每次到新团队中开始做项目时，他们大概还是会按下“重置”的按钮，根据某些首要原则设计出一台新的工作流程。自从软件行业初期以来，这种那种方法论的拥护者们就一直在承诺他们的方法论是让软件项目按时、保质、在成本预算之内完成的独门秘籍。《软件阴谋》的作者马克·米纳西是软件缺陷的愤怒批评者，如果你相信我们已经知道需要软件做的所有事，那么也应该相信，只要足够努力、计划足够详细，我们就能让软件做的足够完美。
第十章，工程师和艺术家。在经历了IBM OS/360灾难和其他问题重重的大规模软件项目之后，仍然深陷冷战、并将竞争延伸到外层空间的北约成员国决定将软件项目视为紧迫的国际问题。他们召集了几十位智囊到德国的嘉美善，向他们征求对软件可靠性、质量控制、成本控制和进度安排的看法——将这些主题统称为“软件工程”。大会召开十年内，“软件”“工程”密不可分。工程师常被定义为将科学原则应用于满足 人类要求。但它也让科学原则背上创意的负担，将他从质朴的抽象里拉到挫折与愿望的妥协宇宙中，“工程”一词由法语转移而来，与“独创”同生于一个拉丁词源，指巧妙制作的能力。在计算机领域中，变化不可避免，我们设计的系统应该让我们从变化中学习、并且反过来影响变化。
第十一章，通向狗食版之路。Chandler的三栏式结构和其他无数种程序少有区别——包括Microsoft Outlook在内，屏幕中部列出条目的概览试图，然后是细节视图，显示概览试图中被选中条目的详细信息，左侧放置了边栏，用户在这里组织条目集合、选择查看其中某类。Chandler将包括不同类别的集合：程序自动提供的“开箱即可”型集合，用户的“特别集合”型集合。边栏不仅需要考虑所有这些类别的集合，还得适应Chandler的无地窖结构，在这种结构中，条目可以保存到多个集合里，用户给条目打戳记、将条目从一种类别转换为另一种类别。
整体这本书不知不觉的就看完了，但是感觉自己也没有看太懂，就好像过了一遍故事一样，也并没有延续像刚开始那样好奇的感觉。不过还是对一些细节有自己的体会的。让我感触最深的就是：软件是人类自以为最有把握、实则最难掌握的技术。也许这也是它为什么要起一个这么一个梦幻的名字的原因吧。