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

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u010066934/article/details/77123201

背景

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

内容

整本书洋洋洒洒讲了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的代码处理,影响原有的代码逻辑,不如在被调用的方法中做一次处理。
    ……

这里写图片描述

小结

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

阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页