窃以为这本书第一章算是整洁之道，后面算是整洁之术吧。
一、 代码整洁之道
代码永存，没有什么先进的代码工具能代替程序员。模糊的需求和精确的代码之间有个必须程序员才能弥补的鸿沟。
勒布朗法则：later equals never. 法则好简单，为什么做起来那么难呢？？有的 洁癖真的很吸引人。
花时间保持代码整洁不仅关系效率而且关系生存。破窗理论，破烂的代码是毁灭的第一步。
当老系统繁重的无法快速满足新变化时，重启新团队重新设计老系统，并与老系统并行运行的例子还是有一定的体会的，此事正好发生在我待过的项目。
写了不整洁的代码而因此承受惨重代价，这是程序员 自作自受，跟繁琐的需求，无止的变化，难以接受的进度，sx的经理都有关系，但还是要说，自作自受。
写混乱的代码就是最快的方式？ 不是，那是因为你根本写不出漂亮的代码。漂亮的代码才是最快的。你有 洁癖吗？艺术家的艺术。
整洁的代码只做好一件事。尽可能的简单（如命令查询分离原则），尽可能的少依赖。
简单的代码，依其重要顺序：
1. 能通过所有测试
2. 没有重复代码
3. 体现系统中的全部设计理念
4. 包括尽量少的实体，比如类，方法等。
消除重复和提高表达力（命名）能在代码整洁方面获益良多。
不要重复代码，只做一件事，表达力，小规模抽象。概括了整洁代码的全部内容。
写新代码时我们一直在读旧代码。读写话费时间比例超过10：1。编写代码的难度，取决于读周边代码的难度。要想写的容易，先让代码易读吧。
美国童子军军规：让营地比你来时更干净。代码的每次check out, check in也是如此。
二、 代码整洁之术
2.1命名
1.名副其实，见名知意。
1） 名字不要怕长，表达清楚更关键。
2） 魔鬼数字用有意义的常量
3） If里的条件能用一个有明确含义的功能方法表达更好。
到处需要命名
如：原始代码，
重构后代码1：
再次重构后2：
2.做有意义的区分
比如有两个类，ProductInfo, ProductData，名称虽然不同，但意义却无区别，就像a, an, the一样。这种情况在项目中也时常发生，至少我经历过。。。
3.使用读得出来的名称
使用正确的 准确的英文表达。花些时间在命名上是非常值得的。不然，痛苦在后面...
单字母名称(如i,j)只应出现在短方法的本地变量。名称长度应与其作用域大小想对应。
若变量或常量多次出现在代码中，应赋予其便于搜索的名称。比如，
原始代码：
重构后后:
4.类名
类名和对象名都应该是 名词或名词短语，如Customer, Account,AddressParser。类名不应该是动词。
5.方法名
方法名应该是 动词或动词短语，如postPayment, save等。
6.每个概念对应同一个词，一致的风格
每个类中采用一致的命名风格，如get***，set***，一词一意，以免概念模糊。可以采用通用的专业性的计算机术语，或问题领域的名称
7.添加有意义的语境
比如添加前缀，lastName, firstName在表示的是地址的时候就可以用addrLastName,addrFirstName.但也不要添加无意义的前缀。
命名一定要精确。
2.2 函数
1.函数的第一规则是短小，第二规则是还要更短小。
If,else,while等代码块中的代码应该只有一行，大抵应该是一个函数调用，一个有较具说明性的名称的函数调用。当然有些极端，理念就是不做多余的事，做同一个抽象层次的事。
2.只做一件事，做好一件事
做的事跟函数名称对应。一个函数做的事情越少，功能越集中，越好命名。
3.每个函数一个抽象层级
函数中的每个语句，包括函数调用等应该是同一个抽象层次的。
4.函数的参数
最理想的参数个数是零，其次是一，再次是二，应该避免三个。有些公司规范是不要超过5个。当参数个数要超过2个或3个时，就要看这些参数是否需要封装成类了。
尽量使用返回值，不要使用输出参数。
5.标识参数（boolean参数）
6.使用异常代替错误返回码
我们要command-query分离，但有时候command会需要返回操作的结果，这时候可以用异常表示错误，否则表示正确，不需要再返回结果状态。
7.分隔指令和查询（command-query分离）
8.抽离try/catch块
Try/catch块搞乱了代码结构，可以把处理异常的逻辑抽离成一个函数，错误处理就是一件独立的事。
9.do not repeat yourself
重复可能是软件中一切邪恶的根源。
整洁的代码并不是一开始就能写出来，就像文章的初稿一样可能混乱不堪，但经过 反复重构慢慢就形成了整洁的代码。这个重构不能隔太久，重构在平时。同时保证测试通过。重构和测试总是分不开的。