今天又读了《梦断代码》，感觉对自己的帮助还是挺大的。第八章的题目是白板上的即时贴。在微软和许多态度严谨的软件公司中，长久以来都有一种法规定，即开发者必须使用自己正在做的产品，用来在服务器发布版本中找出最后一些产品缺陷。WebDVD的工作机制是扩展HTTP——Web服务器和浏览器之间的赖以互相通讯的协议——增加了让用户在远端服务器上编译文件的新命令，其内部建有冲突消除的机制——当两个不同用户试图同时修改一份文档时，决定怎么应付。Google类似于Chandler的方式，敲开了信息地窖，提供了简单约的界面，通过某种高超的编程技术，能比其他基于Web的程序更快的相应用户的点击。Gmai减少了桌面应用和Web应用之间的不同。
方法，在Chandler公布宣告后两年，OSAF在其中任何一方面都做的都不太好。OSAF也许没有足可交付给公众的产品，自从软件行业初期以来，这种那种方法论的拥护者们就一直在承诺他们的方法论是让软件项目按时、保质、在成本预算之内完成的独门秘籍。《软件阴谋》的作者马克·米纳西是软件缺陷的愤怒批评者，如果你相信我们已经知道需要软件做的所有事，那么也应该相信，只要足够努力、计划足够详细，我们就能让软件做的足够完美。
工程师和艺术家，在经历了IBM OS/360灾难和其他问题重重的大规模软件项目之后，仍然深陷冷战、并将竞争延伸到外层空间的北约成员国决定将软件项目视为紧迫的国际问题。他们召集了几十位智囊到德国的嘉美善，向他们征求对软件可靠性、质量控制、成本控制和进度安排的看法——将这些主题统称为“软件工程”。大会召开十年内，“软件”“工程”密不可分。工程师常被定义为将科学原则应用于满足 人类要求。但它也让科学原则背上创意的负担，将他从质朴的抽象里拉到挫折与愿望的妥协宇宙中，“工程”一词由法语转移而来，与“独创”同生于一个拉丁词源，指巧妙制作的能力。在计算机领域中，变化不可避免，我们设计的系统应该让我们从变化中学习、并且反过来影响变化。
通向狗食版之路，Chandler的三栏式结构和其他无数种程序少有区别——包括Microsoft Outlook在内，屏幕中部列出条目的概览试图，然后是细节视图，显示概览试图中被选中条目的详细信息，左侧放置了边栏，用户在这里组织条目集合、选择查看其中某类。Chandler将包括不同类别的集合：程序自动提供的“开箱即可”型集合，用户的“特别集合”型集合。边栏不仅需要考虑所有这些类别的集合，还得适应Chandler的无地窖结构，在这种结构中，条目可以保存到多个集合里，用户给条目打戳记、将条目从一种类别转换为另一种类别。
不知不觉就已经看完了，总体来说对我是有帮助的，感觉比之前读《从小工到专家》也强了。软件乃人类自以为最有把握、实则最难掌控的技术。
我之前没用过团队合作的经验，但是就感觉挺简单的，无非是两个人分工做一个项目嘛。但是今天读了之后才发现这里面学问挺大的。两人的合作又分几个阶段：萌芽阶段、磨合阶段、规范阶段、创造阶段、解题阶段。不同的阶段又有不同的技巧。对于同伴不注意代码规范而按照自己的习惯去写代码，可以合理的指出他的错误，但是一定得注意技巧，否则会造成你们之间的不愉快，我们要让他从心里的去改变这种习惯而不是只靠批评指责。所以以后跟其他人的合作，不仅要虚心纳谏，还要勇敢而委婉的指出他的错。