代码整洁之道 读书笔记（二）第12章 迭进

 多数经理想要好带吗，即便他们总是痴缠于进度。他们会奋力卫护进度和需求；那是他们该干的。你则当以同等的热情卫护代码！--Robert C Martin 代码整洁之道 第一章 P5

每次重读的时候都觉得上面那句话好有道理。通常都是，功能写好了，可以运行了。OK，处理下一个问题。一直发懒、发懒、发懒。。。以至于可维护度越来越低。

OK，切入正题。

第十二章的名字叫 迭进，内容非常简短。主要介绍了四条规则，以便轻松写出整洁代码。但是读完后，很想吐槽一下：迭进这词儿读起来太别扭了。

感觉叫做：简洁性重构的四个原则 更符合意译。

四条原则如下：

1、运行所有测试

2、不可重复

3、表达了程序员的意图

4、尽可能减少类和方法的数量

一、运行所有测试  

这条不敢恭维。因为以往的经历中，并没有见识过测试驱动开发。但是仔细想想，可能就是为了保障处理逻辑无漏洞。同时，为了简化测试用例的编写，也会尽量保障函数、类功能的单一性。从而达到符合SRD的原则。

二、按照四条规则中的 2、3、4条规则进行代码重构。

 2、 不可重复 

要有消除重复的意愿。第一次遇到类似功能，可以不提出来，第二次遇到类似功能的代码，就必须考虑提取公共部分，形成通用方法了。以前，纠结于第一次写代码的时候就会考虑要不要把某部分写成公共方法，以便以后使用。考虑的太远了。现在的想法是：构思功能，对极有可能重用的代码才提炼为公共方法。否则一律不予处理。第二次遇到类似处理时，再提取，重构。

3、表达了程序员的意图

  这个表达太官方了。说直白一点就是：变量名、方法名、类名、接口名等需要命名的地方，一定要见名知意！且符合一般规范。逐渐形成自己的命名风格，作为自己编程风格的一部分。这是软实力，算是内功的一部分。需要注意并刻意训练。  起名字的时候，尽量跟权责进行关联。

有太多时候，我们写出能工作的代码，就转移到下一个问题上，没有下足功夫调整代码，让后来者易于阅读。

  ~~用心是最珍贵的资源。P162