第七章 异常处理
1.try代码就像是事务，catch代码块将程序维持在一种持续状态。在编写可能抛出异常的代码时，最好先写出try-catch-finally 语句。
2.根据需要定义异常类。对错误分类的方式有多种，可以依据来源，是组件还是其他地方，或者依据类型，是设备错误还是网络错误。不过在我们定义异常类的时候，最重要的考虑是如何捕获它们。
3.别返回null值。程序中不断的看到检测null值的代码，一处漏掉检测就可能会失控。返回Null，作者认为这种代码很糟糕。建议抛出异常 或者返回特定对象（默认值）。更早的发现问题。同理，也应该避免传递Null值给其他的方法。
PS:在大多数的编程语言中，没有良好的方法能对付由调用者意外传入的null值。我们发布产品应该有容错的机制，程序不能轻易的就崩掉，有异常应该及时记录下来或给出提示。
第八章 边界
有时候我们在使用第三方程序包或者开源代码的时候，或者依靠公司其他团队的代码，我们都得干净利落的的整合进自己的代码中。这一章就是介绍保持保持软件边界整洁的实践手段和技巧。
1.对第三方进行学习性测试，当第三方程序包发布了新的版本，我们可以允许学习性测试，看看程序包的行为有没有发生改变。
2.使用尚不存在的代码，有时候我们的第三方，还没有开发好API，但又不能影响到我们的开发进度，所以我们先可以定义好自己想要的接口。如果第三方ok了，我们再对接起来。
3.通过接口管理第三方边界，可以使用ADApter模式将我的接口转换为第三方提供的接口。这个是要注意，第三方的代码和自己的代码混合太多，这样不便管理。
第九章 单元测试
敏捷和TDD运动鼓舞了许多程序员编写自动化单元测试，单元测试是确保代码中的每个犄角旮旯都如我们所愿的工作。
TDD三定律
- 除非这能让失败的单元测试通过，否则不允许去编写任何的生产代码。
- 只允许编写刚好能够导致失败的单元测试。 （编译失败也属于一种失败）
- 只允许编写刚好能够导致一个失败的单元测试通过的产品代码。
PS:什么是生产代码，这里有点迷惑。
测试代码和生产代码一样重要，它可不是二等公民，它需要被思考、被设计和北照料。它该像生产代码一样保持整洁。单元测试让你的代码可扩展，可维护，可复用。原因很简单，有了测试，你就不担心对代码的修改，没有单元测试，每次修改可能带来缺陷，一个测试，一个断言。一个测试，对应一个概念。我们不想要超长的测试函数。
测试还应遵守以下5条规则。
1.快速 测试应该能快速运行，太慢了你就不会频繁的运行，就不会尽早的发现问题。
2.独立。测试应该相互独立，某个测试不应该为下个测试设定条件。当测试相互依赖，一个没通过导致一连串的测试失败，使问题诊断变的困难。
3.可重复。测试应该可以在任何环境中重复通过。
4.自足验证 测试应该有布尔值输出，无论通过或失败，不应该是查看日志文件去确认
5.及时。单元测试应该恰好在使其通过的生产代码之前编写。
第十章 类
1.类应该短小
2.单一权责原则(SRP)：类或模块应有且只有一条加以修改的理由。系统应该有许多短小的类而不是巨大的类组成。
PS：每个达到一定规模的系统都会包括大量逻辑和复杂性。管理这种复杂性的首要目标就是加以组织，以便开发者在哪儿能找到东西，反之，拥有巨大、多目的的类的系统，总是让我们在目前并不需要了解的一大堆东西中艰难的跋涉。
3.内聚：如果一个类中的每个变量都被每个方法所使用，则该类具有最大的内聚性。内聚性高，意味着类中的方法和变量相互依赖，相互结合成一个逻辑整体。
4.为了修改而组织。开放闭合原则（OCP）：类应当对扩展开放，对修改封闭。我们可以借助接口和抽象类来隔离这些细节带来的影响。
第十一章：系统
将系统的构造和使用分开：构造和使用是不一样的过程。
PS：修建一栋大楼的时候，起重机和升降机在外面，工人们穿着安全服在忙碌。当大楼建设完成，建筑物变得整洁，覆盖着玻璃幕墙和漂亮的漆色。在其中工作的人，看完完全不同的景象。软件也是如此，将关注的方面分离。
1.工厂，有时候应用程序需要确定何时创建对象，我们可以使用抽象工厂模式。将构造的细节隔离于应用程序之外。
2.依赖注入（DI/IOC）。在依赖管理情景中，对象不应该负责实例化对自身的依赖，反之，它应该将这份权责移交给其他有权利的机制，从而实现控制的反转。
PS 现在的依赖注入组件比较多了，Autofac，Ninject等。
3.扩容：“一开始就做对的系统”纯属神话，反之，我们应该只实现今天的用户的需求。然后重构，明天再扩容系统，实现新用户的需求。这就是迭代和增量敏捷的精髓所在。 就像城市不断的再拆掉，再建设。
4.面向切面编程。AOP中，被称为方面（aspect）的模块构造指明了系统中哪些点的行为会以某种一致的方式被修改，从而支持某种特定的场景。这种说明是用某种简洁的声明(Attribute)或编程机制来实现的。
PS:MVC的Filter是个很好的AOP，可以从权限验证，方法进入前，方法进入后，返回结果前，返回结果后等这几个横切面进行编程。更好的组织代码。第十，十一章讲的设计只是一少部分。更多的可能要去参考专门讲设计模式之类的书。
第十二章 迭进
1.简单设计规则 1：运行所有测试。
紧耦合的代码难以编写测试。同样编写测试越多，就会越遵循DIP之类的原则，使用依赖注入，接口和抽象等工具尽可能减少耦合。如此一来设计就会有长足进步。遵循有关编写测试并持续运行测试的、明确的规则，系统就会更贴近OO低耦合度、高内聚的目标。
2.简单设计规则2 重构：
在重构过程中，可以应用有关优秀软件设计的一切知识，提升内聚性，降低耦合度。换句话说：消除重复，保证表达力，尽可能的减少类和方法的数量。
3.不可重复。重复是良好设计系统的大敌。它代表着额外的工作、额外的风险和额外不必要的复杂度。重复有多种表现。雷同的代码行是一种。另外的比如：
int size();
bool isEmpty();
这两个方法可以分别实现，但可以在isEmpty中使用size消除重复。
bool isEmpty(){
return size()==0;
}
不但是从代码行的角度，也要从功能上消除重复。
第十三章： 并发编程
并发是一种解耦策略，它帮助我们把做什么(目的)和何时（时机）做分解开。在单线程应用中，目的与时机紧密耦合，很多时候只要查看堆栈追踪即可断定应用程序的状态。而解耦目的与时机能明显地改进应用程序的吞吐量和结构。从结构的角度看，应用程序看起来更像是许多台协同工作的计算机,而不是一个大循环。单线程程序许多时间花在等待Web套接字I/O结束上面。
- 并发会在性能和编写额外代码上增加一些开销。
- 正确的并发是复杂的，即使对于简单的问题也是如此。
- 并发缺陷并非总能重现，所以常被看做偶发事件而忽略，而未被当做真的缺陷看待。
- 并发常常需要对设计策略的根本性修改。
