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

背景

很早之前就接触过这本书，但当时比较热衷于看架构和设计模式之类的书籍，就把这本《代码整洁之道》排到了后面去看。也是因为从架构中能读懂很多思想和道理来，后又经人推荐，再次拿起这本书来仔细品味。

内容

整本书洋洋洒洒讲了17章内容，但总结起来，并没有那么复杂。

我们还是从接触事物最初的方式来思考，即Why-What-How。如下图所示：

1、Why

-Why？
-为什么要读这本书?
-为什么我们需要编写整洁代码？

最初可能由于某些原因（如：开发周期短、人员水平有限、懒惰心理、管理漏洞等等），造成一部分糟糕或冗余等代码。

只要这种状况不被打破，根据破窗原理，这个糟糕代码就会逐渐越扩越大。

由于糟糕代码很难维护和扩展，整个团队等开发效率都有可能被拖累。逼不得已时只能选择走上漫长的重构之路，若是上述问题得不到重视，那将是又一轮的恶性循环……

Tips:参见思维导图中的第一分支。

2、What

那了解了糟糕代码的沉重代价以后，我们就迫切的想知道，整洁代码应该是什么样子的？

关于“整洁代码“的看法，各个专家们看法不一，这个概念当然也不会死板到一种阐述方式。

总的来看，可以归结于这几个词：优雅、高效、精炼。

Tips:参见思维导图中的第二分支。

3、How

至此，就要去聊方法论的东西了。到底怎样做才能写出整洁的代码呢？

这里，小编将书中的内容归纳为三大部分。其一，是指导原则。任何的行为和要求都要遵循一定的原则，理解原则可以帮助我们做出更好的实践。其二，是具体的实现方法。其三，是在二的基础上扩展的进阶内容。

3.1、原则

• SRP
  单一职责原则

好处就不用多说了，也是设计模式的六大原则之一。要想重用性高，就需要细分，细分就需要有标准和依据，按照职责划分更适合业务逻辑的实现。

具体编程中适用于类、函数、接口、分层、模块等多种场景下。

• OCP
  开放封闭原则

总的来说就是，对修改关闭，对添加开放。前提是做好抽象和单一职责。

• DIP
  依赖倒转原则

模块应该依赖于抽象，抽象不应该依赖于具体实现。

3.2、规范（要求）

基于3.1的原则，3.2提出了具体的要求，来帮助我们编写整洁的代码。

这块的内容有很多，也很细节，全部列举出来也没有太大的意义，这里说几条小编感触比较深的几点，分享给大家：

• 1） 命名要规范
  取有意义的名字，切忌使用i、j、a等；考虑名称等可读性和可理解性，不要使用缩写和生僻单词；区分动名词，方法命名宜使用动词、DTO对象宜使用名词等。

• 2）注释要写好
  要起到对代码的补充阐释的作用，杜绝过多冗余注释。

• 3）格式要重视
  格式是整洁的直接影响因素，不要小看每一个换行和空格哦。

• 4）功能要精炼
  与单一职责原则相契合，函数要短小精悍，过长的函数／方法不仅可读性差、容易出错，更影响复用性。

• 5）参数要抽象
  函数／方法是供调用方调用的，参数个数不宜超过三个，如果超过三个，那么你该考虑抽象了。
• 6) 不要返回null
  返回null值，增加了调用方的判断null的代码处理，影响原有的代码逻辑，不如在被调用的方法中做一次处理。
  ……

小结

凡事不怕难，就怕用心，就怕思考。我们的目标不是码农，但做高质量的码农也不是容易的。细心总结，你会发现很多原理都是相通的，只有深刻的理解了，才能真正的做好。