在一年一度的寒假中，每个人都是很懒散的，都享受着寒假过年的喜庆和快乐中，但是也不能忘记自己的本行，在这个寒假，我阅读了一本名为《代码大全2》的书籍。读后感其一如下：
作者写这本书的首要目的，就是希望缩小本行业中一般商用实践与大师级人物及专家们之间的知识差距。许多强大的编程技术在被编程领域的大众接触之前，都已在学术论文和期刊里尘封了多年。
成功学大师拿破仑希尔说过:什么思想决定什么样行为;什么样行为决定什么样的习惯,什么样的习惯决定什么样性格,而什么性格决定什么样的命运。
本书给我印象较深刻的章节有：前期准备、软件构建中的设计、防御式编程、表驱动法。
前期准备中包括了需求、架构方面的知识；软件构建中的设计中包括了设计模式、设计方法知识；防御式编程包括了在实际编程中很少关注的处理程序容错性，让出错误更容易发现、更容易修改，并减少错误对产品代码的破坏；表驱动法介绍了一种编程模式，从表里面查找信息而不是使用逻辑语句。
一、打好基础
1、软件构建世界
软件开发的主要流程：问题定义-〉需求分析-〉规划构建-〉架构（概要设计）-〉详细设计-〉编码与调试-〉单元测试-〉集成测试-〉系统测试-〉交付或发布-〉软件维护
各个过程与软件构建的关系如下图：
2、用隐喻来更充分地理解软件开发
软件隐喻更像一个探照灯，而不是一个路牌。它并不能告诉你在哪找到答案，但却能告诉你如何能找到答案。更像一个启发式的方法而非一个算法。隐喻把软件开发过程与其他你熟悉的活动联系在一起，帮助你更好地理解。
一般的软件隐喻有以下类型：
1）写作代码
这种隐喻认为开发方式就像写信，如果写错了，抛弃即可。对于大些的项目明显不适用。
2）培植系统
这种隐喻认为开发就像种庄稼，耕地、播种、施肥、浇水、收割，一点一点的做，最后丰收。其核心为“每次做一点”，但缺点为无法对整个过程进行系统的控制。
3）系统生长
这种隐喻认为开发就像牡蛎产生珍珠的过程：增量式（增量的，迭代的，自适应的和演进的）。就像珍珠先有一个沙粒，然后再一点一点长成珍珠。软件开发也是，可以先搭起骨架，然后一点一点附着肌肉和皮肤，一次增加一点代码，最后形成系统。优点在于不做过多的承诺，缺点在于用它来描绘软件开发过程还是不恰当。
4）建造软件
这种隐喻认为软件开发就像建筑一样，需要计划，前期准备和执行。其实软件开发的很多术语都源于建筑，比如：软件架构，脚手架，构建等。同时你还可以把建筑的很多方面引申到软件开发上来。他们具有很多的相似性。
5）智力工具箱
这种隐喻是指人们在多年的开发过程中积累了大量的技术、技巧和诀窍。在开发过程中学的越多，脑中工具箱可用的工具就越多，以后合适的时候就可以拿出来用。
3、前期准备
不同种类的软件项目，需要在“准备工作”和“构建活动”之间做出不同的平衡。每一个项目都是独特的，但是项目可以归入若干种开发风格。表列出了三种最常见的软件项目种类，并且列出了各种项目最适合的典型实践。
三种常见的软件项目种类，及其典型的良好实践
4、关键的“构建”决策
语言的选择、编程约定
关键点：
输入一种语言去编程，而不是使用一种语言编程。在一种语言上编程的程序员将受制于程序语言提供的“构件",这样，如果工具是初级的，那么程序员的思想也会是初级的。而深入一种语言去编程的程序员会先决定他想表达的思想是什么，然后再决定如何使用特定的程序语言提供的工具来表达这些思想。
如果你使用的语言缺乏你所希望的构件，或者倾向于出现其他种类的问题，那深入一种语言编程的程序员应该发明自己的编程约定，命名标准，和程序类库来弥补特定语言自身的缺陷。
二、创建高质量的代码
5、软件构建中的设计
对优秀的设计师，他们共有的一项特质就是对变化的预期能力。好的程序设计所面临的最重要挑战之一就是适应变化。目标应该是把不稳定的区域隔离出来，从而把变化所带来的影响限制在一个子程序、类或者包的内部。下面给出你应该采取的应对各种变动的措施：
A、找出看起来容易变化的项目。如果需求做得很好，那么其中就应该包含一份潜在变化的清单，以及其中每一项变化发生的可能性。在这种情况下，找出潜在的变化就非常容易了。如果需求中没有包括潜在的变化，请业务规则、对硬件的依赖性、输入和输出、被标准的语言特性、困难的设计区域和构建区域、状态变量等方面考虑变化。
B、把容易变化的项目分离出来。把第一步中找出的容易变化的组件单独划分成类，或者和其他容易同时发生变化的组件划分到同一个类中。
C、把看起来容易变化的项目隔离出来。设法设计好类之间的接口，使其对潜在的变化不敏感。设计好类的接口，把变化限制在类的内部，且不会影响类的外部。任何使用了这个将会发生变化的类的其他类都不会察觉到变化的存在。类的接口应该肩负起保护类的隐私的职责。
。
理想的设计特征
寻找现实世界的对象
形成一致的抽象
封装实现细节
在可能的情况下继承
信息隐藏
找出容易改变的区域
保存松散耦合
探寻通用的设计模式
设计策略
自上而下策略和自下而上策略的最关键的区别在于，前者是一种分解策略，后者是一种合成策略；前者从一般性的问题出发，把该问题分解成可控的部分。后者从可控的部分出发，去构造一个通用的方案。这两种方法都有各自的强项和弱项。
记录设计成果
把设计文档插入到代码里：在代码注释中写明关键的设计决策，这种注释通常放在文件或者类的开始位置。如果你同时使用类似于JavaDoc这样的文档提取工具，那么这种方法会确保设计文档对于开发这部分代码的程序员来说是立等可取的，同时也有助于程序员保持代码和设计文档之间的相当不错的同步。
用Wiki来记录设计讨论和决策：把你们的设计讨论写到项目的Wiki里去（Wiki是指一组可以由项目组所有成员用网络浏览器轻松编辑的网页）。尽管文字录入要比交谈麻烦一些，但这样会自动地记录下你们的设计讨论和设计决策。如果使用Wiki，你可以用图片来弥补文字讨论的不足，并链接支持该设计决策的网站、白皮书及其他材料。如果你的开发团队在地理位置上是分布式的，那么这种技术会非常有帮助。
写总结邮件：每次就设计展开讨论过后，请采取这种做法，即指派某人来写出刚才讨论的纲要——特别是那些决定下来的事项——然后发送给整个项目组。在项目的公共电子邮件文件夹里保留一份备份。
使用数码相机：在对设计进行文档化时有一个很常见的障碍，那就是用流行的画图工具画设计图表太麻烦。不过文档化可不仅限于“用漂亮的格式、正规的符号来记录设计”和“不做任何设计文档”这两种选择。把白板上画出的图表照成相片然后嵌入到传统的文档里，这样做可以带来事半功倍的效果，因为它的工作量只是用画图工具画设计图表的1%，而它的收益却能达到保存设计图表的80%。
保留设计挂图：如果你把设计记录在大的挂图上，那么你只需把这些挂图保存在方便的地方即可，或者采用更好的做法，把它们张帖在项目工作区域的墙上，让大家能够很容易地随时查阅和修改。
使用CRC（类、职责、合作者）卡片：另外一种技术含量较低的文档记录方案是使用索引卡片。在每张卡片上，设计者写下类的名称、职责和合作者（与这个类合作的其他类）。一个设计团队便按照这些卡片的内容展开工作，直到他们认为已经创建出一个好的设计方案为止。到那个时候，你只需把这些卡片保留下来，留待日后引用。索引卡片非常便宜，不吓人，易于携带，并且有助于促进团队合作（Beck 1991）。
在适当的细节层创建UML图：一种流行的绘制设计图的方法是由对象管理组织（Object Management Group）定义的统一建模语言（UML）（Fowler 2004）。UML提供了一套丰富的、形式化的表示法，可用于设计实体（entity）及其关系（relationship）。你可以用非正式的UML图来帮助讨论和发现设计思路。从最简单的草图开始，直到你最终选定了一套设计方案，才往其中增加细节。由于UML是标准化的，因此在交流设计观念时大家都能理解它，同时还能加快团队共同讨论各种设计方案的速度。
6、可以工作的类
包含（“有一个……”的关系）
继承（“是一个……”的关系）
研究表明，人们在做其他事情时，能够记住的离散项目的个数是7+-2个。如果一个类中包含有超过7个数据成员时，请考虑要不要把他分解成为几个更小的类。
创建类的合理原因：对现实世界中的对象建模、对抽象对象建模、降低复杂度、隔离复杂度、隐藏实现细节、限制变化所影响的范围、隐藏全局数据、让参数传递更顺畅、创建中心控制点、让代码更易于重用、让程序族做计划、把相关操作放到一起、实现特定重构。
要点：
类的接口应提供一致的抽象。很多问题都是由于违背该原则而引起的。
类的接口应该隐藏一些信息——如某个系统接口、某项设计决策、或者一些实现细节。
包含往往比继承更为可取——除非你要对“是一个/is a”的关系建模。
继承是一种有用的工具，但它却会增加复杂度。
类是管理复杂度的首选工具。