第二部分：创建高质量的代码
第五章：软件构建中的设计
“在大型项目中，设计可能会详细到让编码工作近乎机械化”
“在小型项目中，设计可能就是指用伪代码写个类的接口，或者询问旁边的程序员那个模式好，画几个类的关系图”
——基本没有经历过大型项目，小型项目描述的过程跟我接触的非常的相似，最多多个设计评审。
“当没人知道对一处代码的改动会对其他代码带来什么影响的时候，项目也就停止进展了”
——得多复杂，多糟糕的项目才会到这个地步啊，没有体会过。
因为项目主要是网络的，没有什么雇员、雇主之类很容易抽象的对象，所以制作的类基本都是c子程序和数据的集合体。不知道是不是不对，不过也没感觉出来不对啊。
“信息隐藏在不断增长、大量变化的环境里尤其有用”
刚开始的代码里面把所有的私有变量都加了get、set，但是慢慢就觉得麻烦，全部都公开了，感觉项目一个人维护，全部私有变量都封装，有时候没感觉出来什么意义，如果个别需要特别处理的变量才封装成方法。
不知道得大到什么程度、或者变动到什么程序，才有明显的意义。或者说，我没有感觉出太大的好处。
“不要使用布尔变量做状态变量，请使用枚举”
——这个比较有道理，因为如果从2种变成为3种类型，修改是个累人的活。
P117 写总结邮件这点不错，每次讨论后，经常有遗忘，或者有人记错了，导致争论和疑问。
第六章：可以工作的类
“不懂得ADT（抽象数据类型）的程序员只是把稍有关系的子程序和数据堆在一起，叫做类。”
——感觉自己就是这样，不过看完了这章，感觉就是教你把私有成员隐藏起来，隐藏实现细节，除了接口全部黑盒。
继承与包含，我用的包含最多，继承最少。
一直讨厌使用继承，最大的原因是用source insight看代码不方面，老是跳到基类的方法里面去了。不知道什么阅读工具会比较好。
“当你想让基类控制接口，用继承。当你想染自己控制接口，用包含”
用继承主要是放在list里面方便，不过我平时都是用一个类，然后包括一个void*，来访那些包含的类，再用一个type变量标记是哪种类。
P155
“避免创建万能类”——有时候视图控制数据分离，难道不是这种结构作为过渡吗？
“消除无关紧要类”——类比结构体放数据方便很多，为什么不能出现专门放数据但是没有行为的类？
C++中，只有virtural的方法才能被覆盖，java默认方法都能被覆盖。
第七章：高质量的子程序
子程序的参数不要超过7个，可以做成结构体，这样增加一个参数的时候会比较方便。
不要出现神秘值，用常量定义或者用枚举来替代100，4.0，3.14之类的常量。
子程序要尽量单一而明确的任务。
避免把输入值当做工作变量。
子程序可以避免代码重复，更易懂，提高可移植性，未来去优化也比较方便。
第八章：防御式编程
“主要思想：传入错误的参数也不怕”
断言是不错的方法，但是linux里面用断言感觉不是很好，因为屏幕打印有什么用处，还不如打印到日志里面去，狠点的话，打印日志后退出程序好了。
处理错误有多种情况，不错网络情况估计就是报警和重试了吧。
在正确性和健壮性之间选择。
“只有真正的例外才抛出异常，异常应该和断言一样，是永远不应该发生的事情”
——这个好像跟com不符合哦，com主要是抛出异常的，尤其是解码的com，抛出的异常种类那叫一个多。
——这里的理由是“异常弱化的了封装性”
P203页批评程序员用异常返回错误是为用而用
——记得以前我上学的时候，一个同学还说他师兄是真正的面向对象，所有返回错误值的地方都用异常处理，当时我们崇拜了一阵子。不过这里也未必全对，毕竟是一本书。
“删除一个对象之前把它填满垃圾数据”
——够狠，也是个好主意，这样不会出现有时候出错有时候正常的情况了，如果以后再试图使用肯定崩溃。
第九章：伪代码编程
1、使用自然语言来精确描述特定的操作。
2、避免使用目标编程语言中的语法元素。（这样会受制于程序语法上的约束）
3、先超出语言来描述解决问题的意图。
4、再以足够低的层次上编写伪代码，以便可以近乎自动的从它生产代码。
5、写好代码后，可以把伪代码当做注释存在。
架构应该提前指明多少资源可用，好确定性能还是可读性优先。
“写一个子程序前先考虑怎么测试它”——感觉很困惑，也没有举出例子，不就是检查输入输出吗？还能考虑什么？