《代码大全2》读书笔记

第一部分 打好基础

第一章：欢迎进入软件构建的世界

　　1.书中的所述的软件构建，按我的理解就是软件开发，主要关注于编码与测试，但也包含详细设计、规划构建、单元测试、集成、集成测试以及其他一些活动。

第二章：用隐喻来更充分地理解软件开发

　　1.当程序员和行外人交流问题的时候，如何描述软件开发的问题呢？最好的方法是用隐喻。

　　2.书中举例子包含了一些常用的隐喻：软件中的书法-写作代码、软件的耕作法-培植系统、软件的牡蛎养殖观点-系统生长、软件构建-建造软件。

　　3.一般情况下，用软件构建-建造软件的隐喻基本可以让外行人理解软件的构造。你可以告诉他，你只是个C++后台程序员，相当于一个挖地基的建筑工人，并不擅长砌砖、装修。这样他也不会说有个很好的想法，就只差一个程序员了。还有，当你的项目经理和你说，只是把参数的长度由32位改成64位那么简单，你可以告诉他，把他家的承重墙向北移一厘米应该也是很简单的喔。

第三章：三思而后行：前期准备
　　1.前期准备的重要性：由上所述，前期准备就是建房子前的设计蓝图，倘若你连建什么都不知道，怎么可能建好一栋房子。

　　2.准备不周全的诱因：不能够抵抗“尽快开始编码”欲望（包括程序员和Ta老板）

　　3.前期准备要做什么：需要理解这个系统/软件应该做什么以及它该如何被做到这些。

　　4.前期准备之问题定义：“问题定义”只定义了“问题是什么”，而不涉及任务可能得解决方案。问题定义应该用客户的语言来书写。

　　5.构建需求：有了正式的需求就不需要再猜测客户需要什么，也减少后期修复需求问题的成本。稳定需求的神话，稳定的需求是软件开发的圣杯。不要期望用户需求不再改变，软件应该去拥抱需求变更（当然希望没有变更）。

　　6.如何应付客户临时提出的需求变更：客户只要想到一个新功能就会很兴奋。在兴奋时血液会涌向大脑，人就会晕头晕脑，他会把所有你们开过的讨论需求会议、签字仪式，以及已经完成的需求文档统统抛诸脑后。最简单的对付这种新功能中毒症患者的办法是说：“咦，这听起来是一个很不错的注意。不过由于它不是需求文档里的内容，我会整理一份修订过的进度表和成本估计表，这样你可以决定是现在实施还是过一阵子再说。”“进度”和“成本”这两个字眼比咖啡和洗冷水澡更提神。许多“必须要有”很快会变成“有就最好”。

　　7.需求核对表参考原书42页

第四章：关键的“构建”决策
　　1.书中的Sapor-Whorf假说：你思考的能力取决于你是否知道能够表达该思想的词汇。所以，程序员同样受到所用编程语言的影响，最明显的是现在我们的开发项目中，虽然用C++开发，但写的都是C的软件结构流程，忽略了C++丰富的面向对象能力。我们学一门编程语言，学到深处更重要的是学它的编程思想。

　　2.在一种语言上编程VS深入一种语言去编程：大多数的编程原则并不依赖于特定的语言，而依赖于你使用语言的方式。如果你使用的语言缺乏你希望用的构建，或者倾向于出现其他种类的问题，那就应该试着去弥补它。发明你自己的编码约定、标准、类库以及其他改进措施。

 

 

 

未完待续...