本文最后更新于 388 天前，其中的信息可能已经有所发展或是发生改变。
序言：这是一本很多前辈推荐的书，阅读这本书后，我最大的感想就是：特别实在。书中时不时的出现一个句子，戳中你的内心。例如序言中的：
那堆“可以运行”的乱麻程序，就在我们的眼皮底下慢慢腐败。 对于软件而言，百分之八十或更多的工作量集中在我们美其名曰“维护”的事情上：其实就是修修补补。 习艺之要有二：知和行。你应当习得有关原则、模式和实践的知识，穷尽应知之事，并且要对其了如指掌，通过刻苦实践掌握它。
[TOC]
整洁代码
阅读本书有两种原因：第一，你是个程序员；第二，你想成为更好的程序员。很好，我们需要更好的程序员。
要有代码
现在已经有了很多低代码平台，让我们更专注于业务，而不用写代码。这个有趣的话题在一次团队知识分享时提到过。在业务简单的场景中，通过可视化平台，产生程序。确实挺快的，换作写代码，可能项目还没搭建好呢。速度快，说明我们干的事就很少，那么隐藏的细节就会更多。产生通用性很强的程序，真的适合复杂多变的业务场景吗？
另外，在面对复杂业务场景时，我需要将需求给低代码平台讲清楚，讲透彻，这件事可能不太容易。而且，
将需求明确到机器可以执行的细节程度，就是编程要做的事。 我们永远无法抛弃必要的精确性——所以代码永存
糟糕的代码
你是否经历过为了赶进度，写烂代码，并且认为只要实现功能就行。也许你还说过：等后面有时间了，再来重构。
勒布朗法则：稍后等于永远不。
混乱的代价
烂代码越来越多，缺陷密度越来越大。促进人员变更，后来的同事看不懂这写的啥玩意。团队生产力逐渐下降，最终到了不重构就走不下去的地步了。
花时间保持代码整洁不仅关乎效率，还关乎生存。
态度
因为需求变更，进度紧张等等原因，我们“不得不”写烂代码。真的是这样吗？你可能会说这是领导要求的，没办法。那我们就改变领导，让他不要让我们处于这种境地。怎么做？前面说的都是领导了解的，那就跟他说说他不了解的，例如这样做的坏处。我相信领导是有远见的，不会给未来挖坑。你看，这不就解决了吗？所以，问题出在我们身上。
我们是自作自受，我们太不专业了。
程序员应当意识到好代码的重要性，烂代码欠下的账，都是要加倍奉还的。
代码整洁的艺术
我们都想写出优雅的代码，不是吗？
什么是整洁代码
整洁的代码只做好一件事
代码也有破窗效应，提交代码需谨慎！
童子军军规
努力，让世界比你来时干净些......
我们是作者
读代码于写代码的时间比例是10:1，可见我们应该让我们写的代码更易读。
有意义的命名
如果经常做某件事，不妨学学如何做好它！
名副其实
代码都是打磨出来的，一旦发现有更好的名称，就重构它。
如果名称需要注释来补充，那就不算是名副其实。
避免误导
实在有歧义，请加注释。
有意义的区分
有时我们遇到想用的命名被使用了，别急，仔细找出他们的不同，并通过命名来区分。
使用可搜索的名称
增加中间变量名，更清晰地表达
避免使用编码
匈牙利语标记法
将类型作为变量名前缀。
Java是强类型语言，不需要使用类型编码，并且可以通过IDE查看其类型。
接口与实现
不要在接口前加I，实在要区分，可以在实现后加Impl。
避免思维映射
避免使用自己想到的，但不是通用的，或者是只有自己能看懂的命名。
专业程序员善用其能，编写其他人能理解的代码。
类名
应该是名词，不应包含动词。毕竟我们是面向对象编程。
方法名
应当是动词。
重载构造器时，使用描述了参数的静态工厂方法名。
代码语言：javascript复制Complex fulcurnmPoint = Complex.FromRealNumber(23.0);每个概念对应一个词
这算是规约，通过需求，想出关键字，从而找到代码。
使用解决方案领域的名称
太专业的术语，并不适合。
记住，只有程序员才会读你的代码。
添加有意义的语境
例如包名。让别人能看懂，并且避免了冗余。
多个局部变量一起创建，一起使用，或者属于一个抽象层面，就可以抽取。
多个条件分支时，分支可抽取为方法。如果干的是一件事，可以考虑用多态 工厂类。
不要添加没用的语境
只要能表达清楚，越短越好。
最后的话
命名不仅需要良好的描述技巧，还需要规约。所以，良好的命名是需要积累的。
函数
庞大的系统都是聚沙成塔造就的，函数便是其中的“沙“。
短小
函数的第一条规则是要短小。第二条规则还是要短小。
书中给的限制是不超过20行，P3C要求不超过80行。
函数缩进层级不应超过两层，超过时可选择封装。
只做一件事
单一职责原则，使之改变的只有一个原因。
编写函数是为了把较大概念拆分为另一抽象层上的一系列步骤。
判断函数是否只做了一件事，就是看还能再拆不。
每个函数一个抽象层级
确保函数只做一件事，函数中的语句就要在同意抽象层级上。
自顶向下读代码：向下规则
下一步骤在函数尾，这样就一层一层的往里深入，往下执行。
switch语句
写出只做一件事的switch语句难，因为switch语句天生就是做多件事的。
条件分支抽取，或者将分支细节隐藏到子类中，利用工厂模式 多态解决。
使用具有描述性的名称
函数越短小，功能越集中，就越便于起个好名字。 别害怕长名称。长而具有描述性的名称，要比短而令人费解的名称好。
如果发现有更好的名称，请选择重构。
函数参数
避免使用3个以上的参数，超过3个，需要封装。
参数少，有利于单元测试。
单参数函数的普遍形式
不建议通过参数输出信息，应该是使用返回值的形式。
标识参数
标识参数丑陋不堪，向函数传入布尔值简直就是骇人听闻的做法。 相当于大声地宣布本函数不只做一件事。
使用布尔值参数时，违背了单一职责，应该把方法重构为两个方法，取消该参数。
双参数函数
一个参数时，一看就明白了，双参数时，容易忽略掉某个参数。
我们根本不该忽略任何代码，忽略掉的部分就是缺陷藏身之地。
减少参数的方法：1、重构为成员变量；2、封装部分或全部参数，封装部分时，其他的参数通过封装对象的方法传入，例如FieldWriter，通过构造器传入outputStream，然后在write方法传入参数name。
动词与关键字
生动形象描述函数。
可将参数名称编码进函数名。
无副作用
输出参数
给字符串添加后缀时，应将字符串和后缀作为输入参数。而不是只传入字符串，在函数里将后缀写死。
应主动考虑需求变更，面向拓展。
分隔指令和询问
单一职责：
函数要么做什么事，要么回答什么事，但二者不可兼得。
使用异常替代返回错误码
当条件分支复杂，多个分支都要返回错误信息时，可以抛出对应异常，在最外层捕获，返回捕获的异常信息。
抽离try/catch代码块
将异常处理，和正常的业务流程分离。
错误处理就是一件事
加上业务流程就违背单一职责了。
Error.java依赖磁铁
新增错误码时，所有使用到错误码的应用都需要重新构建。
而使用异常代替时，就没有这个烦恼，只构建新增异常的应用即可。
别重复自己
重复可能是软件中的一切邪恶的根源。
如何写出这样的函数
好代码是优化出来的。
打磨代码，分解函数，修改名称，消除重复，拆解类。
小结
大师级程序员把系统当做故事来讲，而不是当程序来写。
编写好的代码，才能向他人清晰地展示你写的故事。
Post Views: 390
