作者：聂晓龙

一、前言

一群高智商青年在餐厅吃饭，餐桌上一个瓶盖标识为盐的瓶子里装的是胡椒粉，而标识为胡椒粉的瓶子里装的却是盐，他们想出了一个充满才气的方案来完成对调--仅需要一张餐巾纸、一根吸管和两个空碟子。当他们叫来服务员，准备炫耀他们的天才想法时，只见服务员什么也没说，只是拿起盐瓶和胡椒粉瓶，互换了瓶盖……

在我们软件工程中，同样一件事情可以有很多种解决方案，我们翻开那继承下来的祖传代码，系统堆叠了太多它不需要或者它不适合的动态扩展、规则引擎、条件分支等等。原本并不复杂的业务最终得到的还是一片混乱，是我们的做法还是太过简单吗？或许本质上是我们并不擅长处理『简单』。

二、本质复杂度与偶然复杂度

All software construction involves essential tasks and accidental tasks.

—— Frederick P.Brooks,Jr 《No Silver Bullet》

译：所有软件构建都包含其本质部分与偶然部分。

2.1 业务的复杂

Frederick P.Brooks,Jr 在1975年写下了软件界的一本著作 The Mythical Man-Month，国内也巧妙的译为人月神话。书中提到软件的复杂度包括本质复杂度和偶然复杂度。本质复杂度就是在解决问题时，无论如何都必须要面对的复杂度；而偶然复杂度，是由于选用的做事方法不当，导致额外增加的复杂度。

我们不否认在交易场景、订单场景、支付场景等，可能天然存在非常复杂的业务逻辑，但同样也并非所有的系统都像电商平台一样复杂。随着业务的分拆，组织职能的划分以及微服务的普及，我们面临的问题与场景越来越小越来越聚焦。业务的复杂性天然存在，当我们看着那捉摸不透宛如天书的功能代码时，我们试问一下自己的业务是否真的有那么复杂。

2.1 系统的混乱

Despite all their heroics, overtime, and dedication, they simply aren't getting much of anything done anymore. All their effort is now consumed with managing the mess.

-- Robert C.Martin 《Clean Architecture》

译：不管你们多敬业、加多少班，在面对烂系统时，你仍然会寸步难行，因为你大部分的精力不是在开发需求，而是在应对混乱。

我们经常遇到一个简单的业务诉求，但在老系统上支持就异常艰难。“在人离开的时候，自动把门关上”，但你永远不知道这个房间到底有多少门，同样你也莫名其妙会遇到，某些门关上后窗又碎了。

软件工程最大的成本在于维护，系统的混乱并非业务本身之复杂，简单的模块我们同样可能搞砸。为了未来可扩展，为了未来更灵活，我们不断YY着所谓的未来，却让现在越来越糟。

三、我们以复杂应对简单

诉求有时非常简单，但我们又岂会“甘于做一个执行器”，我们认为这背后一定有更深刻的业务诉求，一定有更本质的商业问题，一定有更底层的层次逻辑。于是我们摆摆手说道：这可没那么简单~

3.1 TMF的扩展实现

TMF是业务中台面向可复用可扩展架构的核心，在平台与业务分离，业务与业务隔离上可以起到重要作用。当我们发现有中国商家需求的同时还存在在海外商家业务，我们立马抄起了TMF来设计我们的扩展与编排。最终代码上线3年，也只有可怜的2个实现。无数的后人需要花更多的时间来理解与维护这段曾经的“高光设计”。

当出现第3个扩展诉求时，有人发现不应该用这么重的框架，于是写了一个简单的策略模式来支撑，而原有的TMF代码又不敢动，于是在可怜的3个扩展实例里还并存着2套扩展框架。再接下来又引申出了另一个课题，去TMF。或许真正需要的，只是3段简单的if-else。

3.2 PD五颜六色的黑

我们也曾经遇到这样的需求，为了方便销售更好的筛选客户，产品提出增加各式各样标签共计80余个，并且支持标签与标签间，可以灵活的让用户选择取交集还是取并集。最终我们发现，销售名下客户的中位数是8个，也就是说大部分销售1~2页可以翻完自己名下的所有客户，当时我们也戏称，标签设计得比客户还多。

部分产品经理没有思考核心的问题到底是什么，在浅层次疯狂堆叠功能，美其名曰业务需要不断试错，实则缺少思考，缺少对问题根因的理解与判断。在复杂这条路上越走越远，也让真正的简单越来越难。

四、‘复杂’的光环与‘简单’的暗淡

Simplicity has been difficult to implement in modern life, because it is against the spirit of a certain brand of people who seek sophistication so they can justify their profession.

-- Nassim Nicholas Taleb 《Antifragile:Things That Gain from Disorder》

译：在现实生活中，简单的做法一直难以实现，因为它有违某些努力寻求复杂化，以证明其工作合理性的人所秉持的精神。

为什么大家更偏向复杂而远离简单，除了缺少思考，找不到问题的核心解以外，还有一个重要原因就是为了所谓的“证明自己”。Nassim Nicholas Taleb 在 Antifragile:Things That Gain from Disorder 中提到一个观点：在现实生活中，简单的做法一直难以实现，因为它有违某些努力寻求复杂化，以证明其工作合理性的人所秉持的精神。

如同DDD在中小系统所带来的灾难一样，根本原因更多是因为大家并不愿意承认自己的系统是中小系统，自己所承接的业务是偏向简单的业务。最终导致简单的模块赋以复杂的束缚，最终效率被工具本身所制约。

曾经有一个搜索器增量推送的诉求，当时用blink来支持，blink支持海量数据处理，分布式集群能力等等。而我们本身并没有海量数据，也没有超高并发，最终上线后不仅用不上blink超强的能力，还因为blink的性能调优、自定义函数异常、类型转换异常、资源申请及降级，以及为新人带来的认知负荷等等，带来了更大的不便。后面通过手写JAVA，调用搜索器增量推送SDK的方式进行重构，简单清晰，查问题成本也更低。

‘复杂’总是伴随着光环，当我们解决一个复杂问题后，我们会得到更多人的肯定，向大家证明和展示自己的实力。而简单往往更‘暗淡’，如同上文提到的互换瓶盖，大家并不会因此认可服务生的能力，甚至觉得也没什么大不了。如此往复，让大家更青睐复杂，更远离简单。

4.1 『简单』其实更复杂

Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple。

-- Steve Jobs

译：简单比复杂更难，你必须尽力理清思路才能做到简单。

手机的HOME键是极简主义的一个代表，据说小圆点的设计灵感是受到马桶的启发，用一个按钮清除所有。

简单并不代表容易，简单意味着非联接，而非联接并不简单。在降低复杂度上，软件设计有一个核心理念叫“解耦”，核心思想是分离关注点，只有你聚焦的内容少了，你才不会觉得复杂。

4.2 KISS原则

Keep it Simple and Stupid

-- Robert S. Kaplan

译：保持简单和笨拙

KISS原则是Robert S. Kaplan提出的一个理论，Kaplan并非是一个软件学家，他是平衡积分卡 Balanced Scorecard 创始人，而他所提出的这个理论对软件行业依然适用。把事情变复杂很简单，把事情变简单很复杂。我们需要尽量让复杂的问题简明化、简单化。

KISS原则的实现看似简单，但实则并不容易。以最简单的做法完成任务，但不断引入复杂度并腐化系统的做法，被John Ousterhout教授称之为「战术龙卷风」。当你不断打着KISS原则的旗号，以最简单的做法堆叠功能时，最终会得到一个终极复杂体。软件设计是一门艺术，前人的经验可以给我们提供前进的方向，但我们也一定要时刻有自己的判断。

4.3 UNIX的艺术

1974年UNIX系统在Communication of ACM上发表，正式向外界披露了UNIX系统。UNIX的成功也诞生了诸如Linux、BSD、Solaris、MacOSX等多个UNIX变种。UNIX奠基人之一的Doug Mcllroy曾经说，UNIX的设计理念就是一个程序只做一件事，并做好。

All the philosophy really boils down to one iron law, the hallowed ‘KISS principle’ of master engineers everywhere.

-- Eric Steven Raymond 《The Art of Unix Programming》

译：所有的UNIX哲学浓缩为一条铁律，那就是各地编程大师们奉为圭臬的KISS原则。

UNIX的哲学根本，就是一部在持续践行KISS原则的卓越工程。『维护如此重要而成本如此高昂，在写程序时，要想到你不是写给执行代码的计算机看的，而是给人--将来阅读维护源码的人，包括你自己』——The Art of Unix Programming

五、遗失的奥卡姆剃刀

Entities should not be multiplied beyond necessity.

-- William of Ockham 《Occam's Razor》

译：如无必要，勿增实体。

奥卡姆剃刀也称为奥康定律，最先并非在软件界提出而是在哲学界。保持事情的简单性，抓住根本，去掉无关内容，是奥卡姆剃刀的核心观念。在软件设计中，每一次的抽象，都是在放大本质因素，消除无关因素。奥卡姆剃刀的缺失，也让我们的系统越来越复杂，我们总能发现有很多奇奇怪怪可有可无的代码，散落在系统各处，增加这些代码可能只需要几分钟，但移除这些代码花费的精力与承担的风险，却数倍于此。