第一章 《整洁代码》
1. 什么是整洁代码？
* 代码逻辑直截了当，利于纠错
* 尽量减少依赖关系，便于维护
* 依据某种分层战略，处理异常
* 性能调节至最优化，防止混乱
整洁的代码只做好一件事情！
2. 简单代码特点：
* 能通过所有代码
* 没有重复代码
* 体现系统全部设计理念
* 包括尽量少的实体，如类，方法，函数等
（无重复代码、只做一件事情、表达力、小规模抽象等）
第二章 《有意义的命名》
命名规则：
1.名副其实
* 命名应该有足够的表达力，告诉你为什么会存在，做什么事情，该怎么用
2.避免误导
* 避免使用与本意相悖的命名
* 前后命名要一致，避免出现误导
3.做有意义的区分
* 要区分名称，就要以读者能鉴别不同之处的方式来区分
4.使用读得出来的名字
5.使用可搜索的名称
* 长名称胜于短名称
* 名称长短应与其作用域大小相对应
6.避免使用编码
* 把类型或者作用域编进名称里面，徒然增加了编码的负担
* 避免使用成员前缀
* 接口和实现尽量在实现类中加入Imp，而不是在接口前加入I
7.避免思维映射
* 不应该让读者在脑中把你的名称翻译为他们熟知的名称。明确即王道。
8.类名
* 类名和对象名应该是名词或名词短语，如Customer，Account，避免使用Manager，Data这样熟知的类名
9.方法名
* 方法名应该是动词或者动词短语
10.每个概念对应一个词
11.别用双关语
* 不同功能不使用同一个名称
12.使用解决方案领域的名称
13.使用源自所涉问题领域的名称
14.添加有意义的语境
15.不要添加没用的语境
取好名字最难的地方在于需要良好的描述技巧和共有文化背景。
第三章 《函数》
1.短小
* 函数代码应短小，代码行数应尽量小
* 函数的代码块和缩进不该多于一层或者两层、这样更利于阅读
2.只做一件事情
* 函数应该做一件事情，做好这件事情。只做这一件事情
3.每个函数一个抽象层级
* 要让代码拥有自顶而下的阅读顺序
4.switch语句
* 写出短小的switch语句很难，使用多态来实现
5.使用描述性的名称
* 别害怕长名称
* 别害怕花时间取名字
* 命名方式要一致
6.函数参数
* 最理想的参数数量是0，尽量避免3个以上的参数，这样还有利于测试
* 输出参数比输入参数更难以理解
* 尽量不要标识参数
* 当输入参数超过3个，就需要考虑封装成类对象
* 函数名动作后的名词尽量具体
7.无副作用
8.分隔指令与询问
9.使用异常替代返回错误码
* 最好将try/catch语句从代码块中抽离出来
* 错误处理就是一件事
* Error类是一块依赖磁铁，使用异常替代错误码，新异常就可以从异常类派生出来
10.别重复自己
11.结构化编程
* 禁止出现goto语句，goto只在大函数中才有道理，应避免使用
12.如何写出这样的函数
* 重构
第四章 《注释》
如果编程语言足够有表达力，根本不需要注释
1.注释不能美化糟糕的代码
2.用代码来阐述
3.好注释
* 法律信息，如版权信息
* 提供信息的注释，但如果程序命名或者设计得当也可不需要
* 对意图解释的注释
* 阐释
* 警示
* TODO注释
* 放大
* 公共API的javadoc
4.坏注释
* 喃喃自语
* 多余的注释
* 误导性注释
* 循规式注释
* 日志式注释
* 废话式注释
* 可怕的废话
* 能用函数或变量时就别用注释
* 位置标记
* 括号后的注释
* 归属与署名，源代码控制系统是这类信息最好的归属地
* 注释掉的代码
* HTML注释
* 非本地信息
* 信息过多
* 不明显的联系
* 函数头
* 非公共代码中的javadoc
* 范例
第五章 《格式》
团队应该一致统一采用一套简单的格式规则
1.格式的目的
* 代码格式关乎沟通，而沟通是专业开发者的头等大事
2.垂直格式
* 像报纸学习，从上往下，有头条，第一段是故事的大纲，接着读下去，细节逐渐增加
* 概念间垂直方向向上的区隔，每行展现一个表达式或者句子，思路用空白行隔开
* 垂直方向上的靠近，靠近的代码暗示了之间的紧密关系
* 垂直距离，变量声明应尽可能靠近其使用位置，实体变量应该在类的顶部声明，相关函数应放置在一起，并调用者应该尽可能的放在被调用者上面，概念相关的代码应该放在一起
* 垂直顺序，被调用的函数应该放在执行函数下面
3.横向格式
* 使用空格字符将相关性较弱的事物隔开
* 水平不一定要完全对齐
* 缩进
* 注意空范围的缩进
4.团队规则
* 使用统一的规则
第六章 《对象和数据结构》
1.数据抽象
* 暴露抽象接口，以便用户无需了解数据的实现就能操作数据本体
2.数据，对象的反对称性
* 对象与数据结构之间的二分原理：过程式代码便于在不改动既有数据结构的前提下添加新的函数，二面向对象代码便于在不改动既有函数的前提下添加新类
3.得墨忒耳律
* 模块不应了解它所操作对象的内部情形
* 方法不应调用任何函数返回的对象方法，不要使用链式编写代码（火车失事）
4.数据传送对象
* 最为精炼的数据结构，是一个只有公共变量、没有函数的类。这种数据结构有时被称为数据传送对象，或OTO。
第七章 《错误处理》
错误处理很重要，但如果它搞乱了代码逻辑，那就是错误的做法。
1.使用异常而非返回码
2.先写Try-Catch-Finally语句
3.使用不可控异常
4.给出异常发生的环境说明
5.依调用者需要定义异常类
6.定义常规流程
7.别返回null值
8.别传递null值
第八章 《边界》
1.使用第三方代码
2.浏览和学习边界
* 不要在生产代码中试验新东西，而是编写测试来遍览和理解第三方代码（学习性测试）
3.学习log4j
4.学习性测试的好处不仅仅是免费
* 编写测试则是获得这些知识的容易二不会影响其他工作的途径
5.使用尚不存在的代码
6.整洁的边界
第九章 《单元测试》
1.TDD三定律
* 在编写不能通过的单元测试前，不可编写生产代码
* 只可编写刚好无法通过的单元测试，不能编译也算不通过
* 只可编写刚好足以通过当前失败测试的生产代码
2.保持测试整洁
* 测试代码和生产代码一样重要
3.整洁的测试
* 可读性：明确，简洁，有足够的表达力
4.每个测试一个断言
5.F.I.R.S.T
* 快速Fast：测试应该够快
* 独立Independent：测试应该相互独立
* 可重复Repeatable：测试应当在任何花姐重复通过
* 自我验证Self-Validating：测试应该有布尔值输出
* 及时Timely：测试应及时编写
第十章 《类》
1.类的组织
* 类应该具有封装性
2.类应该短小
* 类或者模块应有且只有一条加以修改的理由
* 系统应该由许多短小的类而不是少量巨大的类组成
* 类应该只有少量实体变量
* 保持内聚性就会得到许多短小的类
3.为了修改而组织
* 类应该对扩展开放，对修改封闭
第十一章 《系统》
1.如何建造一个城市（抽象层级——系统层级）
2.将系统的构造与使用分开
* 分解main
* 工厂
* 依赖注入
3.扩容
4.JAVA代理
5.纯JAVA AOP框架
6.AspectJ的方面
7.测试驱动系统架构
* 没必要先做大设计
8.优化策略
* 延迟策略至最后一刻也是好手段
9.明智使用添加了可论证价值的标准
10.系统需要领域特定语言
第十二章 《迭代》
1.通过迭进设计达到整洁目的
* 运行所有测试
* 不可重复
* 表达了程序员的意图
* 尽可能减少类和方法的数量
