梦断代码阅读笔记之三

本文主要是介绍梦断代码阅读笔记之三，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

梦断代码阅读笔记之三

第6章：搞掂设计方案2003.7~11

程序操作、数据操作中非常重要的操作——备份。

在写一段代码的过程中，备份的操作可有可无，因为我们有undo键，一个错误的操作影响性很小，我们无须重写，只需要撤销。但对于程序的编写还是需要备份的。

但对于数据库的操作而言，备份操作却是必需的，因为数据库的数据安全收到多方面的影响，对于数据的失误，仅靠一个撤销键是远无法解决的。

项目的设计与文档是分不开的，在这一章中，Chandler文档、网页文档...将整个设计文档嵌入到web中进行讨论。对于文档的嵌套回归原本的计划或许比最新的技术更好操作。

CPIA设计文档通过Chandler初步实现了程序界中的乐高积木，采用了“顶底相接，从里到外”的思想。但OSAF并没有采用该文档，他们决心自己开发出“乐高积木”，这让我很惊讶也很佩服。OSAF启示着我们，时刻保持做自己的“经理”，建议做属于自己的大教堂。

OSAF的Chandler 0.2是一个令人沮丧的版本，它失败的因素有很多：OSAF围绕期限来做版本计划、这个项目中的开发人员都等在最后集成代码...这让我想起我的小组做大作业的时候，由于事先没有约定好项目的设计、web界面的显示...最后在集成的时候花了许多时间进行纠正，甚至将许多东西改的面目全非。所以我认为在项目开始之前将设计文档完善是必要的，当然，没有完美的设计文档，在实际操作中遇到的问题可以开诚布公的进行讨论，确定最终的结果。

第7章：细节试图 2004.1~5

OSAF创建了新的模块，创新了界面模式——让UI元素变成可以检查的数据。这个创新也启发了后来的程序员，没有必要按照传统来编写代码。传统虽然已经被大众所接受，但是没有创新，自己将不会进步。

程序员需要细节、蓝图、规格说明。从细节来说，俗话说：细节决定成败。在程序员的世界中也是如此，程序员需要数据的细节，界面的细节...在搭建好的框架中完善这些细节，从而使程序达到无懈可击的效果。再来说蓝图，程序员在个人发展的过程中，往往会丢掉自己的一些创造力，所以需要第三方绘制好蓝图，由程序员来实现。最后也是最重要的一个，规格说明，规格说明对于程序员来说就是法律或《圣经》，在我们平时开发的时候，没有规格说明的项目是最难操作的，规格说明包含了程序员开发过程中的所有需求和注意事项。

细节试图包含条目和与条目相关的信息，打戳是细节试图中一个好主意。

对于变量名和符号的处理，人脑远比计算机能干的多。书中以变量命名来进行解释，为了避免程序员修正缺陷的时候语义错误，匈牙利法应运而生。

没有歧义的沟通抽象概念，在我们平常编写项目的时候，我们会被一词多义的问题所困扰，我认为还是回归到设计文档，将特殊的词义进行特殊化处理。

第8章：白板上的即时贴 2004.6~10

“吃自己的狗食”——开发者必须使用自己正在做的产品，这句话的本质是自我检查。在有些时候，我们开发的软件用户并不一定会使用所有功能，所以需要最了解该软件的人（开发者）去测试它，找出不足，进而提高质量。

在白板上进行贴纸，对于个人或者小的项目可以在电脑上进行设计，对于大的项目就必须利用现实中的白板，白板上的即时贴我们通常会使用不同的颜色对模块进行区分，在进行项目设计和项目审查时，使用白板即时贴会帮助我们打开思路，明白整个项目的逻辑。

这篇关于梦断代码阅读笔记之三的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！