序言：这是一本很多前辈推荐的书，阅读这本书后，我最大的感想就是：特别实在。书中时不时的出现一个句子，戳中你的内心。例如序言中的：

那堆“可以运行”的乱麻程序，就在我们的眼皮底下慢慢腐败。

对于软件而言，百分之八十或更多的工作量集中在我们美其名曰“维护”的事情上：其实就是修修补补。

习艺之要有二：知和行。你应当习得有关原则、模式和实践的知识，穷尽应知之事，并且要对其了如指掌，通过刻苦实践掌握它。

[TOC]

整洁代码

阅读本书有两种原因：第一，你是个程序员；第二，你想成为更好的程序员。很好，我们需要更好的程序员。

要有代码

​ 现在已经有了很多低代码平台，让我们更专注于业务，而不用写代码。这个有趣的话题在一次团队知识分享时提到过。在业务简单的场景中，通过可视化平台，产生程序。确实挺快的，换作写代码，可能项目还没搭建好呢。速度快，说明我们干的事就很少，那么隐藏的细节就会更多。产生通用性很强的程序，真的适合复杂多变的业务场景吗？

​ 另外，在面对复杂业务场景时，我需要将需求给低代码平台讲清楚，讲透彻，这件事可能不太容易。而且，

将需求明确到机器可以执行的细节程度，就是编程要做的事。

我们永远无法抛弃必要的精确性——所以代码永存

糟糕的代码

你是否经历过为了赶进度，写烂代码，并且认为只要实现功能就行。也许你还说过：等后面有时间了，再来重构。

勒布朗法则：稍后等于永远不。

混乱的代价

烂代码越来越多，缺陷密度越来越大。促进人员变更，后来的同事看不懂这写的啥玩意。团队生产力逐渐下降，最终到了不重构就走不下去的地步了。

花时间保持代码整洁不仅关乎效率，还关乎生存。

态度

因为需求变更，进度紧张等等原因，我们“不得不”写烂代码。真的是这样吗？你可能会说这是领导要求的，没办法。那我们就改变领导，让他不要让我们处于这种境地。怎么做？前面说的都是领导了解的，那就跟他说说他不了解的，例如这样做的坏处。我相信领导是有远见的，不会给未来挖坑。你看，这不就解决了吗？所以，问题出在我们身上。

我们是自作自受，我们太不专业了。

程序员应当意识到好代码的重要性，烂代码欠下的账，都是要加倍奉还的。

代码整洁的艺术

我们都想写出优雅的代码，不是吗？

什么是整洁代码

整洁的代码只做好一件事

代码也有破窗效应，提交代码需谨慎！

童子军军规

努力，让世界比你来时干净些......

我们是作者

读代码于写代码的时间比例是10:1，可见我们应该让我们写的代码更易读。

有意义的命名

如果经常做某件事，不妨学学如何做好它！

名副其实

代码都是打磨出来的，一旦发现有更好的名称，就重构它。

如果名称需要注释来补充，那就不算是名副其实。

避免误导

实在有歧义，请加注释。

有意义的区分

有时我们遇到想用的命名被使用了，别急，仔细找出他们的不同，并通过命名来区分。

使用可搜索的名称

增加中间变量名，更清晰地表达

避免使用编码

匈牙利语标记法

将类型作为变量名前缀。

Java是强类型语言，不需要使用类型编码，并且可以通过IDE查看其类型。

接口与实现

不要在接口前加I，实在要区分，可以在实现后加Impl。

避免思维映射

避免使用自己想到的，但不是通用的，或者是只有自己能看懂的命名。

专业程序员善用其能，编写其他人能理解的代码。

类名

应该是名词，不应包含动词。毕竟我们是面向对象编程。

方法名

应当是动词。

重载构造器时，使用描述了参数的静态工厂方法名。

Complex fulcurnmPoint = Complex.FromRealNumber(23.0);

每个概念对应一个词

这算是规约，通过需求，想出关键字，从而找到代码。

使用解决方案领域的名称

太专业的术语，并不适合。

记住，只有程序员才会读你的代码。

添加有意义的语境

例如包名。让别人能看懂，并且避免了冗余。

多个局部变量一起创建，一起使用，或者属于一个抽象层面，就可以抽取。

多个条件分支时，分支可抽取为方法。如果干的是一件事，可以考虑用多态+工厂类。

不要添加没用的语境

只要能表达清楚，越短越好。

最后的话

命名不仅需要良好的描述技巧，还需要规约。所以，良好的命名是需要积累的。

函数

庞大的系统都是聚沙成塔造就的，函数便是其中的“沙“。

短小

函数的第一条规则是要短小。第二条规则还是要短小。

书中给的限制是不超过20行，P3C要求不超过80行。

函数缩进层级不应超过两层，超过时可选择封装。

只做一件事

单一职责原则，使之改变的只有一个原因。

编写函数是为了把较大概念拆分为另一抽象层上的一系列步骤。

判断函数是否只做了一件事，就是看还能再拆不。

每个函数一个抽象层级

确保函数只做一件事，函数中的语句就要在同意抽象层级上。

自顶向下读代码：向下规则

下一步骤在函数尾，这样就一层一层的往里深入，往下执行。

switch语句

写出只做一件事的switch语句难，因为switch语句天生就是做多件事的。

条件分支抽取，或者将分支细节隐藏到子类中，利用工厂模式+多态解决。

使用具有描述性的名称

函数越短小，功能越集中，就越便于起个好名字。

别害怕长名称。长而具有描述性的名称，要比短而令人费解的名称好。

如果发现有更好的名称，请选择重构。

函数参数

避免使用3个以上的参数，超过3个，需要封装。

参数少，有利于单元测试。

单参数函数的普遍形式

不建议通过参数输出信息，应该是使用返回值的形式。

标识参数

标识参数丑陋不堪，向函数传入布尔值简直就是骇人听闻的做法。

相当于大声地宣布本函数不只做一件事。

使用布尔值参数时，违背了单一职责，应该把方法重构为两个方法，取消该参数。

双参数函数

一个参数时，一看就明白了，双参数时，容易忽略掉某个参数。

我们根本不该忽略任何代码，忽略掉的部分就是缺陷藏身之地。

减少参数的方法：1、重构为成员变量；2、封装部分或全部参数，封装部分时，其他的参数通过封装对象的方法传入，例如FieldWriter，通过构造器传入outputStream，然后在write方法传入参数name。

动词与关键字

生动形象描述函数。

可将参数名称编码进函数名。

无副作用

输出参数

给字符串添加后缀时，应将字符串和后缀作为输入参数。而不是只传入字符串，在函数里将后缀写死。

应主动考虑需求变更，面向拓展。

分隔指令和询问

单一职责：

函数要么做什么事，要么回答什么事，但二者不可兼得。

使用异常替代返回错误码

当条件分支复杂，多个分支都要返回错误信息时，可以抛出对应异常，在最外层捕获，返回捕获的异常信息。

抽离try/catch代码块

将异常处理，和正常的业务流程分离。

错误处理就是一件事

加上业务流程就违背单一职责了。

Error.java依赖磁铁

新增错误码时，所有使用到错误码的应用都需要重新构建。

而使用异常代替时，就没有这个烦恼，只构建新增异常的应用即可。

别重复自己

重复可能是软件中的一切邪恶的根源。

如何写出这样的函数

好代码是优化出来的。

打磨代码，分解函数，修改名称，消除重复，拆解类。

小结

大师级程序员把系统当做故事来讲，而不是当程序来写。

编写好的代码，才能向他人清晰地展示你写的故事。