本文永久链接 – https://tonybai.com/2025/04/27/rob-pike-on-bloat
大家好,我是Tony Bai。
今年年初,Go语言之父、UTF-8编码的发明者Rob Pike的一篇题为”On Bloat”(关于膨胀)的演讲幻灯片(在2024年下旬做的)在技术圈,尤其是在Hacker News(以下简称HN)上,引发了相当热烈的讨论。Pike作为业界泰斗,其对当前软件开发中普遍存在的“膨胀”现象的犀利批评,以及对依赖管理、软件分层等问题的深刻担忧,无疑戳中了许多开发者的痛点。
HN上的讨论更是五花八门,开发者们纷纷从自身经历出发,探讨“膨胀”的定义、成因和后果。有人认为膨胀是“层层叠加的间接性”导致简单修改寸步难行;有人认为是“不必要的功能堆砌”;还有人归咎于“失控的依赖树”和“缺乏纪律的开发文化”。
那么,Rob Pike究竟在“抱怨”什么?他指出的软件膨胀根源有哪些?而作为我们Gopher,Go语言的设计哲学和工具链,能否为我们从纯技术层面提供对抗膨胀的“解药”呢?今天,我们就结合Pike的演讲精髓和HN的热议,深入聊聊软件膨胀的四大根源,并从Go的视角尝试寻找一下应对之道。
在深入探讨根源之前,我们需要认识到,“膨胀”并不止是字面意义上我们理解的最终编译产物的大小或者应用的运行速度慢,Pike的观点和HN讨论中的“软件膨胀”体现在多个维度:
下面我们具体看看Pike指出的“膨胀”几个核心根源:
Pike 指出,我们不断地为产品添加特性,以使其“更好”。但所有特性都会增加复杂性和成本,而维护成本是最大的那部分,远超初次实现。他警示我们要注意“有用谬论” —— 并非所有“有用”的功能都值得我们付出长期的维护代价。
HN讨论也印证了这一点:功能冗余、为了匹配竞品或满足某个高层“拍脑袋”的想法而添加功能、甚至开发者为了个人晋升而开发复杂功能的现象屡见不鲜。
技术层面:Go的“解药”在哪?
注:技术层面包括语言、工具以及设计思路和方法。
Pike 认为,现代软件层层叠加(硬件 -> 内核 -> 运行时 -> 框架 -> 应用代码),当出现问题时,我们太容易在更高的层级通过包装(wrap)来“修复”问题,而不是深入底层真正解决它。这导致了层层叠叠的“创可贴”,增加了复杂性和维护难度。他列举了ChromeOS文件App的例子,并强调要在正确的层级实现功能和修复。
在HN的讨论中,有开发者描述的修改按钮颜色需要穿透17个文件和多个抽象层的例子,正是这种“错误分层”或“过度抽象”的生动体现。
技术层面:Go的“解药”在哪?
这是Pike演讲中着墨最多、也最为忧虑的一点。他用数据(NPM 包平均依赖 115 个其他包,每天 1/4 的依赖解析发生变化)和实例(Kubernetes 的复杂依赖图)强调:
他强烈建议要理解依赖的成本,严格、定期地审视依赖树,并推荐了 deps.dev 这样的工具。
HN 社区对此深有同感,纷纷吐槽“为了一个函数引入整个库”、“脆弱的传递性依赖”、“供应链安全”等问题,并呼唤更好的依赖分析工具。
技术层面:Go的“解药”在哪?
Pike 对比了两种开源开发模式:
他暗示 Go 项目本身更倾向于后者,强调“先做好再提交”(make it good before checking it in)。可能很多Gopher也感受到了这一点,Go项目本身对代码质量的review非常严格,这一定程度上也“延缓”了一些新特性进入Go的时间点。
HN 的讨论中也涉及了类似 “Bazaar vs Cathedral” 的模式对比,但观点更加复杂,认为现实中的项目往往处于两者之间的某个位置,并且“完全不接受外部贡献”也并非良策。
技术层面:Go的“解药”在哪?
虽然 Go 的设计哲学和工具链在对抗软件膨胀方面提供了许多“天然优势”和“解药”,但我们必须清醒地认识到,Go 语言本身并不能完全免疫膨胀。
正如 Pike 在其“建议”(Advice) 中反复强调的,以及 HN 讨论中部分开发者指出的,最终软件的质量很大程度上取决于开发者和团队的“警惕与纪律” (vigilance and discipline):
如果缺乏这些,即使使用 Go,项目同样可能变得臃肿、复杂和难以维护。同时,HN 讨论也提醒我们,软件膨胀背后还有更深层次的组织、文化和经济因素,这些往往超出了单纯的技术和开发者纪律所能解决的范畴。
Rob Pike 的“抱怨”为我们敲响了警钟,Hacker News 的热议则展现了软件膨胀问题的复杂性和普遍性。它确实是我们在工程实践中需要持续对抗的“熵增”现象。
Go 语言以其简洁、显式、组合的设计哲学,以及强大的标准库和相对稳健的依赖管理,在技术层面上,为我们提供了对抗膨胀的有力武器。理解并拥抱这些 Go 的“基因”,无疑能在一定程度上帮助我们构建更健康、更可持续的软件系统。
当然,Pike 的观点也并非金科玉律。有批评者指出,他的视角可能带有一定的“NIH(非我发明)倾向”,并且存在两个关键的“盲点”:
注:“NIH(非我发明)倾向”是一种心理现象,指的是人们对他人提出的想法或创新持有偏见,通常因为这些想法不是自己发明的。这种倾向使得人们倾向于低估或拒绝其他人的创意,尽管这些创意可能是有价值的。
这种批评也提醒了我们,虽然 Pike 对简洁和纪律的呼吁值得我们高度重视,但在真实的商业环境和复杂的工程约束下,我们必须做出务实的权衡。纯粹的技术理想有时需要向现实妥协。
最终,我们每一位 Gopher 都需要在理解 Go 简洁之道的同时,保持批判性思维和务实态度。 在日常的每一个决策中,审慎地权衡简单与复杂、理想与现实、引入依赖与自主掌控,才能在这场与“膨胀”的持久战中,找到最适合我们项目和团队的平衡点,交付真正有价值且可持续的软件。
你如何看待 Rob Pike 对软件膨胀的观点?你认为他的批评切中要害,还是忽视了现实的复杂性?欢迎在评论区分享你的思考与实践!
商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。
© 2025, bigwhite. 版权所有.