读-Rober C.Martin-代码整洁之道

最近的做的项目老是维护以前的代码，感觉有些写的不合理，所以一直看书学习。这本书看完感慨万分，不愧是搞方法论，随便一个主题，都能写好几页纸，nb。有些感觉对自己有益的，记录下。

命名

1. 名副其实

   • 最好不需要注释来解释具体含义；

2. 避免误导

   • 如看到XXXList，一般性反应就是这事一个list类型，你就不能在不需要的地方使用这种方式；

3. 有意义的区分

   • 一个变量当然可以取个a1，a2这样，但是这样不具有可读性，表达不了代表的含义；

4. 使用读得出来的名称

   • 刚看到这个时，还疑惑，后来想想看代码时，还真实习惯性的读出来；

5. 使用可搜索的名称

   • 其实就是使用大家习惯性使用名称，这样方便搜索；

6. 避免使用编码

7. 避免思维映射

   • 一般看到i,j这些的，都习惯看成是循环变量，如果用其他的，看到的时候，可能觉得变扭；
   • 使用DSL语言；

8. 别用双关语

   • 插入数据时，有人用insert，有人add，不是那个不好，要团队统一使用一个；

9. 有意义的语境

   • 一个Person类中有address，age，name很正常，冒出来个system，state，status，谁都不知道什么鬼；

总结：简单明了

函数

1. 短小

2. 只做一件事

3. 函数中每个调用都在同一个抽象层级

   • 方法A中调用业务处理b、c、d方法，bcd在同一个抽象层级，不要突然来个数据库更新；

4. 函数命名，使用描述性的名称

5. 函数参数

   • 一元、二元、三元函数，能一个解决的就不用2个；
   • 标识参数，方法中出现个true、false的标识，可能代码中就会出现分支判断，分解成2个方法开放出去，不要让调用者判断；

6. 使用异常替代返回错误码

   • 抽离try/catch代码块；
   • 错误处理就是一件事；

7. 不重复；

总结：拆

注释

1. 注释不能美化糟糕的代码

2. 用代码来阐述

3. 好注释

   • 法律信息；
   • 提供信息的注释；
   • 对意图的注释；
   • 阐释；
   • 警示；
   • todo注释；
   • 放大某些不合理处理的重要性；
   • 公共API的javadoc；

4. 坏注释

总结：注释无所谓好坏多余，如果代码能自阐释，除非必要，不要加

格式

主要是代码风格的问题，团队有一个统一的风格很重要。

1. 垂直格式

2. 横向格式

总结：团队代码风格的统一，清爽

错误处理

1. 使用异常而非返回码

2. 先写try-catch-finally语句

3. 使用不可控异常

4. 给出异常发生的上下文说明

5. 依照调用者需要定义异常类

   • 不同视角；

6. 别返回null值、别传递null值

   • 这个下次要注意，之前接口调用会用null来判断是否有值；

总结：分离正常业务逻辑和异常处理，如果有个全链路监控系统就好了。

启发

1. 注释

   • 不恰当的信息；
   • 废弃的注释；
   • 冗余注释；
   • 糟糕的注释；
   • 注释掉的代码；

2. 函数

   • 过多的参数；
   • 输出参数；
   • 标识参数；
   • 死函数；

3. 一般性问题

   • 一个源文件存在多种语言；
   • 明显的行为未被实现；
   • 不正确的边界行为；
   • 忽视安全；
   • 重复；
   • 在错误的抽象层级上编码；
   • 基类依赖派生类；
   • 信息过多；
   • 死代码；
   • 垂直分隔；
   • 前后不一致：主要指代码风格和命名规范；
   • 混淆视听：
   • 函数名称应该表达其行为；
   • 封装条件：条件判断复杂时单独封装条件判断；
   • 避免否定性条件；
   • 函数只做一件事；
   • 封装边界条件：边界条件的处理集中到一处；
   • 在较高层级放置可配置数据；
   • 避免传递浏览：避免模块调用getA().getB().XXX（）；

4. java

   • 使用通配符避免过长的导入清单：如果导入过多，就是用下；
   • 不要继承常量；
   • 常量vs枚举；

5. 名称

   • 采用描述性名称；
   • 名称与抽象层级相符：这个以前没注意，下次小心；
   • 尽可能使用标准命名法：团队统一更重要；
   • 无歧义的名称；
   • 为较大作用范围选用较长名称；

总结

1. Don’t repeat yourself：不要重复；

2. The principle of least surprise：最小惊异原则；

3. Keep it simple and stupid；

4. 团队一定要有统一的codeStyle和formatcheck；

5. 之前异常处理一直没太注意，下次要注意跟正常业务逻辑分离；

6. 书里面还写了一些单元测试和并发的内容，并发的东西之前看juc看吐了，就过了下，单元测试后面还要单独学习下；

7. 书中的知识点都比较细，还需要工作中注意一些细节处理，规范代码;

8. 下次再看下重构那本书。