- java技术圈 - java技术社区

mp.weixin.qq.com · · 2200 次点击 · · 开始浏览

这是一个创建于的文章，其中的信息可能已经有所发展或是发生改变。

阿里妹导读：针对业务在不同场景下的差异，我们常常会习惯性地使用if-else来实现不同的业务逻辑，久而久之代码越来越难以维护。那么如何消除这些if-else？面对复杂业务应如何思考和分析？本文分享阿里高级技术专家张建飞（Frank）关于复杂业务治理的方法论，介绍一种多维度分析问题的方法：矩阵分析法。

文末福利：《微服务灰度实践及解决方案》在线直播。

You should not be a if-else coder, should be a complexity conquer.
——Frank

这篇文章，是对之前我在《阿里高级技术专家方法论：如何写复杂业务代码？》说的“自上而下的结构化分解 + 自下而上的抽象建模”方法论的升级。因为在之前的方法论中，我们缺少一个多维度看问题的视角，这种维度思维的缺失，可能会导致miss掉一些重要的业务信息，从而使我们制定软件设计策略的时候，陷入困难。

有了维度思维，我们便可以更加方面的去看清业务的全貌，更加全面的掌握业务信息，从而帮助我们更加体系化的去治理复杂性。

从if-else说起

我经常说，我们不要做一个if-else coder。这里的if-else，不是说我们在coding的时候不能使用if-else，而是说我们不应该简陋地用if-else去实现业务的分支流程，因为这样随意的代码堆砌很容易堆出一座座“屎山”。

业务的差异性是if-else的根源。以零售通的商品业务为例。不同的处理场景，其业务逻辑实现是有差异性的。如下图所示，商品业务的差异性，主要体现在商品类型、销售方式和仓储方式的不同。

这三个维度上的差异组合起来，有 2 * 3 * 2 = 12 之多。这就是为什么在老代码中，到处可以看到 if(组合品) blabla，if(赠品) blabla，if(实仓) blabla 之类的代码。

那么，要如何消除这些讨厌的if-else呢？我们可以考虑以下两种方式：

多态扩展：利用面向对象的多态特性，实现代码的复用和扩展。

代码分离：对不同的场景，使用不同的流程代码实现。这样很清晰，但是可维护性不好。

多态扩展

多态扩展可以有继承和组合两种方式。继承勿用多言，组合有点像策略模式，也就是把需要扩展的部分封装、抽象成需要被组合的对象，然后对其进行扩展，比如星环的能力扩展点就是这种方式。

这里，我们举一个继承的例子，商品在上架的时候要检查商品的状态是否可售，普通商品（Item）检查自己就好了，而组合商品（CombineItem）需要检查每一个子商品。

用过程式编码的方式，很容易就能写出如下的代码：

public void checkSellable(Item item){    if (item.isNormal()){        item.isSellable();         //省略异常处理    }    else{        List<Item> childItems = getChildItems();        childItems.forEach(childItem -> childItem.isSellable());         //省略异常处理    }}

然而，这个实现不优雅，不满足OCP，也缺少业务语义显性化的表达。更好的做法是，我们可以把CombineItem和Item的关系通过模型显性化的表达出来。

这样一来，一方面模型正确的反应了实体关系，更清晰了。另一方面，我们可以利用多态来处理CombineItem和Item的差异，扩展性更好。重构后，代码会变成：

public void checkSellable(Item item){    if (!item.isSellable()){        throw new BizException("商品的状态不可售，不能上架");    }}

代码分离

所谓的代码分离是指，对于不同的业务场景，我们用不同的编排代码将他们分开。以商品上架为例，我们可以这样写：

/*** 1. 普通商品上架*/public void itemOnSale(){    checkItemStock();//检查库存    checkItemSellable();//检查可售状态    checkItemPurchaseLimit();//检查限购    checkItemFreight();//检查运费    checkItemCommission();//检查佣金    checkItemActivityConflict();//检查活动冲突
    generateCspuGroupNo();//生成单品组号    publishItem();//发布商品}
/*** 2. 组合商品上架*/public void combineItemOnSale(){    checkCombineItemStock();//检查库存    checkCombineItemSellable();//检查可售状态    checkCombineItemPurchaseLimit();//检查限购    checkCombineItemFreight();//检查运费    checkCombineItemCommission();//检查佣金    checkCombineItemActivityConflict();//检查活动冲突
    generateCspuGroupNo();//生成单品组号    publishCombineItem();//发布商品}
/*** 3. 赠品上架*/public void giftItemOnSale(){    checkGiftItemSellable();//检查可售状态    publishGiftItem();//发布商品}

这种方式，当然也可以消除if-else，彼此独立，也还清晰。但复用性是个问题。

多维分析

细心的你可能已经发现了，在上面的案例中，普通商品和组合商品的业务流程基本是一样的。如果采用两套编排代码，有点冗余，这种重复将不利于后期代码的维护，会出现散弹式修改（一个业务逻辑要修改多处）的问题。

一个极端情况是，假如普通商品和组合商品，只有 checkSellable() 不一样，其它都一样。那毫无疑问，我们使用有多态（继承关系）的CombineItem和Item来处理差异，会更加合适。

而赠品上架的情况恰恰相反，它和其他商品的上架流程差异很大。反而不适合和他们合用一套流程代码，因为这样反而会增加他人的理解成本。还不如单独起一个流程来的清晰。

那么，问题来了，我们什么时候要用多态来处理差异，什么时候要用代码分离来处理差异呢？

接下来，是我今天要给你着重介绍的多维度分析问题的方法论之一：矩阵分析法。

我们可以弄一个矩阵，纵列代表业务场景，横列代表业务动作，里面的内容代表在这个业务场景下的业务动作的详细业务流程。对于我们的商品业务，我们可以得到如下的矩阵：

通过上面的矩阵分析，我们不难看出普通品和组合品可以复用同一套流程编排代码，而赠品和出清品的业务相对简单，更适合有一套独立的编排代码，这样的代码结构会更容易理解。

维度思维

多维度的重要性

上面的案例不是我编造出来的，而是我在和张文（我同事）讨论应该用哪种方式去处理业务差异的真实故事。

我记得在和大学讨论完，开车回去的路上，我一直在想这个问题，然后在第二个路口等红灯的时候，突然有一个灵感冒出来。我抑制不住兴奋，一边开车，一边发消息给张文说：“我想到了一个很NB的方法论，能解决在‘多态扩展’和‘代码分离’之间如何做选择的问题”。

其实，我知道我兴奋的不仅仅是解决了这个问题。我兴奋的是，我第一次真正领悟到了多维度思考的重要性。从而有机会从一个“单维度”生物，升级成一个“多维度”思考者。妈妈再也不用担心我被“降维打击”了 :)

结构化思维有用、很有用、非常有用，只是它更多关注的是单向维度的事情。比如我要拆解业务流程，我要分解老板给我的工作安排，我要梳理测试用例，都是单向维度的。

而复杂性，通常不仅仅是一个维度上的复杂，而是在多个维度上的交叉复杂性。当问题涉及的要素比较多，彼此关联关系很复杂的时候，两个维度肯定会比一个维度要来的清晰，这也是为什么说矩阵思维是比结构化思维更高层次的思维方式。

实际上，我们从汉语的词汇上，也不难看出一个人的思维层级，是和他的思考维度正相关的。当我们说这个人很“轴”、“一根筋”的时候，实际上是在说他只有一维的线性思维。所以，观察事物的视角越多，维度越丰富，其思维层级也会越高。

无处不在的多维思考

有了这些感悟，我开始系统的整理关于多维度思考分析的资料，发现这种思考方式真是无处不在。发现的越多，我越是感慨，为什么如此重要的思维方式，我到现在才领悟到。

波士顿矩阵

比如，在做产品分析的时候，有对产品发展前景进行分析的波士顿矩阵。

订单要素分析

当年，我在1688做交易下单业务的时候，有非常多的下单场景，每种场景下，买家享受的权益是不一样的（如下表所示）。我们当时也是使用了矩阵去表达这个复杂的关系，只是当时还没有想到要将其提升到方法论的高度。

数据交叉分析

在数据分析中，维度分析是非常重要的，特别是维度很多的时候，我们可以通过皮尔逊积矩相关系数，做交叉分析，从而弥补独立维度分析没法发现的一些问题。

简单相关系数矩阵

分析矩阵

最近我碰巧看到Alan Shalloway写的《设计模式解析：Design Patterns Explained》，这是一本非常经典的关于OOP的书，里面的第十六章就是专门讲“分析矩阵”的，作者创造这个方法论的初衷也是因为业务涉及的要素太多，信息量太大，他需要一种组织海量数据的新方式。

我和Alan的路径不一样，但是都得出了同样的结论。由此可见，这种矩阵分析的方式的确是对复杂业务进行分析的一把利器，业务场景越多，交叉关系越是复杂，越需要这样的分析。

组织阵型

生产关系决定生产力，对于一个管理者来说，如何有效的设置组织结构是决定团队是否能高效协作的关键。所以我们可以看到公司里面，每年都有比较大的关于组织结构和人员安排的调整。

对于技术团队来说，我们习惯于按领域划分工作范围，这样做的好处是责任到人、职责清晰。然而，领域只是一个维度，我们工作通常都是以项目的形式的开展，而项目通常是贯穿多个领域的。所以，在做团队组织规划的时候，我们可以通过业务领域和业务项目两个维度去看。

比如，在我负责的商品团队，我会按照如下的形式去做职责划分。

时间维度

除了工作，生活中也到处可见多维思考的重要性。

比如，我们说浪费可耻，应该把盘子舔的很干净，岂不知加上时间维度之后，你当前的舔盘，后面可能要耗费更多的资源和精力去减肥，反而会造成更大的浪费。

我们说代码写的丑陋，是因为要“快速”支撑业务，加上时间维度之后，这种临时的妥协，换来的是意想不到的bug，线上故障，以及无止尽的996。

RFM模型

简单的思考是“点”状的，比如舔盘、代码堆砌就是当下的“点”；好一点的思考是“线”状，加上时间线之后，不难看出“点”是有问题的；再全面一些的思考是“面”（二维）；更体系化的思考是“体”（三维）；比如，RFM模型就是一个很不错的三维模型。可惜的是，在表达上，我们人类只能在二维的空间里去模拟三维，否则四维可能会更加有用。