【得物技术】供应链：乘风破浪—优雅代码四部曲

作者：阿福德（得物技术部）

引言
你见过超过1000行代码的方法吗？
你有没有读过非常晦涩、要很长时间才能读明白的代码？
你是否写过或者曾经听说过一些链接泄漏，文件句柄未释放的问题？
我可以打包票，只要你工作了几年，一定见过这些代码或问题。
你总是写这样的代码，小心别人带上📷约你去爬山。。。

本人工作已来，针对有味道的代码有了一些自己的思考，总结了如下四条如何编写优雅代码的方式方法。
今天就从切实从代码的角度， 一步步认识高逼格代码的应有的样子。完成产品的功能你还只是个青铜，做到下面的四部曲，你才是个王者！

第一部曲：关注词性，规范命名
一个小故事
今天你去相亲，
你李阿姨给你介绍了一个姑娘，她跟你说，姑娘的名字叫做王铁蛋^_
你先是愣了一愣，然后结结巴巴地说：我现在还不想要女朋友，谢谢你，李阿姨。
之后你从朋友那里得知，那个姑娘是一个特别水灵水灵的小姐姐，长得有点像迪丽热巴，并且已经有男朋友了。
编了上面这样一个故事，你们肯定早就知道我想要说什么了，没错，我今天要说的就是变成中命名的重要性。
关于命名，网上有许多文章讲如何进行命名，也有一些规范性的描述：
1、命名需要有意义的名字
2、如果一个名字需要注释，则说明，这个名字没有揭示其本质。
3、命名需要一致性性
4、概念类似的东西需要使用类似的名字
这里我要说的是，命名与词性的关系。

接口、类与词性
1、接口命名应该使用名词或形容词来命名
接口可以说是一种协议，而协议：可以是什么东西，或者什么样的，前者应该就是名词，后者就是形容词。
我们可以打开jdk源码看看常用的java.util包下所有的接口以及其词性：
Collection -------------名词
Comparator ------------名词
Deque ----------------名词
Enumeration -----------名词
EventListener ----------名词
Formattable -----------形容词
Iterator ---------------名词
List ------------------名词
ListIterator ------------名词
Map -----------------名词
NavigableMap ----------名词
NavigableSet -----------名词
Observer --------------名词
PrimitiveIterator --------名词
Queue ----------------名词
RandomAccess ---------形容词
Set ------------------名词
SortedMap ------------名词
SortedSet -------------名词
Spliterator ------------名词
可以看出，jdk中也基本遵循这种规范，既都是用名词或形容词来对接口进行命名。
2、类应该使用名词来命名
当我们初学java时，就被灌输以下的内容：
java是面向对象的语言，面向对象是一个非常庞大的话题，但是任何庞大的话题都有其核心的组成：类与对象。类是对某一类具有共性特征对象的抽象，而对象是类的一个具体实例。
既然类是某一类事物的共性的抽象概念，从语文的角度来看，可以简写为“类是概念”， 既然是概念，那“类”必然是名词了。
我们查看jdk中java.util包中所有的类（class）时，可以看到类都是通过名词来命名的，如下图。

常用的类命名
在编程中，我这里总结了一些常用类命名英文单词作为后缀。
XxxProcessor
XxxExecutor
XxxConverter
XxxHandler
XxxResolver
XxxBuilder
XxxProvider
XxxFilter
XxxListener
XxxContext
XxxManager
XxxExtension
XxxAdapter
XxxFactory
XxxWrapper
方法与词性
类中除了构造方法，其他的方法都应该是动词，如下是随意找到两个类, 可以看到这两个类的所有方法都是动词。
一个是org.apache.ibatis.executor.BaseExecutor, 另一个是io.opentracing.util.GlobalTracer

属性与词性
属性命名应该使用名词或形容词来命名。

第二部曲：使用金字塔原理，避免大方法
“想清楚，说明白，知道说什么，怎么说”，这是我们每个人希望达到的境界，毕竟在这如此忙碌的生活中，没有人有心情听你罗里吧嗦一大堆，最后又云里雾里，不知道你到底想表达什么。我们写代码也是一样。

「一个小故事」
书中举了这样一个例子：
你要出去买份报纸，你的妻子让你顺便买点东西回来，
她说：“看到电视上有那么多葡萄的广告，我现在特想吃葡萄。”
你穿衣服时，她又说：“也许你可以再买点牛奶。”
你穿上大衣，
她说：“咱家的土豆不够了应该再买点土豆，对了鸡蛋也没有。”
你走到门口，她又说：“再买些胡萝卜，也可以买些桔子。”
你按下电梯按钮，妻子说：“还有咸鸭蛋。”
你走进电梯，妻子又说：“再买些苹果和酸奶。”
请问，你记住妻子都要你买什么了吗？大概除了第一个葡萄和最后的酸奶，别的都没记住吧。没记住是因为你太笨吗？显然不是，这是因为妻子让你买的东西超过了七个，而且这些东西并没有被归类。
这意味着，当大脑发现需要处理的项目超过4个或5个时，就会开始将其归类到不同的逻辑范畴中，以便于记忆。
就好比这九种食物，葡萄 橘子 牛奶 咸鸭蛋 土豆 苹果 鸡蛋 酸奶 胡萝卜
大脑会自动地找出逻辑关系，进行抽象概括，将九种食物分成三组，这样我们无需记住九种食物，而仅需记住九种食物分别属于的三个组。这样不但可以减少大脑的负荷，而且也提高了我们思维抽象程度。

我们在写代码的时候，如果不进行归类，所有的代码都平铺开来，你可以很容易写出一个超大的方法。你是不是也经常写出超大的方法？
超大（比如超过200行）的方法有很多的“好处”：
1、可以让读者云里雾里，读不懂你的代码。
2、可以让你自己后续预估更多的时间来对其进行改造。
3、可以拖住测试，让测试花更多的时间，进行更大范围的回归测试。
把大象装进冰箱
把大象装进冰箱只需要三步，1、打开冰箱门，2、把大象装进去，3、关上冰箱门。然后每一步都是有很多的组成的，比如：打开冰箱门需要两步， 1、拉住冰箱门把手，2、手往外用力拉。
上述功能的伪代码如下：

持续重构，防止腐化
我们在写业务代码时， 由于业务的演化，代码也一直在演化，代码会越写越长。若不想让代码由于变得太长而不可维护，就需要采用“金字塔原理”来进行持续重构。
如果不进行归类，所有的代码都平铺开来，你可以很容易写出一个超大的方法。一个方法从”肥胖“到“健美” 应该经历下图的过程：

将“金字塔原理”用在我们的代码编写上，可以降低我们编写代码的复杂度， 也可以让读者更好的阅读，对与不想要关系细节的读者，只需要看最外层的代码就行，而不需要深入到最底层。
就像我们在读代码时，大部分时候是不会关系jdk的底层实现的，并且更少的时候会去关注java native方法使用C++的实现。

第三部曲：关注相关性，紧贴主题
一个类就是一个主题的抽象，类中的属性和方法需要紧紧的围绕着这个主题。那么问题来了，相关性你傻傻分的清楚嘛……(o^^o)。

飞机有一些部件：机翼、尾翼、发动机、起落架等等。航站楼与飞机有关联，但是在讲飞机部件的上下文中，航站楼就完全没有关系了。
相关性分为:直接相关，间接相关，无关。

围绕主题
一个类就是一个主题的抽象，类中的属性和方法需要紧紧的围绕着这个主题。
看一下jdk中java.util.concurrent.ExecutorService这个类：

这个接口是线程池的一个接口，我们从名字可以看到，它是一个执行器服务，再看里面的方法，看到看到都是围绕执行器服务来的，不会有任何与执行器不相关细的方法存在。
我们在看一下非常常用的接口：java.util.List

这个接口里面的所有方法，都是针对的“列表”这个主题。添加到列表、从列表删除、清空列表，列表是否包含，列表是否为空，从列表中获取等等。

直接关联
方法、属性需要直接与类的“主题”关联，这里举一个例子：

上面代码中的类是FlowFactory， 从类的名称来可以直到，这个类是产生Flow的，但是这个类实际在在创建图（makeGraph），据了解得知，Flow的底层是由图实现的；
我们前面提到，一个类的方法要与主题直接关联；更好的做法是，FlowFactory与Flow直接关联，而Flow与Graph直接关联，FlowFactory与Graph不能有关联。这就需要对Graph进行一个封装。
这里另外一个例子：

先解释一下，PinkOperateItem是PINK中的一个领域对象（“操作对象”），这个操作对象表示仓库中一个需要经过一系列处理（收货、分拣、拍照、质检、鉴别、绑证绑扣等）的商品，比如一双鞋。
这个操作对象有可以有很多的属性和行为，但是不应该有overTime()这样的一个方法，这里overTime表示是超时的意思（在预售项目中，卖家商品超时送到仓库），这里超时其实是收货超时，也就是对入库单的超时收货。
首页操作对象上不应该有“超时”这个概念，也就是“超时”这个概念不应该与操作对象相关联。它们之间没有相关性。

第四部曲：注意对称性，避免埋坑
世界具有对称性
我们的世界是对称性的，有“男”就有“女”， 有“上”就有“下”，有“物质”就有“反物质”

程序具有对称性

缺失对称性会有什么问题呢，仅仅是不够elegant嘛？no no no，就像下面右图的代码，一不小心就埋了个坑。
我们来看一下下面的代码，这是一个非常常见的问题，左边的代码，在同一个方法中进行lock和unlock。
在右边的方法中，testA方法调用testB进行lock，然后又直接unlock。这样做，代码运行肯定是没有问题，但是会埋坑，后人其他人（也可能是你自己）在另外的地方调用了testB，就可能不去unlock。

我们都知道编码中，一旦你打开一个文件句柄，你就必须关闭它。从连接池中获取一个连接，就需要归还这个连接；开启了一个事务，就需要提交或者回滚这个事务。这些都是对称的。
上面说的是在一个方法中，我需要考虑到对称性，对类来说，存在这样的对称性，如下：

上面是Filter类，我们可以看到，这个类，有init方法，同时就会有destroy方法。
又比如：java.io.File类， 有create文件方法，同时就有delete文件的方法。

常用对称性词汇
总结一波对称性词汇，助你命名无忧～～

写在最后
我们通过代码来描述这个多彩的世界。
我们的世界是有机的、有序的，对称的。
世界是怎么样的，我们就怎么去写Code，这样就能写出优雅的代码！
我们要面向现实编程，并进行必要的抽象，但抽象一定要符合世界的规律。