作者：聂晓龙

一、前言

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

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

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

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》

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

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

5.1 Maven 的 SNAPSHOT

Maven 的 SNAPSHOT 设计是我觉得非常棒的一个设计，当版本号为 1.0 时，是正式版，当版本号是 1.0-SNAPSHOT 时，是快照版，直接通过名字进行区分，简单清晰。

或许有人认为这比较粗暴，如果快照版后续还存在更多变种，那支撑起来会非常不优雅，应该用一个字段或属性来单独表示正式版还是快照版，这样更规范更易扩展。

过早的优化是万恶的根源，或许他的担忧是对的，但很庆幸当初 Maven 创始人没这么干，将简单延续了下来，事实也证明，它真的很美。

5.2 因为信任所以简单

因为信任所以简单，是阿里的一个价值观。有次周末打车去公司，师傅问你们不记录相关线路和内容，如果有人打车跑别处去玩了怎么办，我回答因为信任所以简单。我见过很多公司，为了约束员工，设定过非常繁杂的规则。而往往上有政策下有对策，公司与员工内耗在这无尽的拉扯中。

把握住问题的本质--信任。真实不装，互相信任，没那么多顾虑猜忌，问题就简单了，事情也就因此高效。

六、写在最后

小时候打台球，见到能翻袋，下底，长杆的人真厉害，幻想自己有一天能厉害到怎样难的球都能打进。长大后发现，真正厉害的人，母球永远不会轻易停在难打的地方。有能力解决复杂问题的人，我们给予掌声，而能够持续保持简单保持纯粹，应该得到更高的赞许。

参阅书籍

1、Antifragile:Things That Gain from Disorder

https://book.douban.com/subject/34978407/

2、The Art of Unix Programming

https://book.douban.com/subject/1229959/

3、The Mythical Man-Month

https://book.douban.com/subject/6039354/

4、Clean Architecture

https://book.douban.com/subject/26915970/