本文永久链接 – https://tonybai.com/2025/09/08/fanren-xiuxian-programmer-levels

大家好，我是Tony Bai。

最近《凡人修仙传》的电视剧大火，想必各位道友都有耳闻。鄙人也没忍住，不仅刷完了杨洋主演的网剧，还趁着这股热乎劲儿，一口气在微信读书连读再听地补完了小说的人界篇。

当看到韩立资质平平，相貌普通，却凭着“小绿瓶”、远超常人的心智和不懈的努力，在残酷的修仙界中，历经炼气、筑基、结丹、元婴，终至化神时，我猛然拍案：

这不就是我们程序员升级打怪的真实写照吗？！

仔细一想，还真是如此。在这“码农”修仙界，人人皆望飞升，脱离 CRUD 的苦海，证得架构大道。韩天尊从一介凡人，在人界一步步逆天修行；我们则从一行“Hello World”开始，在代码的世界里摸爬滚打。从初窥门径到执掌乾坤，其间的艰辛与突破，又何尝不是一场惊心动魄的修行？

今日，不妨让我们借韩天尊的人界飞升之路，一同探寻这程序员的修仙境界。看看你我，如今身在何处，又该如何“破境”飞升。

第一境：炼气期 – 程序员学徒

此境界的修士初入仙门，刚刚感应到“天地灵气”（编程语言），开始学习吐纳之法（基础语法）。灵力微薄，法术生疏，面对浩如烟海的功法秘籍（API文档），常常感到力不从心，一不小心就可能“走火入魔”（写出 Bug）。

• 境界特征：
  • 初窥门径，灵力微薄： 刚掌握一门或多门“功法”（Java/Python/Go），但理解不深。能写出基础的业务逻辑，但对底层原理一知半解，如同只会念咒却不知其所以然。
  • 修炼功法，打牢根基： 每日勤修不辍，疯狂“吸收灵石”（看文档、刷 LeetCode、学习框架）。主要任务是完成导师（Mentor）分配的“宗门任务”（小功能、Bug修复），以此换取修炼资源。
  • 依赖法器，难离其身： 严重依赖各种“低阶法器”，如 Stack Overflow、CSDN 和各类 AI 代码助手。一旦“法器”失灵（断网），便束手无策，战力大减。
  • 心魔与瓶颈： 最大的心魔是“我是不是不适合写代码”的自我怀疑。常常会遇到“瓶颈”，一个简单的 Bug 可能要耗费数日才能解决，此时急需一颗“筑基丹”（高人指点）方能突破。

第二境：筑基期 – 合格的工程师

经历无数次“走火入魔”后，终于炼化灵气，开辟丹田，成功“筑基”，体内的“灵力”（知识体系）凝聚成形。从此，你不再是修仙界的炮灰，而是一名真正的修士，可以独立执行任务，在宗门（团队）中有了一席之地。

• 境界特征：
  • 筑基成功，道途有望： 能够独立负责一个模块或一条业务线。对团队的技术栈了如指掌，是项目的中坚力量，道基稳固。
  • 拥有本命法器： 不再是见什么用什么，而是有了自己得心应手的“本命法器”（精通的框架或工具链），如 Spring 全家桶、Vue/React 生态。使用起来得心应手，威力倍增。
  • 神识初成，洞察秋毫： 开始具备一定的“神识”（Code Review 能力和设计嗅觉），能发现炼气期修士代码中的明显问题，并预见一些潜在的风险，如同神识外放，探查四周。
  • 独立执行宗门任务： 可以独立外出执行有一定难度的“宗门任务”（负责一个完整需求），并能顺利归来，不再需要师兄寸步不离地看护。

第三境：结丹期 – 资深工程师 / 技术骨干

此乃修行路上的巨大分水岭。修士将全身修为压缩、凝练，在丹田内结成一颗“金丹”（核心技术壁垒）。从此，寿元大增（职业生涯更稳定），神通广大，成为宗门里受人敬仰的长老级人物。

• 境界特征：
  • 凝结金丹，质的飞跃： 在某一领域（如高并发、分布式、数据库优化）形成了自己深厚的知识体系和方法论，这便是你的“金丹”。你是这个领域的 Go-to Person，是众人眼中可靠的“X哥”、“X姐”。
  • 本命法宝，威力大增： 不再满足于使用“法器”，开始炼制自己的“法宝”（轮子、工具库、脚手架），供宗门内弟子使用，极大提升了整个团队的战斗力。
  • 开辟洞府，传道授业： 开始承担起“长老”的职责，为宗门“开辟洞府”（搭建技术分享平台），“传道授业”（指导新人、进行技术培训），培养后辈力量，扩大自己的影响力。
  • 阵法大师，布局为先： 对小型系统的架构设计信手拈来，如同布置“阵法”，懂得权衡取舍，让系统在未来一段时间内稳固运行，易于扩展。

第四境：元婴期 – 架构师 / 首席工程师

碎丹成婴，道行进入全新天地。修士的“元婴”可以出窍，神游天外，对“天地法则”（系统规律）的理解远超常人。他们是宗门的守护神，轻易不出手，但一言一行都足以影响宗门的兴衰。

• 境界特征：
  • 元婴出窍，神游天外： 视角早已超越某个具体项目或业务线。他们的“元婴”（思想和影响力）可以“出窍”，俯瞰整个公司的技术体系，思考跨团队、跨领域的平台级问题。
  • 参悟天地法则： 深入理解分布式、高可用、可扩展性等“天地法则”。他们关注的不再是“术”（具体实现），而是“道”（设计哲学与原则），能在纷繁复杂的需求中，找到最核心的技术模型。
  • 开宗立派，影响一方： 他们设计的“护山大阵”（核心技术架构、平台），能支撑公司未来数年的发展。他们制定的“门规”（技术规范、研发流程），被众多弟子遵守，深刻影响着整个技术团队的文化和效率。
  • 趋吉避凶，未卜先知： 具备强大的技术预判能力，能洞察技术趋势，规避未来的技术债务和架构风险，带领宗门走在正确的“修行”道路上，避免误入歧途。

第五境：化神期 – 技术大牛 / 领域开拓者

此境界已是人界的传说，神龙见首不见尾。他们对“道”的理解已返璞归真，能够洞悉本源，甚至创造规则。他们的存在，本身就是一座无法逾越的高山，是无数修士仰望的目标。

• 境界特征：
  • 返璞归真，大道至简： 他们的言论和代码往往看起来平平无奇，却蕴含着对技术最深刻的理解。能用最简单的语言解释最复杂的原理，如同“大道至简”，一言一行皆是道法自然。
  • 言出法随，创造规则： 他们不再是规则的遵守者，而是规则的创造者。他们创造的某个开源框架（如 K8s, TensorFlow）、某篇论文（如 MapReduce, DynamoDB），可能开创一个时代，成为无数修士修行的“根本大法”。
  • 破碎虚空，飞升上界： 他们的影响力早已超越一家公司，成为整个行业的灯塔。他们可能在顶级技术会议上“讲道”，也可能在某个开源社区中“点化”众生。对他们而言，换个公司已不是“跳槽”，而是“破碎虚空”，去往另一个更广阔的世界（灵界）。

小结：路漫漫其修远兮

修仙之路，道阻且长，行则将至。

从炼气期的迷茫，到筑基期的坚定；从结丹期的突破，到元婴期的洞察，乃至化神期的传说。每一个境界，都离不开日复一日的“打坐”（学习）、一次又一次的“渡劫”（攻克难题），以及那么一点点“机缘”（好的项目和团队以及赛道）。

韩立资质平平，却凭着“勤奋”与“谨慎”二字，终成大道。我辈程序员，或许没有逆天资质，但只要心向大道，勤勉不怠，终有一日，也能突破瓶颈，得见真我。

那么，各位道友，你现在修炼到哪个境界了？在修行路上又遇到了哪些瓶颈或趣事？欢迎在评论区留下你的“道号”和境界，我们一同论道！

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

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

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

本文永久链接 – 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

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