本文永久链接 – https://tonybai.com/2025/08/31/the-simplest-thing-that-could-possibly-work

大家好，我是Tony Bai。

在我们解读了Github工程师Sean Goedecke关于“无聊即可靠”的系统设计和API设计理念之后，他再次带来了一篇精彩的的文章——《Do the simplest thing that could possibly work》。这既是对前两篇文章思想的延续，更是将其核心哲学提炼为一条终极黄金法则：在软件设计的每一个环节，都应“做可能奏效的最简单的事”。

这条法则，在今天这个充斥着“无限扩展”、“优雅分布式”、“完美分层”等宏大叙事的时代，显得尤为重要。Goedecke认为，工程师们最大的误区，就是试图一开始就设计出那个“理想”系统，而忽略了当下最核心的问题。

本文将继续和大家一起来深入剖析Goedecke这篇文章，领略其提出法则的真谛，探讨它如何帮助我们对抗软件工程中三大根深蒂固的敌人：对“大泥球”的恐惧、对“简单”的误解，以及对“未来扩展性”的过度痴迷。对于追求务实与高效的Go开发者来说，这套思想武器库，无疑是构建健壮、可维护系统的最佳指南。

核心法则：先深入理解，再做最简单的事

Goedecke的核心论点可以概括为两步：

1. 花时间去深度理解当前的系统和需求。
2. 然后，做那件能够解决当前问题的、最简单的事。

这与许多工程师的直觉相悖。我们总是被教导要“高瞻远瞩”，要设计一个能够应对未来各种可能性的“完美”架构。但Goedecke认为，这恰恰是通往失败的错误路径。

让我们以他文中的Go应用场景为例：为一个现有的Go服务添加限速功能。

• “理想系统”思维：马上想到引入Redis，实现一个精巧的“漏桶算法”，构建一套独立的、可水平扩展的速率限制微服务。这套方案技术上无懈可击，充满了“工程美感”。
• 作者的“极简工作法”思维：
  1. 最简单的一步是什么？ 检查一下我们正在使用的边缘代理（如Nginx, Envoy）是否已经内置了速率限制功能？也许只需要几行配置就能解决问题。
  2. 如果不行，次简单的一步是什么？ 能否在应用内存中维护一个计数器？“可是重启会丢失数据！”——那么，丢失这些数据对业务的实际影响是什么？真的那么致命吗？
  3. 如果还不行，再下一步呢？ 如果数据不能丢失，且服务是多实例部署，那么引入外部依赖（如Redis）才成为那个“能奏效的最简单的事”。

这个思考过程的精髓在于，它强迫我们不断地质问自己：“真的有必要吗？” 直到我们确认，更复杂的方案是解决当前真实存在的约束的唯一途径时，才去实施它。这正是极限编程中“YAGNI”（You Ain’t Gonna Need It）原则的终极体现。

“简单”的真谛：少即是多，平庸即伟大

一个普遍的现象是，初级工程师热衷于使用他们新学会的各种工具——数据库、缓存、消息队列、代理——来构建复杂的系统，并在白板上画出纵横交错的箭头，这让他们感觉像在做“真正的工程”。

然而，软件设计的精髓，如同武学大师的境界，在于学习何时做得更少，而非更多。

Goedecke指出，伟大的软件设计往往看起来平庸无奇（underwhelming）。它不会让你惊叹于其复杂精巧的结构。相反，当你面对一个伟大的设计时，你通常会感到惊讶：“哦，原来这个问题这么简单？”或者“太好了，我们实际上并不需要做那些复杂的事情。”

Unicorn web服务器是伟大的设计，因为它利用了Unix进程这一极其“无聊”但无比可靠的原语，就解决了请求隔离、水平扩展和崩溃恢复等核心问题。标准的Rails REST API是伟大的设计，因为它用最枯燥的方式，完美地满足了CRUD应用的需求。

对三大反对意见的深刻辩驳

当然，“做最简单的事”这一法则总会面临三个经典的质疑。Goedecke对这些质疑的回应，构成了文章最精彩的部分。

1. 反对意见一：“这难道不会导致‘大泥球’（Big Ball of Mud）吗？”

“做最简单的事”听起来像是鼓励走捷径、写“hack代码”。我们都见过那种由无数“hack”堆砌而成的、无法维护的“大泥球”系统。

Goedecke的反驳： “Hack”代码根本不简单！
- “Hack”只是“更容易想到”：一个临时的补丁或权宜之计，通常是我们能最快想到的方案，但这并不意味着它是最简单的。
- “Hack”增加了系统的认知负荷：每一个“hack”都为代码库引入了一个需要被“特殊记忆”的例外。随着“hack”的增多，系统的整体复杂性是在增加，而非减少。
- 真正的“简单”方案需要深度思考：找到一个正确的、优雅的修复方案，往往需要对系统有更深入的理解，并探索多种可能性。这个“正确的修复”通常比“hack”本身要简单得多。

结论：做“最简单的事”不是放弃工程，恰恰相反，它要求我们投入更多的精力去做真正的工程设计，以找到那个最根本、最简洁的解决方案，而不是用一个又一个复杂的“补丁”去掩盖问题。

2. 反对意见二：“‘简单’的定义是什么？这难道不是一个空洞的同义反复吗？”

如果“最简单”就等同于“好设计”，那么“做最简单的事”不就等于说“做好设计”这句废话吗？

Goedecke借鉴了Rich Hickey在著名演讲《Simple Made Easy》中的思想，对”简单“给出了一个直观的定义：

1. 更少的“活动部件”：一个简单的系统，是你需要同时思考的东西更少的系统。
2. 更低的内部耦合：一个简单的系统，是由具有清晰、直接接口的组件构成的。

基于这个定义，他给出了一个实用的决断法则：简单的系统更加稳定。

如果在两个方案之间抉择，一个方案在需求不变的情况下需要持续的维护、监控和干预（比如部署和维护一个Redis集群），而另一个则不需要，那么后者就是更简单的。

因此，对于Go的速率限制例子，内存方案比Redis方案更简单，因为它减少了外部依赖、监控需求和部署复杂性这些“活动部件”。

3. 反对意见三：“难道我们不应该构建可扩展（scalable）的系统吗？”

这是来自大型科技公司工程师最常见的呐喊：“内存限流根本无法扩展！”

Goedecke的反驳： 对“扩展性”的痴迷，是SaaS工程领域最大的原罪。

• 过早的扩展性设计通常是无效的：你无法准确预测一个非凡系统在流量增长几个数量级后，瓶颈会出现在哪里。为遥远的未来进行过度设计，往往是在解决一个根本不存在或被错误预测的问题。
• 过早的扩展性设计会使代码库僵化：为了所谓的“独立扩展”，你可能会过早地将一个单体服务拆分为多个微服务。这引入了网络通信、分布式事务等一系列极其困难的工程问题，使得实现某些功能变得异常艰难。“我见过很多次这种拆分，但真正从中受益的，可能只有一次。”
• 务实的扩展策略：最多为当前流量的2倍或5倍做准备。然后，保持系统的简单和灵活，以便在真正的瓶颈出现时，能够快速地识别和解决它。

在Go社区，我们经常看到关于“单体 vs 微服务”的讨论。Goedecke的观点为我们提供了清晰的指引：保持单体的简单性，直到拆分的必要性变得无可辩驳。 一个设计良好、简单的Go单体应用，其扩展能力远超大多数人的想象。

小结：拥抱当下，而不是预测未来

Goedecke在文末总结道，软件开发有两种基本方式：

1. 预测未来：预测半年或一年后的需求，并为此设计一个“最佳”系统。
2. 拥抱现在：为当前已知的、真实的需求，设计一个“最佳”系统。

他悲观地认为，我们人类作为一个集体，预测系统未来走向的能力非常有限。我们甚至很难完全理解一个系统当前的状态。因此，第一种方式往往导致糟糕的设计。

唯一的理性选择是第二种：做那个可能奏效的、最简单的事。

这要求我们放弃作为工程师的某种虚荣心，不再追求构建那些看起来“令人印象深刻”的复杂系统。相反，我们应该拥抱“无聊”，致力于创造那些看似平庸，却异常健壮、稳定且易于理解和修改的系统。

这，或许就是从“优秀”走向“卓越”的工程师，其设计哲学的终极奥义。

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

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

本文永久链接 – https://tonybai.com/2025/08/30/python-an-origin-story

大家好，我是Tony Bai。

在编程语言的星空中，很少有哪颗星像Python一样，以如此温和而坚定的姿态，从一个不起眼的个人项目，成长为照亮地球未来的科技灯塔。如今，当我们谈论数据科学、人工智能时，Python几乎是绕不开的默认选项。但这一切的起点，竟源于一位程序员在阿姆斯特丹的圣诞假期里，为了“打发时间”而开始的一个“私活”项目。

近期，一部名为《Python: The Documentary》的纪录片，通过对创始人Guido van Rossum及众多早期核心贡献者的访谈，为我们揭开了这段波澜壮阔的起源故事。这既是一部技术编年史，更是一部关于设计哲学、社区力量、时代机遇与人性光辉的启示录。

本文将沿着这部纪录片的脉络，和大家一起穿越回那个个人电脑尚不普及、Usenet是唯一交流渠道的年代，探寻和复盘Python成功的真正基因。

孕育：一次对“专家思维”的反叛

故事始于80年代的荷兰CWI（国家数学和计算机科学研究中心），一个诞生了Algol系列语言的学术圣地。当时，编程语言的设计理念被一种根深蒂固的经济关系所主导：计算机极其昂贵，而程序员相对廉价。因此，语言被设计得尽可能贴近硬件，以榨干机器的每一分性能，至于程序员需要花费多少时间去理解和编写，则在其次。

正是在这种背景下，CWI的ABC语言项目应运而生。项目成员Lambert Meertens在尝试向艺术家教授编程时发现，现有的语言充满了对底层硬件知识的隐式要求，这对非技术背景的人来说是一堵无法逾越的高墙。ABC的目标，就是创造一门“易学、易教、易用”的语言，让初学者无需关心“那些凌乱的硬件细节”。

Guido van Rossum，当时还是一名年轻的程序员，被雇佣来将ABC的原型实现为一个完整的系统。他在这门语言上投入了三年半的心血。然而，ABC生不逢时。在那个没有互联网的年代，分发软件需要邮寄软盘，ABC几乎没有触及到它的目标受众，并最终被CWI高层扼杀。

这次失败的经历，却在Guido心中埋下了一颗种子。

诞生：在C与Shell之间的“甜蜜点”

项目被砍后，Guido被调往一个名为Amoeba的分布式操作系统项目。他的任务是为这个系统编写大量的用户应用程序。他很快发现，使用C语言来完成这些任务极其痛苦和低效，而使用Shell脚本又缺乏足够的编程能力。

“天啊，如果我们能用ABC来写这些工具就好了，”Guido回忆道，“每个工具可能只需要半页代码，我几周就能搞定，而不是看起来要花上好几年。”

但他同样意识到，ABC过于抽象，它刻意回避了与文件系统、进程等操作系统底层交互的能力。此时，一个清晰的需求浮现了：市场需要一种能够弥合C语言的强大能力与Shell脚本的易用性之间鸿沟的语言。

当时，Perl是这个生态位的有力竞争者，但Guido和他的同事们并不欣赏它。“我们觉得它作为一门编程语言并不好，几乎和Basic一样糟糕，只是糟糕的方式不同。” 正是在这种“一个能打的都没有”的背景下，Guido做出了一个改变历史的决定。

1989年的圣诞假期，他没有选择休息，而是开始了自己的“私活”项目：创造一门属于自己的编程语言。

设计哲学：“禅”的雏形

Guido的新语言，自然地继承了ABC的许多思想遗产，其中最著名、也最具争议的，就是使用缩进来组织代码块。但他同样抛弃了ABC中那些他认为不切实际的部分，朝着更务实的方向前进。

更重要的是，Python从诞生之初就树立了一种与当时主流脚本语言Perl截然相反的哲学。Perl的座右铭是“条条大路通罗马”（There’s more than one way to do it），鼓励天马行空的语法和技巧。而Python则悄然确立了自己的核心原则：“应该有且最好只有一种显而易见的方法来做事”（There should be one– and preferably only one –obvious way to do it）。

这种对明确性（explicitness）和可读性（readability）的极致追求，后来被社区核心成员Tim Peters总结为著名的《The Zen of Python》。当人们困惑于Python的设计哲学时，Tim Peters用诗一般的语言给出了答案：

• Beautiful is better than ugly. (优美胜于丑陋)
• Explicit is better than implicit. (明了胜于晦涩)
• Simple is better than complex. (简洁胜于复杂)
• Readability counts. (可读性很重要)

这可不是什么漂亮的口号，而是真正指导Python语言演进的根本大法。一位科学家用户在纪录片中分享道：“我用Perl处理数据，一年后回来看代码，完全不知道自己写了什么。而Python的代码，一年后我依然能读懂。” 这正是Python设计哲学的胜利。

社区的黎明：从Usenet的21个碎片开始

当Guido将这个名为“Python”（源自他喜爱的喜剧团体“Monty Python”）的语言展示给ABC的同事时，并非所有人都表示欢迎。他的导师Lambert Meertens的第一反应是输入一行代码，让解释器崩溃了，这让Guido备受打击。但第二天，他就修复了这个问题。这种务实、快速迭代的风格，贯穿了Python的整个发展历程。

很快，Python在CWI内部吸引了第一批真正的用户，Sjoerd Visscher和Jack Jansen。他们成为了Guido最初的反馈来源，“你只需要对他喊一声‘嘿，Guido！’”。一个微小的、紧密的社区开始形成。

历史的关键转折点在于CWI的开明决定：他们允许Guido以开源的形式将Python发布到全世界。“他们不知道这会成为一个巨大的成功，这很好，”Guido笑着说，“如果他们知道了，他们可能会阻止，那它就永远不会成功了。”

在那个前互联网时代，发布软件是一项艰苦卓绝的任务。团队必须将源代码打包、压缩、转换成ASCII编码，再分割成21个符合Usenet帖子大小限制的碎块。用户则需要手动下载所有碎片，再反向执行所有步骤。然而，Guido充满诱惑力的“预告”吸引了足够多的早期信徒，他们不辞辛劳地完成了这套复杂的“解压”流程。很快，来自世界各地的邮件和Usenet帖子开始涌入，一个全球性的社区就此诞生。

成长与迁徙：从NIST车间到成为“仁慈的独裁者”

Python的早期发展离不开美国国家标准与技术研究院（NIST）的一群爱好者。他们组织了第一次Python研讨会，只有20人参加，在一个“没有窗户的政府办公楼”里。正是这次会议，奠定了Python社区开放、协作的基调，也催生了Guido著名的头衔——“仁慈的独裁者”（Benevolent Dictator for Life, BDFL）。

这个听起来有些戏谑的称号，精准地描述了Guido在社区中的角色：他欢迎所有人的想法，但保留对语言发展的最终决定权。这种模式在混乱的开源世界中提供了一种宝贵的稳定性和方向感，确保了Python在演进过程中没有因为无休止的争论而偏离其核心哲学。

随后，Guido移居美国，加入了CNRI（国家研究创新公司），这是他第一次可以全职投入到Python的开发中。在这里，他不仅获得了稳定的支持，还拥有了python.org域名，为社区建立了一个正式的家园。（一个有趣的插曲是，他们当时没有注册python.com，导致该域名多年来被一个成人网站占据。）

走向主流：科学计算与Web浪潮的双重助推

Python的崛起并非一帆风顺，而是踩中了数次技术浪潮的节拍。

• 科学计算社区的拥抱：最初，科学家们使用Perl或MATLAB等工具，但Perl代码难以维护，而MATLAB是昂贵的商业软件。Python凭借其开源属性、出色的可读性和通过C扩展实现高性能计算的能力，迅速赢得了科学计算领域的青睐。NumPy、SciPy等库的出现，为Python构建了坚实的护城河。Guido本人虽然不是科学家，但他对社区需求的开放态度，使得Python能够不断演进，满足这个群体的需求。

• 互联网泡沫与Web开发：2000年初，随着Web的兴起，开发者需要一种能够快速构建网络服务的语言。相比于Java的笨重和Perl的混乱，Python的“胶水语言”特性使其成为理想选择。Dropbox和YouTube等早期巨头的成功，雄辩地证明了Python在生产力上的巨大优势。Dropbox的创始人Drew Houston回忆道：“Google有一个百人C++团队在做视频网站，却始终追不上那个叫YouTube的小团队，后来他们发现，后者只有几个用Python的工程师。”

3.0之痛：一次差点撕裂社区的“大分裂”

当一门语言获得巨大成功后，如何处理历史包袱就成了一个棘手的问题。Python 2在Unicode和bytes处理上的混乱设计，成为了Guido心中的一根刺。2008年末，Python 3.0发布，这是一次不向后兼容的重大升级，旨在从根本上解决这些历史问题。

团队乐观地估计，社区只需要几年时间就能完成过渡。但他们严重低估了现实的阻力。对于拥有数百万行Python 2代码的公司（如Dropbox）来说，迁移成本是天文数字。许多核心库的维护者也迟迟不愿跟进，导致生态系统出现严重割裂。

这场“2 vs 3”的分裂持续了近十年，一度让社区陷入绝望。一些著名的开发者公开表示“不会迁移”，认为Python 3的收益不足以弥补其带来的痛苦。

最终，是时间、工具和榜样治愈了这场创伤。2to3、six等兼容库的出现降低了迁移门槛；Instagram等大型公司率先完成迁移并分享了性能提升的成功经验，给了社区巨大的信心；而Python 2.7在2020年正式停止支持，成为了压倒骆驼的最后一根稻草。

这场痛苦的经历给Guido和整个社区留下了深刻的教训：“Python可能已经太庞大了，再也无法承受一次这样的迁移。”如今，“永远不会有Python 4”已经成为社区的共识。

文化的胜利：Python的真正护城河

回顾Python的成功之路，语法和功能固然重要，但真正让它与众不同的，是其独特而强大的社区文化。

• 开放与包容：从Guido亲自指导一位毫无开源经验的女性开发者Mariatta Wijaya成为核心贡献者，到PyLadies社区的兴起，Python社区在推动多元化和包容性方面做出了巨大努力。这使得Python不仅仅吸引了传统的白人男性程序员，还吸引了来自不同背景、不同领域的广大人群。
• 幽默与人文关怀：从以“Monty Python”命名，到import this会打印出《The Zen of Python》，再到用“spam, spam, spam”作为会议T恤的口号，Python社区始终保持着一种轻松、幽默的氛围。这让参与开源不再是一件枯燥严肃的事情，而是一种有趣的社交活动。
• “我为语言而来，为社区而留”: 这是前PyCon主席Jesse Noller的名言，也是无数Python开发者的心声。PyCon不只是一个技术会议，更像一个大型的家庭聚会。人们在这里交流思想，结交朋友，共同塑造着这门语言的未来。

小结：一场精心策划的“意外”

Python的成功，是一系列因素的完美风暴。它诞生于一个恰当的时机，满足了市场对一种更人性化、更高生产力语言的渴求。它的设计哲学——简洁、明确、可读——被证明是应对大型项目和团队协作复杂性的最佳解药。它抓住了一次又一次的技术浪潮，从科学计算到Web开发，再到今天的人工智能。

但最重要的，是Guido van Rossum和整个社区所展现出的务实、开放和人文精神。他们愿意为了长远的目标而承受短期的痛苦（Python 3迁移），也愿意为了让社区更美好而不断反思和改进。

这个始于圣诞节的“私活”项目，最终没有成为又一个被遗忘在历史尘埃中的ABC。它活了下来，并茁壮成长，因为它不仅是一门优秀的编程语言，更是一个充满活力的、不断进化的生命体。它的故事，至今仍在激励着每一个开源世界的参与者。

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

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