可在下方连接中关注原账号原文链接：https://mp.weixin.qq.com/s/Rk49n_QgHKPpbSyDj-vvHQ前言一群高智商青年在餐厅吃饭，餐桌上一个瓶盖标识为盐的瓶子里装得是胡椒粉，而标识为胡椒粉的瓶子里装得却是盐，他们想出了一个充满才气的方案来完成对调–仅需要一张餐…

前言

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

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

本质复杂度与偶然复杂度

All software construction involves essential tasks and accidental tasks.
— Frederick P.Brooks,Jr 《No Silver Bullet》
译：所有软件构建都包含其本质部分与偶然部分。

业务的复杂

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

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

系统的混乱

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着所谓的未来，却让现在越来越糟。​

我们以复杂应对简单

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

TMF的扩展实现

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

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

PD五颜六色的黑

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

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

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

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的方式进行重构，简单清晰，查问题成本也更低。当然，将blink画到PPT里，那确实还挺高大上的。​

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

​

『简单』其实更复杂

Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple。
— Steve Jobs
译：简单比复杂更难，你必须尽力理清思路才能做到简单。

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

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

KISS原则

Keep it Simple and Stupid
— Robert S. Kaplan
译：保持简单和笨拙

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

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

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》
译：如无必要，勿增实体。

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

Maven的SNAPSHOT

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

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

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

因为信任所以简单

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

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

写在最后

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

参阅书籍：
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/