Gopher - Tony Bai

本文永久链接 – https://tonybai.com/2025/09/30/good-taste-in-software-engineering

大家好，我是Tony Bai。

在软件工程领域，我们习惯于用“技术能力”（Technical Skill）来衡量一位工程师的优劣。他是否精通并发模型？能否写出高性能的代码？对底层原理的理解有多深？这些能力可以通过学习和重复练习来获得，是我们评价体系中的“硬通货”。

然而，github工程师Sean Goedecke在他最新的博文中，提出了一个新的观点：决定工程师成长上限的是“技术品味”（Technical Taste）。他认为，“品味”与“能力”是两个正交的维度。你可以技术能力很强，但品味很差；也可以技术尚在发展，但已具备良好的品味。就像一个美食家，即使自己不会烹饪，也能分辨出食物的好坏。同样，一个有品味的工程师，在能亲手构建一个复杂系统之前，就已经知道自己喜欢什么样的软件。在文章中，他还特意以Go的一些语法特性举例，来诠释什么是工程品味。

在这篇文章中，我们将一起拆解“技术品味”这个看似玄妙的概念，学习如何识别自己和他人身上的“坏品味”（比如对“最佳实践”的盲从），并探索一条培养“好品味”的实践路径，帮助我们Go开发者在日常的权衡与决策中，做出更成熟的选择。

“品味”不是“对错”，而是“价值观”的排序

文章以一个经典的例子开场：for循环 vs. map/filter。

许多来自函数式编程背景的开发者会认为，使用map/filter的代码“看起来更美”，因为它们通常涉及纯函数，易于推理，还能避免一类的迭代器bug。这似乎是一个关乎“正确”与“错误”的技术问题。

然而，Go语言的设计者们，出于“有原则的理由”，并没有在语言核心中原生内置map/filter。在Go中，一个简单的for循环：

性能上更易于推理：没有高阶函数调用的开销。
更灵活：可以轻松扩展到更复杂的迭代策略（如一次处理两个或多个元素）。

这个分歧的本质是什么？Goedecke一针见血地指出：这不是一个关于技术能力高低的争论，而是一个关于“工程价值观”（Engineering Values）优先级排序的差异。

偏爱map/filter的工程师，可能将“表达力”和“数学上的优雅”排在了更高的位置。
偏爱for循环的Go语言设计者们，则将“性能透明度”和“实现的直接性”置于首位。

成熟的工程师，能够理解并承认这种差异源于价值观的不同，而非技能的缺失。

什么是工程中的“好品味”？

几乎所有软件工程决策都是一次权衡（tradeoff）。

你很少能在两个选项中找到一个绝对更优的。你总是在不同的工程价值观之间做艰难的取舍，比如在“性能”和“可读性”之间，或者在“开发速度”和“正确性”之间。

不成熟的工程师会固执己见，认为“X永远比Y好”。而成熟的工程师则会评估双方的优劣，并思考：“在当前这个特定的项目中，X的收益是否大于Y的收益？”

因此，Goedecke对“技术品味”给出了一个精辟的定义：

Taste is the ability to adopt the set of engineering values that fit your current project.
(品味，是为当前项目选择一套恰如其分的工程价值观的能力。)

你的个人技术偏好，构成了你的基础“品味”。而“好品味”，则是在这个基础上，根据项目所处的真实环境（团队能力、业务阶段、性能要求、交付压力等），灵活调整你的价值观优先级的能力。

如何识别“坏品味”？—— “最佳实践”的诅咒

“坏品味”最常见的表现形式，就是僵化（inflexibility）。

I will always distrust engineers who justify decisions by saying “it’s best practice”.
(我永远不信任那些用“这是最佳实践”来为决策辩护的工程师。)

没有任何工程决策是在所有情境下的“最佳实践”。

当你听到有人用这个词时，往往意味着他正在将过去某个项目的成功经验（那套当时恰好适用的价值观），僵化地、不加思考地套用到一个全新的问题上。

一个在金融科技公司追求“五个九”可用性的工程师，如果将同样的价值观带到一个需要快速迭代验证想法的初创公司，坚持为内部仪表盘构建跨区域部署，那就是“坏品味”。这会让项目变得复杂无比，难以理解，拖慢了产品发布的速度，甚至导致了失去市场的机会。
一个习惯于用Ruby元编程“炫技”的开发者，如果在一个追求长期可维护性的Go项目中，滥用reflect来实现类似的动态能力，那也是“坏品味”。

Goedecke用了一个绝妙的比喻：品味差的工程师就像一块坏掉的指南针。在一块特定的磁场里（比如他之前工作的领域），这块坏指南针可能恰好能指向北方，让他看起来非常高效。但一旦环境变化（换了项目或公司），这块指南针就会立刻将团队引向错误的方向。

如何培养“好品味”？—— 拥抱灵活性与真实世界

培养技术能力有明确的路径：读书、练习、看代码。而培养“技术品味”则更为神秘。Goedecke给出的建议是：

涉猎多样化的项目：在不同类型、不同阶段、不同需求的项目中工作。密切关注在这些项目中，哪些部分做起来很“容易”，哪些又异常“艰难”。
聚焦于灵活性：刻意避免形成关于“编写软件的唯一正确方式”的强烈、普适性的观点。始终保持开放，愿意倾听和理解那些与你价值观相悖的观点。
拥抱真实世界的混乱：“好品味”无法在玩具问题或技术问答中得到检验。你必须投身于一个真实的、充满了各种混乱约束的实际问题中，才能锻炼你在多重约束下做出最佳权衡的能力。

小结：从理解“品味”，到成为更好的Gopher

综上所述，Sean Goedecke为我们揭示了一个深刻的层次：“技术品味”是超越“技术能力”的、衡量工程师成熟度的关键标尺。 文章的核心不在于掌握多少工具，而在于面对具体问题时，能否为之匹配一套恰如其分的工程价值观。这正是成熟与僵化、权衡与教条、情境与普适之间的分水岭。一个工程师的成长上限，或许就取决于他/她能否从固守个人偏好，进化到为项目选择最佳价值排序的“好品味”阶段。

这套关于“品味”的哲学，在Go的语境中显得尤为贴切，甚至可以说，它完美地解释了Go语言及其社区文化的形成。

Go语言本身，就是其设计者们“好品味”的结晶。他们没有盲目追随当时其他语言的风潮，而是为“构建大型、可维护的网络服务”这一特定问题，选择了一套恰如其分的工程价值观——将简单性、可读性和性能透明度置于极高的优先级。

这门语言的设计，反过来也在塑造着我们的“品味”。它通过“做减法”，有意地减少了语言的“魔法”，迫使开发者回归到问题的本质，进行更多的第一性原理思考，而不是依赖于复杂的框架或语法糖。在Go社区所推崇的“务实主义”、“显式优于隐式”，以及对“最佳实践”的天然警惕，本质上都是一种对情境化“好品味”的追求。

只有理解了为什么Go是现在这个样子，我们才能在使用这门语言时，做出同样充满“品味”的、与项目需求相匹配的决策，从而真正发挥出Go语言的全部威力，成为一名真正成熟的软件工程师。

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

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

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

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

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

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

本文永久链接 – https://tonybai.com/2025/09/26/self-reliant-programmer

大家好，我是Tony Bai。

“当代多数软件，对其用户而言是一种耻辱。”

最近，一篇措辞激烈、观点鲜明的《自立程序员宣言》（Self-Reliant Programmer Manifesto）在技术圈流传开来。它以一种近乎愤怒的姿态，抨击了现代软件开发中日益增长的复杂性、对臃肿工具的过度依赖以及脆弱的供应链。

对于许多沉浸在复杂框架和无尽工具链中的开发者来说，这份宣言可能显得有些“原教旨主义”。然而，在我们Go社区，当这篇文章被转发和讨论时，一种奇特的、会心一笑的共鸣油然而生。我们中的许多人看完后的第一反应是：“这不就是我们一直在说的Go语言哲学吗？”

这份宣言的核心呼吁——相信简单、最小化依赖、并勇于编写自己的工具——听起来就像是Go社区日常交流的“黑话”。

本文将和你一起解读这份“檄文”，并逐一印证，为什么它所倡导的“自立”之道，早已深深烙印在Go语言的DNA之中。

Go语言哲学：我们一直在坚持什么？

在解读宣言之前，让我们先回顾一下Go社区长期以来所珍视的一些核心价值观：

少即是多 (Less is exponentially more)：Go语言刻意保持规范的微小，避免引入带有额外认知负荷的特性。
清晰优于聪明 (Clear is better than clever)：代码首先是写给人读的，显式的错误处理、简单的控制流远比“魔法般”的语法糖更受推崇。
“自带电池” (Batteries Included)：一个强大的标准库，是我们抵御外部依赖泛滥的第一道，也是最重要的一道防线。
“一点复制胜过一点依赖” (A little copying is better than a little dependency)：这句社区谚语，体现了我们对引入新依赖的极度审慎。

现在，让我们带着这些“Go味十足”的理念，去看看《自立程序员宣言》都说了些什么。

宣言的核心法则 vs. Go的内在基因

法则一：“简单即是善” (Simple is good)

宣言说：“一切复杂的事物，都是由简单的东西构成的……你不需要四十二层抽象来实现一些简单的事情。”

这不就是我们所说的“少即是多”吗？ Go的设计哲学正是建立在对“简单性”的极致追求之上。它通过减少语言特性，来降低程序员的心智负担。当你在阅读一段Go代码时，你很少需要去猜测这段代码背后隐藏着什么复杂的继承链或元编程魔法。你所见即所得。

宣言强调：“理解事物的工作原理能帮助你建立更好的心智模型。” Go的显式错误处理 (if err != nil)虽然常被诟病冗长，但它强迫我们直面每一个可能出错的环节，而不是将其隐藏在try-catch的便利之下。这正是帮助我们建立健壮心智模型的绝佳实践。

法则二：“最小化依赖” (Minimises their dependencies)

宣言说：“更少的依赖意味着更少被包管理器的供应链攻击所伤害……更简单的代码意味着更好地理解你实际在使用的东西。”

这不就是我们“自带电池”和“一点复制胜过一点依赖”的实践吗？ Go强大的标准库，让我们在构建高性能Web服务、处理并发、加解密等无数场景下，都无需第一时间就去go get一个外部模块。

当确实需要外部功能时，社区文化也鼓励我们保持克制。与其为了一个简单的辅助函数就引入一个庞大的库及其数十个传递依赖，我们更倾向于将那几行代码直接复制到自己的项目中。这看似“原始”，却完美地践行了宣言的精神：完全掌控你自己的代码，并深刻理解它的每一行。

法则三：“编写自己的工具” (Writes their own tools)

宣言说：“更简单的工具意味着你可以独自工作……你无需依赖臃肿的CI、Docker、Kubernetes……”

这不就是Go语言被创造出来的核心目的之一吗？Go本身就是一门为构建工具和基础设施而生的语言。

静态编译与单二进制文件：go build产生的单一静态二进制文件，是分发和部署工具的终极形态。没有运行时依赖，没有复杂的安装脚本。
云原生世界的基石：Docker, Kubernetes, Terraform, Prometheus, etcd……这些定义了现代基础设施的工具，几乎无一例外都是用Go编写的。

我们Gopher不仅用Go构建应用，更用Go构建了我们赖以工作的整个世界。我们不满足于使用别人提供的、充满黑盒的工具，我们选择用我们自己的语言，为我们自己打造称手的兵器。这正是“自立程序员”精神的最高体现。