写代码顺手埋了个「彩蛋」！苹果工程师亲述：我差点被“炒”了

优快云资讯

于 2025-07-08 17:04:26 发布

阅读量6.4k

点赞数 27

CC 4.0 BY-SA版权

本文链接：https://blog.youkuaiyun.com/csdnnews/article/details/149209542

不同的程序员在写代码时总有些独特的习惯和小癖好。有人追求代码的极致严谨和规范，有人热衷于将逻辑压缩得干净利落，有人喜欢在注释里加几句自嘲或者冷笑话，也有人走上了更“文艺”的路线——在代码中悄悄藏下一些只属于自己的小彩蛋。

只是这些看似无害的“个性表达”，有时候也会踩到大公司的“雷点”。

John Calhoun 就是这样一个例子。他早年因开发 Mac 平台上的独立游戏（如 Glider）而小有名气，90 年代中期被苹果招募入职。刚进公司那会儿，他还带着点“独立开发者”的随性劲。有一天，他在系统的颜色选择器资源的里，藏下了 T.S. Eliot 的一段诗句，作为彩蛋埋在代码里。

没想到，这个看似浪漫的小动作，差点让他丢掉工作，也把他自己推上了“见高层、等处分”的边缘。那是他第一次差点被苹果解雇，成了他二十多年职场生涯里，始终记得的一课。

随着他将自己这次《The First Time I Was Almost Fired From Apple》（我第一次差点被苹果解雇）的经历分享出来，也引发了巨大的讨论：程序员在写代码时，到底能“玩”到什么程度？那些藏在代码深处的“彩蛋”，到底是个性表达，还是一场风险操作？

接下来，我们不妨先看看发生在 John Calhoun 身上的真实经历。

原文链接：https://www.engineersneedart.com/blog/almostfired/almostfired.html

作者 | John Calhoun 编译 | 苏宓

出品 | 优快云（ID：优快云news）

1995 年 10 月，John Calhoun 被苹果录用。

那时正值苹果最艰难的时期之一。他回忆道——当时的苹果公司处于“在下水道边缘打转”的阶段——外界媒体唱衰不断，坊间也频频传出“苹果快要倒闭”的猜测。在这样的背景下，苹果依然在招聘新工程师，多少显得有些反常。

但这家公司逻辑大概是：虽然公司摇摇欲坠，但还是得找个「图形工程师」来继续维护 QuickDraw GX 这个图形技术。

说起来，这个技术是苹果公司在 1990 年代初期推出的一项图形系统技术，意图作为原有 QuickDraw 图形引擎的“下一代替代品”。不过，它最终并没有成功推广，被称为苹果历史上“短命而先进”的技术之一，当然这些都是后话了。

彼时年仅 31 岁的 Calhoun，是一名为苹果 Macintosh 设备写游戏的独立程序员。或许正因为这层背景，苹果认为他是个合适的人选。

当惯了自由开发者，Calhoun 首次参加苹果公司的面试时，感受到了前所未有的职业氛围，好在他还是幸运地拿到了 offer，正式成为 Apple Computer, Inc. 的一名 QuickdrawGX 图形工程师。

紧接着，他带着女朋友、所有家当和两只猫，从美国的堪萨斯搬到了苹果公司所在的加州。对他来说，这不仅仅是一次搬家，更是一次彻底的生活转轨。很快他意识到，自己在这份新工作中需要学习的不只是技术，还有真正意义上的“职场专业性”。

在苹果公司初来乍到，他甚至一度怀疑自己是否胜任这份工作——苹果的工程师们不仅聪明，还极富专业精神，而他则像个刚跳进深水区、手脚乱划的新手。

不过，大约半年后，Calhoun 逐渐进入状态，开始适应节奏，能够踏实地推进自己的任务。但正如他自己所说的那样，离“职场成熟人士”还差得远，怎么看都还是个毛手毛脚的乡下程序员，和所谓的“专业大公司范儿”格格不入。

他最初参与的 QuickdrawGX 项目在他入职不久后就宣告失败，随后他被调到另一个叫做 ColorSync 的团队，并接手了一个新任务：将苹果标准颜色选择器（Color Picker）从老旧的 Motorola 68K 处理器迁移到更快的 PowerPC（PPC）平台上。

颜色选择器的迁移

苹果的这个颜色选择器其实是个模块化设计，里面包括两种配色器：一种是 HSL（色相、饱和度、亮度），另一种是 RGB（三原色）。

尤其是 HSL 那一块，原来是用汇编语言写的，能做到用户一边拉“亮度”滑块，颜色轮一边实时渲染，性能非常高效。简单解释一下，汇编是一种非常贴近硬件底层的编程语言，针对特定芯片写的——而这段代码就是为 Motorola 68K 芯片量身定做的。

所以，想在 PPC 上运行，就得把这些汇编代码“清理”出去，换成别的写法。

对刚加入苹果不久的 John Calhoun 来说，这项任务毫无疑问是个“下马威”。毕竟，他之前从未接触过汇编语言。用他自己的比喻来说，这感觉就像拿到一本中文书，却被要求翻译成英文——前提是你根本不会中文。

尽管如此，Calhoun 还是咬牙啃下了这项任务。他用熟悉的 C 语言重写了原有汇编逻辑，成功在 PPC 芯片上跑出了 HSL 色彩轮。

Calhoun 在博客中写道：

要说把这个项目交给我，是因为大家都看好我，那也太天真了。其实就是没人愿意干，刚来那小子正好就可以“安排”上了。是不是有点“甩锅”的味道？也许吧，但这种事在公司里并不稀奇。

不过对此 Calhoun 也并不介意，反而从这些没人争的项目里，找到了一些属于自己的成就感。

在接手颜色选择器的过程中，他还遇到不少新概念，比如大量 callback 回调机制——起初完全看不懂。为了避免不小心破坏原有代码的逻辑，他干脆决定自己从头写一个颜色选择器。与其硬啃别人写的代码，不如亲手造一遍轮子，这样反而更容易理解整体流程。就像学中文最有效的方式，是直接去中国住一阵，通过“沉浸式”学习语言。

就其个人喜好而言，Calhoun 坦言，自己并不喜欢 HSL 模型，而更习惯使用 HSV（色相、饱和度、明度），这在做美术工作时对他来说更直观。所以他把编写一个 HSV 配色器也加进了自己的“待办列表”中。

HSV 颜色选择器

当他把自己的颜色选择器写出来、运行起来后，发现这事其实还挺好玩的。可能正因为有点上头，Calhoun 又动手写了一个新的配色器。

那时候，万维网（www）刚开始火起来，于是他自然地想到：做一个 HTML 配色器应该挺有意义的。这个配色器基本还是基于 RGB，但数值是用十六进制表示的，比如 “#FFCC33” 这样的格式，方便网页设计师直接复制使用。

HTML 配色器

没过多久，他又写了一个“蜡笔配色器”。此时，Color Picker 项目已经基本完成，Calhoun 称，自己对它也算是摸透了。“后面这些配色器，纯粹就是我玩得起劲，顺手加的。”

Calhoun 写的蜡笔配色器，有 60 支蜡笔可选。原始颜色和当前选择颜色会以涂鸦形式展示，带点随机效果。第一排是棕色、冷暖灰色；第二排是饱和度很高的纯色；后面几排颜色越来越淡；最后一排全是中性色的灰。

为了规避法律风险，Calhoun 还特意查了蜡笔调色板的商标版权相关问题。得出的结论是，“Crayola”是注册商标（美国著名的蜡笔制造商品牌），蜡笔尾部的波浪纹图案也可能受保护，所以他干脆换了名字和设计，确保可以正常上线。

Calhoun 表示，他喜欢那个年代的苹果公司，因为“工程师才是掌舵人”。他之所以写 HSV 颜色选择器，是因为觉得它对艺术创作者更友好；写 HTML 颜色选择器，是因为 Web 的发展让它变得有用；而蜡笔选择器，完全是出于一种本能的判断——苹果的产品应该让“普通人”也能感受到乐趣与亲近。HSL 和 RGB 是工程师的世界，而蜡笔，则是我们大多数人从小接触颜色的方式。

令人惊喜的是，最终苹果竟然把他写的这些颜色选择器软件全部发布了。没有市场部来提需求，也没有设计部门审核功能是否“有商业价值”。但工程师们不仅是写代码的人，也是产品的用户，他们凭直觉知道哪些东西是 Mac 用户真正想要的。

至少对 Calhoun 而言，他只是把自己想要的工具，做出来了而已。

软件中埋下“彩蛋”引发争议

说到这儿，不得不提一件让 John Calhoun 至今记忆犹新的插曲——关于他亲手埋下的“彩蛋”。

在软件世界中，所谓“彩蛋”（Easter egg）指的是那些被悄悄藏在程序里的小惊喜、小幽默。在 Mac 社区，发现或分享一个彩蛋是一件非常有趣、甚至带点神秘感的事。而在苹果内部，这种文化更是活跃。

Calhoun 当时刚加入公司，身边正是那些曾参与彩蛋创作的老工程师，自然也萌生了一个念头：自己也想在代码里藏一个属于自己的彩蛋。

这个念头，最后几乎让他丢掉饭碗。

事后回想起来，他认为问题并不在于“做彩蛋”本身，而在于彩蛋的本质就是隐藏的、非公开的东西。那么，这类内容需要提前报备吗？还是“先做了再说”，事后解释求个原谅？他选择了一个折中的做法——跟几位同事打了声招呼，征询了一下意见。但显然，这一步做得还不够周全。

而这个让他差点惹祸上身的彩蛋，其实就是几行诗句，出自 T.S. 艾略特的名作《普鲁弗洛克的情歌》：

“我们在海的密室中徘徊，

由海藻缠绕的海之少女围绕身旁，

直到人声将我们唤醒，我们便沉入海底。”

Calhoun 把这段诗句拆分成几段，作为颜色选择器中多个资源项的名称使用。这些名称就像网页里图片的文件名一样，平时是不会直接呈现给用户看的。但如果有人深入查看颜色选择器的底层资源，就有可能偶然发现这些诗句。

而毫无疑问，后来确实有苹果内部人员在操作系统构建流程中检查字符串时，注意到了这段来自诗人 T.S. Eliot 的文字。

在 Calhoun 看来，这只是一个低调又克制的小彩蛋。他原以为这首诗已经进入公版领域，即便没有，三行引用按理说也应属“合理使用”。然而他忽视了一个关键事实：苹果对版权问题一向极为敏感。毕竟公司历史上曾多次因为知识产权问题惹上麻烦，而这一点他当时并没有真正意识到。

更大的问题在于，他在“大公司企业文化”这门课上仍属新手，不清楚在一家大型科技公司里做事的边界与规范。结果，出于一份纯粹的浪漫与无知，他差点在无意中把苹果即将发布的操作系统推向法律风险的边缘。

好在，万幸，这个“彩蛋”字符串在系统真正制作发行版光盘之前被及时发现，避免了更严重的后果。

被叫去办公室谈话

John Calhoun 已经记不清事情发生时的所有细节了。当时可能是他的经理先得到了消息，然后把他叫进办公室，告诉他闯了大祸。对于一位刚入职不久的员工来说，这无疑是一记重击。而这位经理的忧虑显然不止是 Calhoun 一人，他也很清楚，这种“任性操作”可能会连累整个团队，甚至影响到他本人。

最终，经理告知他需要与苹果的一位高层会面，这场会面将直接决定他是否还能继续留在公司。

虽然记忆模糊，但 Calhoun 当时心里非常清楚：他真的惹了大麻烦，饭碗恐怕难保了。

他确实见到了苹果负责操作系统项目的负责人——一个在苹果早期就小有名气的人物。据 Calhoun 回忆，这位高管常骑着一辆本田 Goldwing 摩托上下班，嘴里还叼着烟斗，是公司里少有的“老派角色”。

那次谈话的情景，Calhoun 至今记得。他被严厉训斥了一番，高管还告诉他，为了这段“诗意的彩蛋”，公司不得不销毁一批刻了操作系统的光盘，这无疑是一笔不小的损失。

Calhoun 试图解释，自己原以为不会涉及版权问题，但对方显然毫不买账。在几句无力的辩解之后，他索性认错，接受了即将到来的任何处罚。

这位高管还问过他对接下来结果的看法。Calhoun 坦言，自己也意识到工作可能保不住了。但他也明确表态：如果公司愿意给他一个机会，他保证今后绝不会再做出类似的愚蠢举动。

结果出乎意料——他留了下来。而且，这一干就是二十多年。不过这件事也成了他的“职场前车之鉴”，时不时用来告诫那些刚入职的新人：别太拿自己的“个性”当回事。从那天起，他在苹果的每一步都变得格外谨慎，时刻考虑着总部会如何解读他的行为，以及可能带来的影响——无论这些影响是有意为之还是意料之外。

Calhoun 表示，回头看，那一刻对他而言颇为羞耻。在苹果这样的大公司犯错，就像在社交场合里出丑，立马暴露出你成长环境的粗糙和不成熟。

这并不是他第一次在职场上体会“缺乏白领训练”的代价。还有一次，是入职几年后，经理问他为什么没有参与公司提供的 401(k) 退休计划。他一脸茫然：“那是什么？”后来才知道，原来入职第一天苹果安排了整天的新人培训，内容包括退休计划的介绍和如何从工资中扣款设置。但 Calhoun 那天直接跳过了培训，自顾自地跑到办公室报到。

其他彩蛋

尽管一度面临被解雇的风险，John Calhoun 最终还是留在了苹果。他自己也说不清这是为什么。也许苹果觉得没必要这么做，或者觉得人非圣贤，允许给新人一次犯错的机会，也有可能，是他的经理在关键时刻为他争取了一把——这一切至今仍是谜。

事实上，Color Picker 中除了那段被质疑的诗句，还藏着其他几个无伤大雅的彩蛋。比如在“蜡笔配色器”里，用户可以看到蜡笔随着时间推移而逐渐磨损甚至“断裂”。虽然这一视觉效果不会影响功能，但充满了童趣和细节感。每年圣诞节，所有蜡笔还会“自动重生”，仿佛刚换上了一整盒新的颜色。

另一个隐藏玩法，则是在特定操作下可以显示一些“彩蛋色名”——实际上是项目组成员名字的字母重组（即字谜）。Calhoun 只记得其中一个彩蛋名叫“I Born Short”。

他猜测，在那次“藏诗事件”之后，这些无害的小彩蛋也被一并撤下了。是否真的如此，他不敢断言，也许其他人会知道得更多。

不过后来的一些迹象表明，有些彩蛋其实还是悄悄被保留了下来。比如就有用户发现，颜色选择器里的蜡笔会随着时间推移慢慢“磨损”，像真的被用过一样。

程序员能否在代码中留“彩蛋”？

回顾 John Calhoun 的经历，一个本意纯粹、风格浪漫的彩蛋，差点酿成职业生涯的重大危机。

而在 Hacker News 上，许多开发者也分享了对“代码彩蛋”的看法。不少人认为，只要彩蛋无害、不影响功能，也不踩版权或合规的红线，它反而是代码世界里一丝幽默与人情味的体现。

有网友指出：

我觉得大众（这里也包括不少软件工程师）普遍高估了那种“一出大错就被炒鱿鱼”的概率——就像电影里演的那样。现实中，只要错误不是（1）出于恶意或蓄意，或者（2）明显暴露出你完全不胜任这份工作，那么通常不会直接导致被解雇。大多数“重大失误”，其实都出现在那些本意良好、技术扎实的工程师身上，只不过他们当时犯了一个真诚的错误而已。

从公司或管理层的角度，正确的做法不是立刻开除出错的人，而是让他们去修正问题（可能还需要别人的帮助）。而现实中，大多数公司确实也是这么做的。虽然也确实存在一些管理糟糕的公司会因此开人，但那应该是少数。

当然，也有人对此持更谨慎态度：

我从来不是彩蛋的忠实粉丝。从风险管理和质量保障（QA）的角度看：一个软件项目本来就有很多可能出错的地方，为什么还要特意加一个没人要求的东西？哪怕它只有 1% 的几率出问题，也未免太不值得了。因为一旦真的出故障，你还得写事故复盘报告，到时候你要怎么解释？

彩蛋，究竟是“多余的风险”，还是“程序员的浪漫”？可能每个团队、每家公司都有不同答案。而对每一个工程师来说，也许真正重要的不是彩蛋本身，而是清楚它出现在哪里、为什么存在、又可能带来什么后果。那么，你写过“彩蛋”吗？