Clean Code

第一章 整洁代码

1、整洁代码只做好一件事
2、推崇小块代码
3、没有重复代码（有意义的命名+方法功能不要太多）
4、代码读的轻松，小规模抽象
5、明确才是王道

第二章 有意义的命名

1、命名要名副其实，尽量不要使用List，用Groups或者Accounts（名词复数形式）表示
2、名称长短应与其作用域大小相对应
3、类名和对象名应该是名词短语
4、方法名应该是动词短语
5、可以添加有意义的语境

第三章 函数

1、函数应该做一件事，做好这件事，只做这一件事。
2、每一个函数一个抽象层级。
3、switch 语句天生要做N件事，我们可以创建多态对象，而且隐藏在某个继承关系中。
（if ... else if ... else if ... else等结构需要进行一层抽象，提取出公共接口，然后生成对象数组进行多态调用，将分支结构转化为循环结构）。
4、函数参数最理想是零，当有三个及三个以上参数时，需要考虑是否将其中一些参数封装成类。
5、向函数传入布尔值简直是骇人听闻，函数将不止做一件事，true时这样做，false时那样做。
6、使用异常代替返回错误码，避免更深层次的嵌套结构。
7、抽离Try/catch代码块，Try/catch代码块破坏原来代码结构，将错误处理和正常流程混为一谈，需要另外形成函数。（错误处理就是一件事）
8、别重复自己

第四章 注释

1、尽量用代码而不用注释来阐述
2、注释可以是提供信息的注释，如正则表达式匹配字符
3、注释可以是对意图的解释
4、注释可以用来进行警告
5、//TODO注释放置要做的工作列表

第五章 格式

1、垂直格式，需要向报纸学习
2、垂直方向上的间隔可以很好的隔开概念
3、关系密切应该相互靠近，变量声明应尽可能靠近其使用位置
4、实体变量放置在类的顶部声明
5、相关函数应将其放置在一起，调用者应尽可能放在被调用者的上面；这样函数声明总会再其调用后很快出现
6、概念相关应该放在一起，相关性建立在直接依赖的基础上，如函数间调用或函数使用某个变量

第六章 对象与数据结构

1、使用数据结构代码便于在不改动既有的数据结构的前提下添加新函数，难以添加新的数据结构（必须修改所有函数）；
使用面向对象代码便于在不改动既有函数的前提下添加新类，难以添加函数（必须修改所有类）。
2、对于面向对象较难的事，对于过程式代码却比较容易，反之亦然。
3、The Law of Demeter：

• 模块不应了解它所操作对象的内部情形，**对象隐藏数据，暴露操作。
• Handler类的方法f()只应该调用以下对象的方法：

Handler
由f创建的对象
作为参数传递给f的对象
由Handler的实体变量持有的对象

4、最为精炼的数据结构是只有一个公共变量、没有函数的类。这种数据结构被称为数据传送对象，DTO（Data Transfer Objects）
5、对象暴露行为，隐藏数据。

• 便于添加新对象类型而无需修改既有行为，同时也难以在既有对象中添加新行为。
  数据结构。
  数据结构暴露数据，没有明显的行为。
• 便于向既有数据结构添加新行为（新函数），同时也难以向既有函数添加新数据结构。

第七章 错误处理

1、使用不可控异常
2、依调用者需要定义异常类，需要考虑如何被捕获
3、将第三方API打包是个良好的时间手段
4、特例模式：创建一个类或配置一个对象，用来处理特例，可将异常行为封装到特例对象中
5、别返回null值，方法返回null可以抛出异常或者返回特例对象
6、别传递null值
7、错误处理隔离看待，独立于主要逻辑，就能写出强固而整洁的代码

第八章 边界

1、建议不要将Map（或在边界上的其他接口）在系统中传递，如果使用类似Map的边界接口，就把他保留在类或者近亲类中。
2、学习log4j

第九章 单元测试

1、TDD三定律：

• 定律一：在编写不能通过单元测试前，不可编写生产代码
• 定律二：只可编写刚好无法通过的单元测试，不能编译也算不通过
• 定律三：只可编写刚好足以通过当前失败测试的生产代码

2、F.I.R.S.T.：快速（fast）、独立（independence）、可重复（repeatable）、自足验证（self-validating）、及时（timely）

第十章 类

1、类应该短小，有单一权责原则（Single Responsibility Principle，SRP），类或模块应有且只有一条加以修改的理由。
2、如果一个类的每个变量都被每个方法所使用，则该类具有最大的内聚性。——内聚性高
3、如果函数想要共享某些变量，应该让他们拥有自己的类。故当类丧失内聚性时，就应该拆分类
4、通过降低连接度，就遵循了一条类设计原则——依赖倒置原则（Dependency Inversion Principe）。本质而言，DIP认为类应当依赖于抽象而不是依赖于具体的细节。（减少耦合）

第十一章 系统

1、软件系统应将起始过程与起始过程之后的运行逻辑分离开。
2、main函数创建系统所需的对象，在传递给应用程序，应用程序只管使用。依赖箭头都是从main函数向外走，这表明应用程序对main或者构造过程一无所知。
3、使用抽象工厂模式让应用程序自行控制何时创建对象，但构造细节却隔离于应用程序代码之外。
4、控制反转（Inversion of Control，IoC）将第二权责从对象中拿出来，转移到另一个专注于此的对象中，从而遵循了单一权责原则。
5、延后初始化的好处：

• DI（Dependency Injection）容器在需要对象之前并不构造对象。
• 许多这类容器提供调用工厂或构造代理的机制，而这种机制可为延迟赋值或类似的优化处理所用。

6、通过方面式的手段切分关注面，用测试驱动系统架构。

第十三章 并发编程

1、并发防御原则：

• 单一权责原则（SRP）：分离并发相关代码和其他代码。
• 限制数据作用域：谨记数据封装，严格限制对可能被共享的数据的访问。
• 使用数据复本：从多个线程收集所有复本的结果，并在单个线程中合并这些结果。
• 线程应尽可能地独立：尝试架构数据分解到可被独立线程（可能在不同处理器上）操作的独立子集。

2、几种执行模型

基础定义

• 生产者-消费者模型：生产者与消费者之间队列是一种限定资源。
• 读者-作者模型：需提供合理的吞吐量
• 宴席哲学家