第四章 注释
第五章 格式
第六章 对象和数据结构
得墨忒耳定律 (最少知识原则)
1.每个单元对于其他的单元只能拥有有限的知识：只是与当前单元紧密联系的单元；
2.每个单元只能和它的朋友交谈：不能和陌生单元交谈；
3.只和自己直接的朋友交谈。
火车失事代码
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
混杂
一半是对象，一半是数据结构，这是一种糟糕的设计。它增加了添加新函数的难度，也增加了添加新数据结构的难度。
隐藏结构
既然取得路径的目的是为了创建文件，那么不妨让 ctxt 对象来做这件事：
BufferedOutputStream bos = ctxt.createScratchFileStream(classFileName);
第七章 错误处理
1、别返回null值。程序中不断的看到检测null值的代码，一处漏掉检测就可能会失控。返回Null，作者认为这种代码很糟糕。建议抛出异常 或者返回特定对象（默认值）。更早的发现问题。同理，也应该避免传递Null值给其他的方法。
2、在大多数的编程语言中，没有良好的方法能对付由调用者意外传入的null值。我们发布产品应该有容错的机制，程序不能轻易的就崩掉，有异常应该及时记录下来或给出提示。
第八章 边界
1、通过接口管理第三方边界，可以使用ADApter模式将我的接口转换为第三方提供的接口。这个是要注意，第三方的代码和自己的代码混合太多，这样不便管理。
第九张 单元测试
敏捷和TDD运动鼓舞了许多程序员编写自动化单元测试，单元测试是确保代码中的每个犄角旮旯都如我们所愿的工作。
TDD三定律
- 除非这能让失败的单元测试通过，否则不允许去编写任何的生产代码。
- 只允许编写刚好能够导致失败的单元测试。 （编译失败也属于一种失败）
- 只允许编写刚好能够导致一个失败的单元测试通过的产品代码。
整洁的测试 具有 可读性
构造-操作-检验（BUILD-OPERATE-CHECK）测试代码三个步骤
每一个测试一个概念
F.I.R.S.T 整洁的测试遵循以下5条规则：
1.快速（Fast） 测试应该能快速运行，频繁运行测试，就能今早发现问题
2.独立（Independent）测试应该相互独立。某个测试不应为下一个测试设定条件，可以单独运行每个测试，及以任务顺序运行测试。
3.可重复（Repeatable）测试应该可在任务环境中重复通过。
4.自足验证（Self-Validating）测试应该有布尔值输出。不应该手工对比量不同文件来确认测试是否通过。
5.及时（Timely）测试应该及时编写。单元测试应该恰好在使其通过的生产代码之前编写，如果在编写生产代码之后编写测试，你会发现生产代码难以测试。
