大泥球架构

概述

“大泥球”这个名词最早来源于 UIUC 两位计算机科学家（Brian Foote 和 Joseph Yoder）的声讨檄文《Big ball of mud》；该文痛批了那些结构随意、杂乱无序、臃肿肥大、布满了“胶带”与“捆扎线”的、意大利面条式的软件混合体。

Big ball of mud

“大泥球”这个名字起得还是非常贴切的，大家如果有兴趣（且非常非常闲）可以试着找个遗产系统并画个代码模块依赖图，大概率你能得到如下的结果：

Dependencies

上图还是很像大泥球的吧？通常来说，一个维护多年的遗产系统最后都会成为一个混沌系统——代码间的联系可正亦可负、可有亦可无。我们现实生活中也有许多类似混沌的“遗产”，很多人的态度是：要对未知保持谦卑，并认为这种系统有着一套自己的“哲学”，只有挖掘出它的深刻奥义才能驾驭这份“遗产”。但是，软件行业内对“遗产”抱有上述观念的只属于少数群体，主流的观点还是把那种不能通过常规认知的混沌系统，统称为“大泥球架构”（或是“屎山”）。

“大泥球架构”项目从代码规范或是人员组成上也有许多共通点：

• 系统往往缺少架构设计资料，或从未有过良好的架构分层（那种只分了几个文件夹的不能算）
• 系统中相距很远的模块被杂乱无章的共享
• 重要信息被设为全局上下文，通常还会被重复定义
• 团队成员缺乏最基本的“架构敏感性”
• “工作积极分子”是一些热衷无聊琐事的人

形成原因

当然，现实中很少会有人特地设计出“不可认知”的架构。只不过最终“大泥球”还是成为了最常见的系统架构，因为通常的系统经过几年或是几十年的“代码填充”，想不变成“大泥球”也难。直接原因就是技术和管理太落后了：

• 劳动密集型的开发模式，最明显的特征就是开发前期没有业务设计这一步，靠“意识”堆砌的代码
• 流程、规则、工具，以及基础设施始终被限定在开发初始阶段（Google 搜索不到的技术和类似于写 Demo 的开发形式）
• 开发团队缺少必要的分工与技术专业化，比如没有“架构师”（纯技术 KPI 向的角色）
• 程序员的经验、技巧、眼见等等被限定在 CRUD 中

笼统来说就是“业务线”和“技术线”本应该是两条并行向前的线路，但是业务线在不断扩充的同时，技术管理这块停滞不前，最终拖累了业务扩展。

平心而论，我们还是要肯定这类软件的商业价值。因为能存活几年甚至是几十年的软件必然是解决了生产生活中的一些痛点，领导干部自然也是人中龙凤了；只是底层的小职员过得并不开心罢了，有点类似于大城市里的“棚户区”，看着房价很高，但是上个厕所还得去“茅房”。

解决方法

回到正题，把“大泥球”的宿命归咎于程序员的技术水平低和管理不善，显然是没用的。根本原因还是软件规模的增长，必然使得代码和团队变得笨重，即便使用最积极的生产策略，这些情况大概率依旧会发生。关键还是得解耦，只能靠把系统做小，把软件规模变小才行。

系统解耦

系统层面的解决方法是将代码解耦，拆分成各个子系统；通俗来说就是组件化、模块化，甚至是微服务化。每个组件或模块，都可以独立开发，通过公开的接口被其它部分调用。当然，要设计接口（就是公共的规则）需要有架构师这类角色，处理不当又容易成为新的问题。

Monlithic vs microservices

团队解耦

现实中，技术其实并不是最难的，“人”才是。这里不展开人的问题了，只介绍现在常常被谈起的一种组织形式——小团队：由五六人组成的全功能软件开发组织。实行“小团队”也同时需要“大组织”下放职权，由一个小组织来负责一个或几个完整的子模块（或组件，或服务）；小团队完成内部所有的设计、编码、测试、部署、产品支持等等任务。强制软件系统依照小组织的形式分工，并分配 KPI 和责任；让从下往上的动力来推动系统解耦。由于职责下放，组织能自己决定子模块的内部细节，包括开发工具、基础设施、重构计划、交付形式等等；而不同组织间只要通过架构师设计的接口实现连接即可。

Organization

这种组织形式点类似中国改革开放中出现的“县域经济”模式，各个县按照自己的特色发展经济，实现“县际竞争”；而更高层的组织者需要做的是把“各地”优秀的实践经验迅速推广开来。经济学家张五常就大力夸奖过中国的县域经济；现实中那些县域经济特别强大的省份，往往也是全国最富裕的省份。我们开发人员其实也可以从更广的视野来看待一些问题，陷在“大泥球”里毕竟解决不了问题。

没有银弹

再写一下总结。本文简单讲解了“大泥球架构”的特点与解决方法，可惜这些都是务虚的理论：只有宏观的借鉴意义，却没有实操的指导作用。因为世上并没有“银弹”，当你的系统已经是“大泥球”时，也就意味着剩下的都是难啃的骨头了。这时候，无论进与退，亦或是原地踏步都是艰难的选择；这里我个人的意见还是往前进的，至少我们要 push 自己做一些适合自己成长的事，毕竟窝在大泥球一动不动对个人的帮助为零。
最后，我还是很想推荐一本书，叫《程序员的呐喊》，是本很有争议的书：它对开发混沌架构的开发们，给了这么一个建议：“趁早离职”；哈哈，anyway，“尽吾力而不能至者，可以无悔也”。

文章同步发布于an-Onion 的 Github。码字不易，欢迎点赞。