本文永久链接 – 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讨论中的“软件膨胀”体现在多个维度：

• 复杂性失控： 过度的抽象层次、复杂的依赖关系、难以理解的代码路径，使得维护和迭代变得异常困难。
• 维护成本剧增： 添加新功能的长期维护成本（包括理解、测试、修复Bug、处理兼容性）远超初次实现的成本，但往往被低估。
• 不可预测性与脆弱性： 庞大且快速变化的依赖树使得我们几乎无法完全理解和掌控软件的实际构成和行为，任何更新都可能引入未知风险。

下面我们具体看看Pike指出的“膨胀”几个核心根源：

根源一：特性 (Features) —— “有用”不等于“值得”

Pike 指出，我们不断地为产品添加特性，以使其“更好”。但所有特性都会增加复杂性和成本，而维护成本是最大的那部分，远超初次实现。他警示我们要注意“有用谬论” —— 并非所有“有用”的功能都值得我们付出长期的维护代价。

HN讨论也印证了这一点：功能冗余、为了匹配竞品或满足某个高层“拍脑袋”的想法而添加功能、甚至开发者为了个人晋升而开发复杂功能的现象屡见不鲜。

技术层面：Go的“解药”在哪？

• 简洁哲学： Go从设计之初就强调“少即是多”，鼓励用简单的原语组合解决问题，天然地抵制不必要的复杂性。
• 强大的标准库： Go 提供了功能丰富且高质量的标准库，覆盖了网络、并发、加解密、I/O 等众多领域，减少了对外部特性库的依赖。很多时候，“自己动手，丰衣足食”（使用标准库）比引入一个庞大的外部框架更符合Go的风格。
• 关注工程效率： Go的设计目标之一是提高软件开发（尤其是大型项目）的工程效率和可维护性，这促使Go社区更关注代码的清晰度和长期成本。

注：技术层面包括语言、工具以及设计思路和方法。

根源二：分层 (Layering) —— 在错误的层级“打补丁”

Pike 认为，现代软件层层叠加（硬件 -> 内核 -> 运行时 -> 框架 -> 应用代码），当出现问题时，我们太容易在更高的层级通过包装（wrap）来“修复”问题，而不是深入底层真正解决它。这导致了层层叠叠的“创可贴”，增加了复杂性和维护难度。他列举了ChromeOS文件App的例子，并强调要在正确的层级实现功能和修复。

在HN的讨论中，有开发者描述的修改按钮颜色需要穿透17个文件和多个抽象层的例子，正是这种“错误分层”或“过度抽象”的生动体现。

技术层面：Go的“解药”在哪？

• 小接口哲学： Go 鼓励定义小而专注的接口，这使得组件之间的依赖更清晰、更松耦合。当问题出现时，更容易定位到具体的接口实现层去修复，而不是在外部层层包装。
• 组合优于继承： Go 通过组合（struct embedding）而非继承来实现代码复用，避免了深度继承带来的复杂性和脆弱性，使得在“正确层级”修改代码更易操作。
• 显式错误处理： if err != nil 的模式强制开发者在调用点处理错误，使得问题更难被“隐藏”到上层去统一“包装”处理，鼓励在错误发生的源头附近解决或添加上下文。

根源三：依赖 (Dependencies) —— 看不见的“冰山”

这是Pike演讲中着墨最多、也最为忧虑的一点。他用数据（NPM 包平均依赖 115 个其他包，每天 1/4 的依赖解析发生变化）和实例（Kubernetes 的复杂依赖图）强调：

• 现代软件依赖数量惊人且变化极快。
• 我们几乎不可能完全理解自己项目的所有直接和间接依赖。
• 依赖中隐藏着巨大的维护成本、Bug 和安全风险。
• 简单的 npm update 或 audit 无法解决根本问题。

他强烈建议要理解依赖的成本，严格、定期地审视依赖树，并推荐了 deps.dev 这样的工具。

HN 社区对此深有同感，纷纷吐槽“为了一个函数引入整个库”、“脆弱的传递性依赖”、“供应链安全”等问题，并呼唤更好的依赖分析工具。

技术层面：Go的“解药”在哪？

• Go Modules： 相比 NPM 等包管理器，Go Modules 提供了相对更好的依赖管理机制，包括语义化版本控制、go.sum 校验和、最小版本选择 (MVS) 等，提高了依赖的可预测性和安全性，但也要注意Go module并非完美。
• 强大的标准库： 这是 Go 对抗依赖泛滥的最有力武器。很多功能可以直接使用标准库，避免引入外部依赖。
• 社区文化： Go 社区相对而言更推崇稳定性和较少的依赖。引入一个大型框架或过多的外部库在 Go 社区通常需要更充分的理由。
• 工具支持： Go 提供了 go mod graph, go mod why 等命令，可以帮助开发者理解依赖关系。结合 deps.dev，可以在一定程度上实践 Pike 的建议。

根源四：开源模式 (Open Source Development) —— “大门敞开” vs “严格把关”

Pike 对比了两种开源开发模式：

• “真正的开源方式” (The true open source way): 接受一切贡献 (Accept everything that comes)。他认为这是膨胀和 Bug 的巨大来源。
• 更好的方式： 设立严格的代码质量、标准、评审、测试、贡献者审查等“门槛”，对允许合入的内容有标准。这种方式维护成本低得多。

他暗示 Go 项目本身更倾向于后者，强调“先做好再提交”（make it good before checking it in）。可能很多Gopher也感受到了这一点，Go项目本身对代码质量的review非常严格，这一定程度上也“延缓”了一些新特性进入Go的时间点。

HN 的讨论中也涉及了类似 “Bazaar vs Cathedral” 的模式对比，但观点更加复杂，认为现实中的项目往往处于两者之间的某个位置，并且“完全不接受外部贡献”也并非良策。

技术层面：Go的“解药”在哪？

• Go 自身的开发模式： Go 语言本身（由 Google 主导）的开发流程相对严谨，对代码质量和向后兼容性有较高要求，可以看作是“严格把关”模式的体现。
• 标准库的设计： Go 标准库的设计精良、接口稳定，为开发者提供了一个高质量的基础平台，减少了对外部“随意贡献”的依赖。
• 社区项目实践： 观察 Go 社区一些知名的开源项目，其贡献流程和代码标准通常也比较严格。

反思与现实：Go 也非万能，“警惕与纪律”仍是关键

虽然 Go 的设计哲学和工具链在对抗软件膨胀方面提供了许多“天然优势”和“解药”，但我们必须清醒地认识到，Go 语言本身并不能完全免疫膨胀。

正如 Pike 在其“建议”(Advice) 中反复强调的，以及 HN 讨论中部分开发者指出的，最终软件的质量很大程度上取决于开发者和团队的“警惕与纪律” (vigilance and discipline)：

• 我们是否真正理解并避免了增加不相称成本的特性？
• 我们是否努力在正确的层级解决问题？
• 我们是否审慎地评估和管理了每一个依赖？
• 我们是否坚持了高标准的开发和评审流程？

如果缺乏这些，即使使用 Go，项目同样可能变得臃肿、复杂和难以维护。同时，HN 讨论也提醒我们，软件膨胀背后还有更深层次的组织、文化和经济因素，这些往往超出了单纯的技术和开发者纪律所能解决的范畴。

小结：拥抱 Go 的简洁，但需务实前行

Rob Pike 的“抱怨”为我们敲响了警钟，Hacker News 的热议则展现了软件膨胀问题的复杂性和普遍性。它确实是我们在工程实践中需要持续对抗的“熵增”现象。

Go 语言以其简洁、显式、组合的设计哲学，以及强大的标准库和相对稳健的依赖管理，在技术层面上，为我们提供了对抗膨胀的有力武器。理解并拥抱这些 Go 的“基因”，无疑能在一定程度上帮助我们构建更健康、更可持续的软件系统。

当然，Pike 的观点也并非金科玉律。有批评者指出，他的视角可能带有一定的“NIH（非我发明）倾向”，并且存在两个关键的“盲点”：

1. 忽视了“不使用依赖”同样是巨大的技术债。 每一行自写的代码都需要永远维护。
2. 现实中的选择往往不是“使用依赖 vs 自己实现”，而是“使用依赖 vs 根本不做这个功能”。 面对复杂的合规要求（如 ADA、GDPR）、第三方集成或 FIPS 认证等，从零开始构建的成本（可能需要数百人年）往往让“自己实现”变得不切实际。为了让产品能够及时上线并满足用户（哪怕是 Pike 本人可能也在使用的“缓慢”网站）的需求，引入依赖和一定的“膨胀”有时是必要且务实的选择。

注：“NIH（非我发明）倾向”是一种心理现象，指的是人们对他人提出的想法或创新持有偏见，通常因为这些想法不是自己发明的。这种倾向使得人们倾向于低估或拒绝其他人的创意，尽管这些创意可能是有价值的。

这种批评也提醒了我们，虽然 Pike 对简洁和纪律的呼吁值得我们高度重视，但在真实的商业环境和复杂的工程约束下，我们必须做出务实的权衡。纯粹的技术理想有时需要向现实妥协。

最终，我们每一位 Gopher 都需要在理解 Go 简洁之道的同时，保持批判性思维和务实态度。 在日常的每一个决策中，审慎地权衡简单与复杂、理想与现实、引入依赖与自主掌控，才能在这场与“膨胀”的持久战中，找到最适合我们项目和团队的平衡点，交付真正有价值且可持续的软件。

你如何看待 Rob Pike 对软件膨胀的观点？你认为他的批评切中要害，还是忽视了现实的复杂性？欢迎在评论区分享你的思考与实践！

参考资料

• Rob Pike – On Bloat – https://docs.google.com/presentation/d/e/2PACX-1vSmIbSwh1_DXKEMU5YKgYpt5_b4yfOfpfEOKS5_cvtLdiHsX6zt-gNeisamRuCtDtCb2SbTafTI8V47/pub?slide=id.p
• HN：On Bloat – https://news.ycombinator.com/item?id=43045713
• Pike is wrong on bloat
• On Bloat – https://commandcenter.blogspot.com/2025/02/on-bloat-these-are-slides-from-talk-i.html

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/04/23/tips-for-reading-technical-books

大家好，我是Tony Bai。

今天是世界读书日。聊到读书，尤其是咱们技术人经常要面对的那些厚重的“技术砖头”，估计不少朋友都有过类似的挣扎：道理都懂，书很重要，但就是感觉难啃、读不进去，或者读完就忘，效果不彰。

技术书籍往往信息密集、逻辑严谨、内容晦涩，想要高效地从中汲取养分，确实需要讲究一些方法。我自己就是一个长期主义者，坚信持续学习和深入思考的力量。多年来，我不仅坚持阅读，也一直在我的博客tonybai.com以及本公众号上进行长期的、持续的输出，这个过程让我对如何高效阅读和内化知识，有了一些切身的体会和思考。 此外，如今AI工具日益强大，如何结合传统方法与智能辅助，是一个非常值得探讨的话题。

今天，我就结合我的长期实践，和大家分享一些个人实践，特别是在攻克难点和整理笔记环节，我也会着重谈谈AI如何能成为我的得力助手，希望能帮助你更好地攻克技术“硬书”，将知识真正转化为自己的竞争力。

心法一：明确目标，精准选书——为何而读？

在信息爆炸的时代，选对书可能比努力读更重要。开始前，先明确“为何而读”：

• 当前痛点/目标是什么？ (深入Go并发？掌握K8s？学习AI Agent开发？)
• 这本书能解决问题吗？ 通过看目录、序言、书评（例如在豆瓣读书、亚马逊评论区、O’Reilly Learning Platform、Manning官网 等站点优质站点查找）、作者背景来判断。
• 难度是否匹配？ (是否需要前置知识？)

我的做法： 基于工作和学习规划、以及遇到的技术瓶颈选书，优先选择能直接解决我当下问题的、或者能为我未来方向打下坚实基础的书(这的确需要一些前瞻性的技术眼光)。带着明确的目的去读，效率和动力都会高很多。

心法二：主动出击，建立框架——如何开始？

面对“砖头书”，忌直接死磕。先做“侦察”，建立整体认知：

• 速览目录、序言、总结： 把握全书结构、核心思想。
• 带着问题阅读： 主动思考你想从中获得什么答案。

我的做法： 我通常会先花半小时到一小时快速“翻阅”全书，在脑海里构建一个大致的知识地图。然后根据我的目标，决定是通读全书，还是重点阅读某些章节。对于特别重要的章节，我会先看一遍小结，再带着问题去细读正文。

心法三：攻克难点，允许“跳过”

遇到难啃的概念或复杂逻辑卡壳时：

• 别死磕，标记跳过： 保持阅读节奏，避免挫败感。后续内容或整体理解可能有助于回头解决。
• 寻求外援： 查阅资料、社区提问，或同主题书籍的交叉阅读，从多个角度帮助理解难啃的技术概念。

AI在此环节的“神助攻”

在这个最容易卡壳、也最考验耐心的环节，AI展现出了惊人的辅助潜力，能显著提升我们攻克难点的效率。以下是一些你可以尝试的提示词示例（以经典书籍《The Go Programming Language》为例）：

• 多角度解释：

  • “请用一个现实生活中的例子，解释《The Go Programming Language》中描述的 Go channel 的概念，特别是带缓冲和不带缓冲 channel 的区别。”
  • “我正在读 TGPL 关于 interface 的章节，对于『接口值』的内部结构（类型和值）有点模糊，请用更通俗的语言解释一下，并说明为什么 nil 接口值不等于包含 nil 指针的接口值？”
  • “请对比 TGPL 中提到的 goroutine 和传统操作系统线程，用打比方的方式解释goroutine的『轻量』体现在哪里？”

• 代码示例具象化：

  • “请根据《The Go Programming Language》中关于 select 语句的介绍，写一个简单的 Go 代码示例，展示如何使用 select 实现一个非阻塞的 channel 发送操作。”
  • “我需要理解 TGPL 中错误处理章节提到的 %w 动词，请提供一个 Go 代码片段，演示如何使用 fmt.Errorf 和 %w 来包装错误，并随后使用 errors.Is 和 errors.As 来检查和提取原始错误。”

• 模拟对话与“抬杠”：

  • “假设你是一位 Go 语言专家，我正在学习 TGPL 的并发章节。我对于 mutex 和 channel 的选择有些困惑，在什么场景下应该优先选择 mutex？什么时候 channel 是更好的选择？我们来讨论一下，请给出你的理由和实例。”
  • “我看到 TGPL 中提到『不要通过共享内存来通信，而应该通过通信来共享内存』。这句话很经典，但我对其理解不够深入。你能挑战我的理解吗？比如，在哪些情况下共享内存（如使用 sync.Mutex）反而是更合适的选择？请举例说明。”

AI就像一位不知疲倦、拥有广阔知识的“智能私教”，能够针对你的难点进行个性化的“辅导”，极大地加速了理解和突破瓶颈的过程。

心法四：提炼精华，有效笔记

“不动笔墨不读书”，关键是怎么记：

• 用自己的话总结： 这是内化的核心，检验是否真懂。
• 建立知识关联： 将新知识与旧知识联系起来。
• 代码示例验证： 亲自实践代码是关键。
• 结构化整理： 思维导图、结构化笔记等，用于复习和输出。但在我来看，这不是必须。

AI在此环节的“效率加速器”

在整理和消化大量信息的过程中，AI 同样能扮演好“智能助手”的角色，帮助我们提高效率，聚焦核心。以下是一些你可以尝试的提示词示例（同样以《The Go Programming Language》为例，前提是你拥有该书籍的电子版数据，用来喂给AI）：

• 辅助总结与提炼：

  • “请帮我将《The Go Programming Language》第七章『接口（Interfaces）』的核心内容，总结成 5-7 个关键要点，用 bullet points 形式列出。”
  • “我正在阅读 TGPL 关于『并发（Concurrency）』的部分，特别是 goroutine 和 channel。请提取这段内容中关于『select 语句』的主要用途和注意事项。”
  • （重要提示） AI 的总结是草稿，你必须用自己的理解去审核、修改、重写和完善，将信息转化为你自己的知识结构。

• 笔记结构化建议：

  • “我正在为《The Go Programming Language》的第五章『函数（Functions）』做笔记，请给我建议 2-3 种不同的笔记组织结构，例如概念分类、按重要性排序、或者 Q&A 形式。”

• 快速原型代码：

  • “根据 TGPL 中关于『方法（Methods）』的讨论，特别是嵌入（embedding）和方法集（method sets）的概念，请给我生成一个简单的 Go 代码示例，演示结构体嵌入后方法的调用规则。”
  • “请基于 TGPL 中对 go test 工具的介绍，给我生成一个包含基本测试函数、基准测试函数（benchmark）和示例函数（example）的简单 Go测试文件模板。”

AI在这里的作用，不是替代思考，而是将我们从一些相对重复、机械性的信息整理工作中解放出来，让我们能将宝贵的认知资源更集中地用于深度理解、批判性思考、知识关联和创造性应用上，这一点与“AI会写Go代码了，初学者还需要系统学习吗？”一文观点异曲同工。

心法五：学以致用，输出倒逼

阅读只是输入，真正的内化需要输出和实践，这是一个需要长期坚持的过程：

• 实践应用： 在项目中应用所学知识。
• 分享与教学： 写文章、做分享，输出是最好的学习。这也是我的实践精华。
• 参与讨论： 与他人交流碰撞思想。
• 持续回顾： 温故而知新。

我的做法： 我长期坚持在tonybai.com博客进行输出，这是我奉行长期主义、内化知识最重要的方式之一。 把学到的东西用自己的理解讲出来、写出来，这个过程本身就是对知识体系最好的锤炼和检验。同时，在星球里回答大家的提问，也是在不断地进行知识输出和巩固。没有输出的阅读，效果终将有限。

小结：拥抱工具，以我为主，终身学习

高效阅读技术书籍，是一项可以通过刻意练习而不断提升的技能。在 AI 时代，我们拥有了强大的工具来辅助我们攻克难关、整理信息。但请始终牢记，AI 是我们的“协处理器”和“智能拐杖”，思考和理解的主体，永远是我们自己。

找到适合自己的节奏，在关键环节善用AI的辅助，保持耐心和好奇心，将阅读视为一场需要长期投入的修行。

如果你希望将阅读和实践更紧密地结合起来，系统性地提升Go语言能力，并探索Go与AI的结合：

• 我把我多年 Go 语言实践和思考的精华，沉淀在了 《Go语言精进之路》 这本书中，它侧重于连接理论与实践，希望能为你打通 Go 语言学习的“任督二脉”。

• 同时，在我的知识星球 「Go & AI 精进营」 中，我开设了像 【Go进阶课】 这样覆盖语法强化、设计先行与工程实践的体系化课程，并提供深度的 专家答疑 和活跃的 社区交流。我们一起学习，一起实践，一起拥抱 Go 和 AI 的未来。

【世界读书日 · 特别福利】点赞 + 留言 + 在看，赢取签名版《Go语言精进之路》！

为了感谢大家一直以来的支持，并响应世界读书日的精神，鼓励大家在阅读与实践的道路上不断精进，我特别准备了一个【世界读书日专属福利】活动！参加门槛很低，大家只需移步到我的公众号同名文章下点赞 + 留言 + 在看，我将结合留言内容的质量与【在看】情况，从参与本次活动的读者中，抽取1位幸运儿赠送一本由我亲笔签名的《Go语言精进之路》(卷1或卷2随机)！获奖名单将在五一劳动节当天公布，获奖读者请在名单公布后的 48 小时内，主动通过公众号后台联系我，并提供准确的邮寄信息，以便我将签名版书籍寄送给您。

活动时间：即刻起 – 2025年04月30日23:59。

期待大家的踊跃参与和精彩分享！ 让我们在阅读与交流中，共同进步！

希望今天分享的这些心法和 AI 应用思路能对你有所启发。你有什么高效阅读技术书籍的独门秘诀？或者你觉得 AI 在学习中还能扮演哪些角色？欢迎在评论区留言交流！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。