##好书推荐——[Clean Code](https://www.slideshare.net/hebel/clean-code-vortrag032009pdf)
- - - - -
###整理
1. 整洁代码
- 整洁代码力求集中，每个函数、每个类和每个模块都全神贯注于一件事。
- 整洁代码简单直接，从不隐藏设计者的意图。
- 整洁代码应当有单元测试和验收测试。它使用有意义的命名，代码通过其字面表达含义。
- 消除重复代码，提高代码表达力。
- 时时保持代码整洁。
2. 有意义的命名
- 使用体现本意的命名能让人更容易理解和修改代码。
- 较短的命名如果能表达足够的意义，通常比较长的命名好，尽量减少命名上不必要的文字。
- 命名的长度应该与范围大小对应，一个常用的变量或常数，最好给它一个容易被搜索到的名字。
3. 函数
- 规则：
- 每行应该少于150字符，函数应该少于20行。
- 每个函数都要清楚的告诉读者它本身的意图，并带领到下一个函数。
- 一个函数应该只做一件事（高内聚），无副作用。
- 自顶向下阅读代码，如同是在阅读报刊文章。
- 长而具有描述性的函数名称，好过描述性的长注释。
- 少用输出参数。
- 拒绝boolean型标识参数。
- CopyUtil.copyToDB(isWorkDB) --> CopyUtil.copyToWorkDB( ), CopyUtil.copyToLiveDB( )
- 使用异常代替返回错误码，错误处理代码就能从主路径代码中分离出来得到简化。
- 写代码很像是写文章。先想怎么写就怎么写，然后再打磨：分解函数、修改名称、消除重复。
- 编程其实是一门语言设计艺术，大师级程序员把程序系统当做故事来讲。使用准确、清晰、富有表达力的代码来帮助你讲故事。
4. 注释
- 别给糟糕的代码加注释----重写吧。
- 把力气花在写清楚明白的代码上，直接保证无需编写注释。
- 注释只应该描述附近的代码，不要在区域性的注解内放入系统全局的注解。
- 好的注释：
- 法律信息
- 提供信息
- 解释意图
- 警示
- TODO注释
5. 格式
- 代码格式很重要。代码格式关乎沟通，而沟通是专业开发者的头等大事。
- 向报纸格式学习代码编写。
6. 对象和数据结构
- 对象把数据隐藏于抽象之后，只提供操作数据的函数。
- 数据结构暴露其数据，没有提供有意义的函数。
- The Law of Demeter（得墨忒耳定律）：模块不应去了解它所操作的对象内部细节。
7. 错误处理
- 使用异常而非返回错误码。
- try-catch-finally, log出错信息。
- 不要返回null，不要传递null。
- NULL Object模式, 例：Collections.emptyList( );
8. 边界
- 边界上代码需要清晰的分割和定义了期望的测试。
- 学习型测试：不要在产品里实验新的东西，而是另外写测试函数，来了解第三方库。
- 学习型测试不会花费我们太多时间，而且能确定第三方库是否能够按照我们预期去执行。
- 如果没有这种边界测试，来减轻更新时的整合负担，我们只能一直停留在旧版本。
9. 单元测试
- 有了测试，就不会害怕修改代码会造成代码的结果不如预期。
- 测试代码跟产品代码一样重要，一样需要整洁，确保可读性。
- 一个测试代码只测试一个功能。
- TDD定律：
- 在编写不能通过的单元测试前，不可编写生产代码。
- 只可编写刚好无法通过的单元测试，不能编译也算不通过。
- 只可编写刚好足以通过当前失败测试的生产代码。
10. 类
- 自顶向下原则：让程序读起来就像是一篇报纸文章。
- method可以是protected，以便于单元测试。不要过度执着于代码的封装。
- 我们架构的系统，在未来想增加或修改功能时，尽可能不修改到其他函数库。
- SRP：类或模块应有且仅有一个加以修改的原因。类名应准确描述其职责。高内聚。
- 变量名、方法名、类名都是给代码添加注释的一种手段。
- 开放闭合原则OCP、依赖倒置原则DIP。
- 类应该要对扩展有开放性，对修改有封闭性。
- 类应该要依靠于抽象概念，而不是依靠于集体细节。
11. 系统
- 将系统的构造与使用分开
12. 跌进
- 紧耦合的代码难以编写单元测试。
- 单元测试消除了对清理代码会破坏代码的恐惧。
- 写出自己能理解的代码很容易，软件项目的主要成本在于长期维护。
- 代码应当清晰表达其作者的意图；测试代码可以通过实例起到文档作用。
13. 并发编程
14. 逐步改进
- 编程是一种技艺。要编写整洁代码，必须先容忍脏代码，然后清理！
- 写出好文章就是一个逐步改进的过程。
15. JUit
16. 重构SerialDate
17. 味道与启发
