<<梦断代码>>读后感(三)

  今天又读了《梦断代码》，感觉对自己的帮助虽然不是很多，但依旧挺大的。第八章的题目是白板上的即时贴。在微软和许多态度严谨的软件公司中，长久以来都有一种法规定，即开发者必须使用自己正在做的产品，用来在服务器发布版本中找出最后一些产品缺陷。WebDVD的工作机制是扩展HTTP——Web服务器和浏览器之间的赖以互相通讯的协议——增加了让用户在远端服务器上编译文件的新命令，其内部建有冲突消除的机制——当两个不同用户试图同时修改一份文档时，决定怎么应付。Google类似于Chandler的方式，敲开了信息地窖，提供了简单约的界面，通过某种高超的编程技术，能比其他基于Web的程序更快的相应用户的点击。Gmai减少了桌面应用和Web应用之间的不同。

      第九章：方法。在Chandler公布宣告后两年，OSAF在其中任何一方面都做的都不太好。OSAF也许没有足可交付给公众的产品，但却另有收获，开始有了工作流程，还有一套可能让它朝目标行进的可行的方法论。Chandler软件开发者很成组的共同开发一系列项目，他们像是专才们为制作一部电影而临时组合然后解散，在重新为下一部电影组合起来。所以，每次到新团队中开始做项目时，他们大概还是会按下“重置”的按钮，根据某些首要原则设计出一台新的工作流程。自从软件行业初期以来，这种那种方法论的拥护者们就一直在承诺他们的方法论是让软件项目按时、保质、在成本预算之内完成的独门秘籍。《软件阴谋》的作者马克·米纳西是软件缺陷的愤怒批评者，如果你相信我们已经知道需要软件做的所有事，那么也应该相信，只要足够努力、计划足够详细，我们就能让软件做的足够完美。

    第十章：工程师和艺术家。在经历了IBM OS/360灾难和其他问题重重的大规模软件项目之后，仍然深陷冷战、并将竞争延伸到外层空间的北约成员国决定将软件项目视为紧迫的国际问题。他们召集了几十位智囊到德国的嘉美善，向他们征求对软件可靠性、质量控制、成本控制和进度安排的看法——将这些主题统称为“软件工程”。大会召开十年内，“软件”“工程”密不可分。工程师常被定义为将科学原则应用于满足 人类要求。但它也让科学原则背上创意的负担，将他从质朴的抽象里拉到挫折与愿望的妥协宇宙中，“工程”一词由法语转移而来，与“独创”同生于一个拉丁词源，指巧妙制作的能力。在计算机领域中，变化不可避免，我们设计的系统应该让我们从变化中学习、并且反过来影响变化。

    第十一章：通向狗食版之路。Chandler的三栏式结构和其他无数种程序少有区别——包括Microsoft Outlook在内，屏幕中部列出条目的概览试图，然后是细节视图，显示概览试图中被选中条目的详细信息，左侧放置了边栏，用户在这里组织条目集合、选择查看其中某类。Chandler将包括不同类别的集合：程序自动提供的“开箱即可”型集合，用户的“特别集合”型集合。边栏不仅需要考虑所有这些类别的集合，还得适应Chandler的无地窖结构，在这种结构中，条目可以保存到多个集合里，用户给条目打戳记、将条目从一种类别转换为另一种类别。

    不知不觉就已经看完了，总体来说虽然读不太懂，但是感觉比之前读《从小工到专家》强了点。软件乃人类自以为最有把握、实则最难掌控的技术。

    两人的合作不同的阶段（萌芽阶段、磨合阶段、规范阶段、创造阶段、解题阶段）有不同的技巧。对于同伴不注意代码规范而按照自己的习惯去写代码，你可以合理的指出他的错误，但是要注意技巧，否则很可能造成你们之间的不愉快，要让他从心里的去改变这种习惯而不是只靠批评指责。