系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』

简介: 软件工程最大的成本在于维护,为了未来可扩展、为了未来更灵活,我们往往会增加很多很多奇奇怪怪可有可无的代码,增加这些代码可能只需要几分钟,但移除这些代码花费的精力与承担的风险,却数倍于此。我们不断 YY 着所谓的未来,却让现在越来越糟。系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』。
文章被推送至 InfoQ 系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』

前言

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

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

本质复杂度与偶然复杂度

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,国内也巧妙的译为人月神话。书中提到软件的复杂度包括本质复杂度和偶然复杂度。本质复杂度就是在解决问题时,无论如何都必须要面对的复杂度;而偶然复杂度,是由于选用的做事方法不当,导致额外增加的复杂度。

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

系统的混乱

show

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创始人没这么干,将简单延续了下来,事实也证明,它真的很美。

因为信任所以简单

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

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

写在最后

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

参阅书籍
《Antifragile:Things That Gain from Disorder》
《The Art of Unix Programming》
《The Mythical Man-Month》
《Clean Architecture》

目录
相关文章
|
9月前
|
文字识别 算法 安全
转:图像处理算法在文档管理系统中的优势、误区及应用
图像处理算法在文档管理系统中可以提高处理效率、提高图像质量、实现文字识别和提取等功能,但也需要注意误判和错误处理的问题,并合理应用于不同的场景中。以下是关于图像处理算法在文档管理系统中的优势、误区以及应用的一些重要信息。
67 3
|
11月前
|
设计模式 小程序 测试技术
面对复杂问题时,系统思考助你理解问题本质
面对复杂问题时,系统思考助你理解问题本质
169 0
|
11月前
「管理」处理复杂性-一个粗略的指南,领导模式和理论
「管理」处理复杂性-一个粗略的指南,领导模式和理论
|
11月前
|
安全 程序员 UED
程序员在软件开发中,业务开发和非业务开发到底哪个工作量更大?
随着互联网的普及和信息化时代的到来,软件开发已经成为了一个非常重要的行业。而在软件开发的过程中,业务开发和非业务开发都是非常重要的环节。那么,在这两个环节中,哪一个工作量更大呢?本文将就此问题简单探讨一下。
128 1
程序员在软件开发中,业务开发和非业务开发到底哪个工作量更大?
|
Unix Java Linux
系统的混乱并业务本身之复杂,我们并不擅长处理『简单』
![](https://ata2-img.oss-cn-zhangjiakou.aliyuncs.com/neweditor/846d5052-1e21-4f9c-8f52-aaa37cacc407.png) # 前言 一群高智商青年在餐厅吃饭,餐桌上一个瓶盖标识为盐的瓶子里装得是胡椒粉,而标识为胡椒粉的瓶子里装得却是盐,他们想出了一个充满才气的方案来完成对调--仅需要一张餐巾纸、一根吸管和两个
48592 10
系统的混乱并业务本身之复杂,我们并不擅长处理『简单』
语音软件开发,整洁的代码更有利于长期发展
语音软件开发,整洁的代码更有利于长期发展
|
设计模式 安全 测试技术
如何快速理解复杂业务,系统思考问题?
对于复杂问题的思考其实是有层次的,从最表面的事件,到事件背后的规律,再到这个问题的结构模式,再到价值观,层层递进。在画完自己的业务系统因果回路图之后,再结合这个心智模型,思考自己的思考在哪个层次,是否可以有机会再下钻到更深的层次。
1178 2
如何快速理解复杂业务,系统思考问题?
|
运维 监控 数据库
面对平台间业务的迁移,你该做些什么?
面对平台间业务的迁移,你该做些什么?
212 0
面对平台间业务的迁移,你该做些什么?
|
Web App开发
《伟大的小细节:互联网产品设计中的微创新思维》——2.3 预期操作权衡
本节书摘来自华章计算机《伟大的小细节:互联网产品设计中的微创新思维》一书中的第2章,第2.3节,作者:文哲著, 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
1210 0