本文永久链接 – https://tonybai.com/2025/12/18/escaping-java-bicycle-shed-is-go-the-pure-land

大家好，我是Tony Bai。

“如果每次我看到‘为什么不这么写？’这种针对完美代码的 PR 评论都能得到一分钱，我现在已经退休了。”

近日，一位在 r/golang 社区发帖的开发者发出了这样的咆哮。他受够了 Java 生态中那种无休止的、关于细枝末节的争论——也就是所谓的“自行车棚效应”(Bike Shedding)。他正在认真考虑转向 Go 语言。

但问题是，换一门语言，真的就能彻底摆脱人性的弱点，找到那份久违的“简单”与“高效”吗？

这篇帖子迅速引发了数百条评论的热议，并形成了一次关于团队文化、工程效率以及如何在代码审查中保持理性的深度反思。

---

科普小贴士：什么是“自行车棚效应” (Bike Shedding)？

这个概念源自帕金森定律。典故是：一个委员会在审批核电站计划时，对极其复杂的反应堆设计匆匆通过（因为太难懂，大家不敢轻易发言），却为了旁边自行车棚该漆成什么颜色而争论了一个小时（因为每个人都能懂，都想发表意见）。

在软件开发中，它特指团队在无关紧要的琐事（如代码风格、变量命名、语法糖）上浪费大量时间，而忽略了真正重要的系统设计和逻辑问题。

审视“自行车棚”—— 无效争论的代价

发帖人的痛苦，源于一种许多开发者都深有体会的经历：PR 被琐碎的个人偏好所劫持。

• 症状：代码逻辑正确、测试通过、符合规范。但审查者依然会问：“为什么不用 Optional.of(…).orElse(…) 而是用 if-else？”
• 潜台词：“如果是我的话，我会这么写。我要指出这一点，以显示我有在认真看代码，而且我很聪明。”
• 后果：
  • 时间浪费：为了一个不影响功能的改动，需要重新提交代码、等待 CI 跑完（在企业级 Java 项目中可能长达 20-30 分钟）、等待再次审查。
  • 士气低落：开发者感到自己的工作不被尊重，变成了为了满足审查者个人喜好而工作的“打字员”。

正如一位评论者尖锐指出的：“这不仅是语言问题，更是‘人’的问题。” 有些开发者倾向于过度工程化，为了使用设计模式而使用设计模式，而忽略了代码的实际价值。

Go 是解药吗？—— “强制统一”带来的自由

为什么发帖人认为 Go 是解药？因为 Go 的设计哲学确实在很大程度上抑制了“自行车棚”的滋生土壤。

1. 极简的语法与“唯一解”

Go 语言的设计哲学是“少即是多”。它没有 Optional，没有复杂的流式操作符，没有十种不同的方式来实现同一个功能。
一位资深 Gopher 指出：“在 Go 中，很少有人会争论‘为什么不这么写’，因为通常只有一种地道的写法。” gofmt 更是从根本上消灭了关于格式化的争论。

2. “Not Invented Here” vs. “Just Copy It”

Java 生态倾向于构建通用的、高度抽象的框架。而 Go 社区更推崇“复制一点代码胜过引入一点依赖”。这种文化鼓励简单、直接的实现，而不是过早的抽象。
评论区有人提到：“在 Go 中，如果你看到重复代码，你可能会选择容忍它；但在 Java 中，你会被要求抽象出一个通用的 Factory 模式。”

3. 工具链的胜利

Go 的工具链（lint, vet）非常强大且统一。如果一个问题可以通过静态分析发现，那就交给机器去阻止，而不是在 PR 中由人来指指点点。

硬币的另一面 —— Go 社区的“新自行车棚”

然而，逃离了 Java，就能彻底摆脱“自行车棚”吗？社区的声音并非一边倒。Go 并不是没有任何争论的乌托邦。

• 新的争论点：虽然不再争论 Optional，但 Go 社区也有自己的“圣战”：
  • “为什么你要用这个第三方库？标准库不够好吗？”
  • “这个 struct 应该放在 pkg 目录下吗？”
  • “为什么你要定义这个接口？让消费者去定义！”
• 过度的“地道”追求：有时，对“Idiomatic Go”（地道 Go 代码）的追求也会演变成一种教条主义。一位评论者分享了自己的经历：仅仅因为不想在代码中看到哪怕一点点“Java 味”，审查者就拒绝了一个完美运行的 PR。

由此看来，Go 虽然减少了语法的复杂性，从而减少了语法层面的争论空间，但它也无法消除人类对于微小差异的执着。

给所有团队的“防杠指南”

无论你使用 Java 还是 Go，如何建立一个健康的 Code Review 文化才是根本。社区贡献了许多极具价值的建议：

1. 区分“阻塞”与“建议”：引入明确的前缀，如 nit: (吹毛求疵，不阻塞合并)、suggestion: (建议，可不采纳)、blocker: (必须修改)。这能清晰地传达审查者的意图。
2. 自己动手，丰衣足食：如果审查者对某个非功能性的风格问题非常在意，且有权限，不妨直接提交一个小改动，而不是阻碍原作者的 PR。
3. 规则自动化：凡是能用 Linter (如 Checkstyle, golangci-lint) 解决的问题，绝不在人工审查中讨论。让机器做坏人。
4. 接受“足够好”：Code Review 的目标是保证代码质量、发现 Bug 和分享知识，而不是追求“完美”。完美是完成的敌人。

小结：选择语言，更是选择文化

回到标题的问题：Go 是开发者的净土或避风港吗？是，也不是。

它确实通过强制的规范和极简的设计，消灭了许多“低级”的自行车棚，提供了一种更务实、更直接的编程体验。

但在任何有人的地方，争论都会寻找新的出口。如果你厌倦了 Java 的复杂，Go 绝对值得尝试；但请记得，真正的避风港不在语言里，而在一个成熟、理性、相互尊重的团队文化中。

资料链接：https://www.reddit.com/r/golang/comments/1pechqt/who_else_has_or_wants_to_move_from_java_to_go/

吐槽时间

“自行车棚效应”恐怕是每个程序员心中的痛。你在代码审查中遇到过最离谱、最让你抓狂的“自行车棚”争论是什么？是关于一个变量名，还是一个缩进？

欢迎在评论区吐吐槽，让我们一起把这些“无效卷”晒在阳光下！

如果这篇文章说出了你的心声，别忘了点个【赞】和【在看】，并转发给你的团队（也许能改变点什么）！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

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

本文永久链接 – https://tonybai.com/2025/11/29/oop-the-worst-thing-that-happened-to-programming

大家好，我是Tony Bai。

Erlang 之父 Joe Armstrong 曾提出了一个关于面向对象编程（OOP）的、流传甚广的深刻比喻：

“你想要一根香蕉，但你得到的却是一只拿着香蕉的猴子，以及整片丛林。”

这个比喻辛辣地讽刺了 OOP 中继承（Inheritance）等机制带来的强耦合与不必要的复杂性。近日，一篇由 Alexander Danilov 撰写的、题为《OOP：编程史上发生的最糟糕的事》的文章，则以一种更系统、更“檄文”式的方式，为我们详细解剖了这只“猴子”和这片“丛林”的构成。

Danilov 的文章，如同一份详细的“丛林勘探报告”，迫使我们重新审视，我们最初只是想要的那根香蕉（代码复用），是如何让我们不知不觉地，深陷于一片由类、继承和“魔法”构成的、盘根错节的“优雅”陷阱之中的。

想要香蕉，却来了只猴子 (继承的“原罪”)

故事始于一个最简单的愿望：代码复用。Danilov 在文章中展示了一个典型的场景：我们有一个 User 类，现在想创建一个 Npc（非玩家角色），它也需要 User 的 name 和 surname 字段。

在 OOP 的世界里，最“优雅”的做法就是继承。

// OOP - Inheritance (Danilov's example)
class User {
  id: string
  name: string
  surname: string
  address: string
  friends: User[]
  // ... a dozen other fields and methods ...
}

// “优雅"的陷阱：为了得到 name 和 surname (香蕉)，
// 我们被迫继承了 User 的全部 (猴子)
class Npc extends User {
  constructor(name: string, surname: string) {
    // 我们被迫为那些根本不需要的字段提供空值
    super(name, surname, "", [])
  }
}

我们成功地拿到了香蕉，但代价是，我们必须同时领养一只我们不想要的猴子——User 的所有其他字段和方法，如 address, friends 等。这只猴子不仅增加了我们代码的认知负荷，更在内存中占用了不必要的空间。

Danilov 指出，与之相对，函数式/组合式的思路则要直接得多：

// FP/Composition
type BaseUser = { id: string; name: string; surname: string }
type User = BaseUser & { address: string; friendIds: string[] }
type Npc = BaseUser // Npc 只是 BaseUser 的一个别名

通过组合而非继承，我们可以像搭乐高积木一样，精确地选择自己需要的“零件”（香蕉），而不会被迫带上任何多余的“猴子”。

猴子带来了它的朋友们 (方法的强耦合)

Danilov 的批判并未止步于继承。他将矛头直指 OOP 的另一个核心——实例方法 (Instance Method)。他认为，一个实例方法，本质上就是一个被“绑架”了的函数，它的第一个参数被隐式地、硬编码地绑定到了一个特定的类实例 (this) 上。

这场“绑架”，直接导致了方法的可重用性极差。一个 User 类的 getDisplayName() 方法，无法被一个同样拥有 name 字段的 Dog 对象复用。方法与其所属的类（猴子）形成了不可分割的共生关系。

更糟糕的是，Danilov 还展示了 OOP 语言为了管理这种绑定关系而发明的、迷宫般复杂的重写 (Override) 规则（如 C# 中的 virtual, override, sealed），他讽刺道：“想出这个的人，显然觉得 OOP 中‘搬起石头砸自己脚’的方法还不够多。”

为了管理猴群，我们建了座丛林 (设计模式与 DI 容器)

当我们的代码库里充满了各种各样的猴子（类），它们之间有着复杂的亲缘关系（继承链）和社交网络（依赖关系）时，事情开始失控。于是，为了“优雅”地管理这群日益庞大的猴子，我们开始建造一座丛林。

Danilov 对这座“丛林”的构成进行了无情的剖析：

• 设计模式 (Design Patterns)：他认为，绝大多数 GoF 的设计模式，都并非普适的智慧，而只是在 OOP 的种种限制下，为了实现本应简单的功能而发明的、复杂的“变通方案” 或“拐杖”。例如，“装饰器模式”就是为了在无法使用继承时，动态地为对象添加功能。

• 依赖注入容器 (DI Containers)：这是丛林里最“魔法”的部分。Danilov 回忆起他第一次面试 C# 时遇到的那段“童年阴影”代码，其中一个类的实例，通过静态构造函数和静态字段“自我创建”。他当时就感到困惑：“人类的大脑是如何以及为何会想出这种东西？” 后来他才明白，这只是通往 DI 容器“更深层魔法”的第一步。当一个 @Service 或 @Inject 注解就能让一个实例“凭空出现”时，你就失去了对程序启动和依赖关系最宝贵的洞察力——可预测性。当系统出错时，我们如同在伸手不见五指的丛林里，根本不知道那根有毒的香蕉，究竟是从哪棵树上掉下来的。

走出丛林 —— Go 语言的“反叛”与“重构”

在这场关于“香蕉、猴子与丛林”的寓言中，Go 语言扮演了一个“破局者”的角色。Danilov 在文章的最后，也将 Go 列为值得推荐的现代语言之一，正是因为它在设计上，系统性地回应并解决了 OOP 的诸多“原罪”。

Go 的方式并非简单粗暴地全盘否定，而是一种深刻的“反叛”与“重构”：它保留了 OOP 中部分有价值的表象（如 . 点号调用），却在底层彻底重构了其实现哲学。

没有继承，只有组合：直接砍掉“猴子”

这是 Go 最彻底的“反叛”。Go 完全废除了类型间的继承。取而代之的是更灵活的结构体嵌入 (Embedding)。你可以将一个 Nameable 结构体（香蕉）嵌入到 User 和 Npc 中，精确地实现复用，而不会被迫带上任何多余的“猴子”。这正是“组合优于继承”原则在语言层面的终极体现。

没有类，但有方法：将“被绑架的函数”解放出来

Go 确实有方法 (Method)。然而，Go 的方法与 OOP 的实例方法，在哲学上有着根本性的不同。

• 在 OOP 中，方法是类定义的一部分，与数据紧密耦合。
• 在 Go 中，方法是通过 func (receiver T) MethodName() 的语法，“附加”到一个类型上的。数据 (struct) 和行为 (func) 在定义上是分离的。

这种“分离”的设计，使得 Go 的方法更像是一个以 receiver 作为第一个参数的、被赋予了特殊“点号调用”语法糖的普通函数。

它巧妙地实现了“两全其美”：

• 保留了便利性：我们依然可以写出 user.GetDisplayName() 这样符合直觉的代码。
• 获得了灵活性：由于底层仍是函数，它鼓励我们思考更通用的、基于接口而非具体类型的解决方案，从而避免了 OOP 方法的强耦合问题。

隐式的、非侵入式的接口：重新定义“多态”

Go 的接口设计，是对传统 OOP 接口（如 Java 的 implements）的一次彻底革命。

• 在传统 OOP 中，一个类必须在定义时就明确声明它要实现哪个接口。这是一种侵入式的、预先绑定的关系。
• 在 Go 中，接口的实现是隐式的、非侵入式的。任何类型，只要它拥有一个接口所要求的所有方法，它就自动地、在事后满足了这个接口。

这种设计带来了巨大的灵活性，使得我们可以为任何（甚至是来自第三方库的）类型，定义我们自己的接口，而无需修改其源代码。这是对“依赖倒置原则”的终极实践。

拒绝“魔法”，拥抱显式

Danilov 所批判的 DI 容器和各种“魔法”，在 Go 的世界里几乎没有生存的土壤。

Go 的依赖管理就是简单的 import。一个包的 API，就是它导出的所有函数、类型和变量。一切都是显式的、可被静态分析的，没有注解驱动的“自动装配”，也就没有了那片需要“魔法”才能导航的丛林。

Danilov 引用了 Java 之父 James Gosling “后悔加入类”的传闻，以及 Linus Torvalds 禁止在 Linux 内核中使用 C++ 的决定，来佐证他的观点。而 Go 语言，似乎正是这些“巨人”反思的结晶。

Go 语言并非简单地回归到 C 语言那样的纯粹过程式编程。它更像是一位高明的外科医生，精准地解剖了 OOP 这具“巨人”的尸体，剔除了其中已经腐坏的组织（如继承），重构并解放了其依然有活力的器官（如方法和接口），最终创造出了一个更简单、更健壮、也更符合现代工程实践的新物种。

小结：简单，才是终极的优雅

Danilov 的文章，以一种辛辣而深刻的方式，揭示了 OOP 所承诺的“优雅”，在数十年的实践中，是如何常常演变成一个诱人的陷阱。它以“模拟现实世界”为名，引导我们构建起复杂的继承体系和对象网络，最终将我们自己困在了这片由“香蕉、猴子和丛林”组成的、难以维护的复杂性之中。

而 Go 语言的故事，则是一个关于“回归”的故事。它没有试图发明更聪明的“魔法”来隐藏复杂性，而是选择从根源上消除复杂性。

它提醒我们，真正的优雅，并非来自于那些能够驾驭复杂丛林的精巧工具，而是来自于从一开始，就选择不走进那片丛林的智慧。

资料链接：https://alexanderdanilov.dev/en/articles/oop

聊聊你的“OOP”爱恨情仇：

• 你是否也在项目中遇到过“香蕉、猴子和整片丛林”的困境？
• 你认为OOP在哪些场景下依然是“最优解”？
• 对于像Go/Rust等新一代编程语言的“反叛”与“重构”，你有哪些认同或不同的看法？

欢迎在评论区留下你的思考与争鸣，让我们一起探寻更优雅的编程之道！

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

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