梦断代码阅读笔记之三

梦断代码阅读笔记之三

6章:搞掂设计方案2003.7~11

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

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

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

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

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

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

7章:细节试图 2004.1~5

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

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

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

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

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

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

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

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

 

posted on 2022-06-07 20:46  跨越&尘世  阅读(19)  评论(0编辑  收藏  举报