《代码整洁之道》读书笔记

前言：
我们总说书上写的是死的，但人是活的，不要死读书。但在我看来，灵活使用的前提是你的知识储备已经具备了灵活掌握的程度，断然不是遇到别人引用书中的话语，并且这是一个我们没见过，且与我们认知有些违背，我们就说别人是死读书。这句话像极了对别人掌握知识的蔑视，我们都应该清楚的认识到，事物发展都需要过程。这一切的一切得结合时代、结合双方的认知程度等众多因素才能做出结论，不过当下我认为最好的状态，还是只对过程进行阐述，不下结论，《代码整洁之道》书中的观点亦是如此。

一、感悟

说实话这本书读起来没有太多的让我惊喜的时刻， 一方面可能是因为和《重构》有重叠，导致很多东西都比较熟悉，另一方面是书虽然接近400页，但是真正和书名高度相关的内容也就1/3；中间1/3的内容（测试、AOP、并发）在今天看来也有些太大众化，且由于相关技术点的实效性，自己仅做浅尝；最后还有接近1/3的附录代码，这部分直接白给。最后的结果就是，这本书读起来没有拿在手里感觉的那么厚。

同样的，对书中一些比较有感觉的点进行记录：

部分感悟和《重构：改善既有代码的设计》这本书有些重叠的，无妨，多重复几遍，有些东西就能体会的更加深刻。

1、命名单词的选择上尽可能的基于一个大的底座，类名：名词或名词短语；方法名：动词或动词短语；
2、在一些常量的魔法值的处理上，要使用具有业务含义的命名，并且命名具有辨识度，这样有助于未来的定位相关魔法值；
3、方法的业务逻辑需要保持在同一个抽象层级上，并且最终方法构建的形态是一课平衡树，拒绝业务含义上的头重脚轻；
4、方法不要出现副作用，做了什么事情，回答了什么事情要能够独立区分
5、注释应该有其确定的作用，而不是为了解释而强行添加，过多的注视只会影响观感
6、单纯的DTO数据对象，不要含有业务逻辑方法
7、遵从迪米特法则，方法不应该调用任何方法返回的对象的方法，除非这个方法返回的对象是一个数据结构，而非对象结构
8、抛出的错误应该要能清晰的定位错误的来源和位置
9、方法尽量不要返回null和传入null
10、不要依赖直觉去判定代码的正确性，应该探索边界，并且编写对应的测试
11、不要让父类依赖子类
12、如果想让多个函数呈现出一定的顺序，可以在方法的如参上进行限定，继而保证方法的顺序
13、函数的名称应该代表其具备的行为
14、配置相关的参数，应该在较高的抽象层级上进行获取，然后以参数的形式进行传递

二、脑图