标签 最佳实践 下的文章

代码之外的修炼:Google 资深工程师的 21 条“生存法则”

本文永久链接 – https://tonybai.com/2026/01/11/21-lessons-from-google-engineer

大家好,我是Tony Bai。

“当我 14 年前加入 Google 时,我以为这份工作就是写出优秀的代码……我只说对了一部分。我待得越久,就越意识到,那些真正茁壮成长的工程师,不一定是最好的程序员——他们是那些懂得如何驾驭代码周围一切的人:人、政治、协同和模糊性。”

这段话,出自 Google 资深工程师 Addy Osmani 的一篇深刻反思——《在 Google 14 年的 21 条经验》。这篇文章,如同淬炼了 14 年的智慧结晶,几乎没有谈论任何具体的技术栈,却精准地描绘出了一位卓越工程师的成长画像。

这 21 条“法则”,并非关于某种转瞬即逝的技术,而是关于那些在项目、团队、公司之间反复出现的永恒模式。它们不是一场与外部世界的战争,而是一场关于自我提升的漫长“修炼”。这是一份珍贵的“心法”,能帮助我们在这场修炼之路上,走得更远、更稳。本文将为你逐一解读。


1. 最好的工程师痴迷于解决“用户问题”,而非“技术问题”

这是工程师“修炼”之路的第一心法:放下执念

放下对特定技术的迷恋,将自我从“工具的使用者”升华为“问题的解决者”。

“用户痴迷”意味着走出 IDE,去阅读支持工单,去和真实用户交谈,去观察他们如何在你的产品中挣扎。

当你真正理解了用户的“痛”,你往往会发现,那个最优雅的解决方案,远比你最初设想的任何复杂技术都要简单。

2. 做到正确很廉价,而“一起”做到正确才是真正的修行

你可以在每一次技术辩论中都“赢”,但最终输掉整个项目。

真正的“修为”,不在于证明自己正确,而在于创造一个安全的空间,让团队能够共同对问题达成一致,并对自己的确定性保持怀疑。

记住:“观点强硬,但立场松动 (Strong opinions, weakly held)。”

3. 偏爱行动。交付。你可以修改一个糟糕的页面,但无法修改一个空白的页面

对完美的追求是麻痹剂,是“心魔”。

完美的架构不会在纯粹的冥想中诞生,它诞生于与现实的接触。

先做出来,再做对,再做得更好。

交付那个让你感到“有点尴尬”的 MVP。

一个粗糙的原型所能带来的真实反馈,远超一个月闭门造车的理论辩论。

4. 清晰即资深,聪明是开销

编写“聪明”的代码,是工程师证明能力的本能。

但真正的软件工程,是在时间和团队协作的维度上展开的。

清晰性不是一种风格偏好,而是一种运营风险的降低

你的代码,是一份写给未来某个凌晨三点需要维护它的陌生人的“战略备忘录”。

资深的工程师,早已学会在他们的“修炼”中,用清晰性去交换那份无关紧要的“聪明”。

5. 新奇是一笔贷款,你将在故障、招聘和认知开销中偿还

像一个预算有限的组织一样,谨慎地对待你的“创新代币”。

只在你拥有独特优势的地方进行创新,其他所有事情,都应该默认选择“无聊”的技术,因为“无聊”意味着失败模式是已知的。

记住,“最好的工具”,常常是那个“在最多场景下最不坏的工具”。

6. 你的代码不会为你代言,人会

以为“好的工作会自己说话”,是工程师“修炼”生涯早期最大的错觉。

代码静静地躺在仓库里,它不会在晋升会议上为你辩护。

你需要将你的工作和价值,以一种可被他人理解和传播的方式呈现出来:写清晰的文档、做有影响力的分享、主动沟通你的成果。

7. 最好的代码,是那些你从未写下的代码

工程文化崇尚创造,但删除代码往往比增加代码更能改善一个系统

你没有写下的每一行代码,都是你永远不必去调试、维护或解释的一行代码。

在动手构建之前,请先用“无为”的智慧拷问自己:“如果我们就是……不这么做,会发生什么?”

8. 在规模化面前,即使你的 Bug 也有用户

当用户足够多时,你的系统的每一个可观测行为,无论你是否承诺过,都会成为一种事实上的依赖。

有人正在爬取你的 API,有人正在自动化你的“怪癖”,有人正在缓存你的 Bug。

这意味着,兼容性本身就是一种产品。你不能再将修复 Bug 视为“维护”,将开发新功能视为“真正的工作”。

9. 大多数“慢”团队,其实是“失调”的团队

当项目拖延时,我们的本能是归咎于执行力:人手不够、技术不行、工作不努力。

但真正的瓶颈,往往在于协同失败 (Alignment Failure)——团队在做错误的事情,或者以不兼容的方式在做正确的事情。

资深工程师会花费更多时间去澄清方向、接口和优先级,而不是单纯地“更快地写代码”。

10. 关注你能控制的,忽略你不能的

在大型组织中,组织架构调整、管理层决策、市场变化……无数变量都在你的控制范围之外。

为这些事情焦虑,是在浪费你宝贵的精力。

卓越的工程师,会战略性地专注于他们的“影响圈”:你能控制你代码的质量,你能控制你如何响应变化,你能控制你学到了什么。

这是一种专注的“禅定”

11. 抽象并未消除复杂性,只是将其转移到了你 on-call 的那一天

每一个抽象,都是一次“我未来不需要理解其底层”的赌博。

有时你会赌赢,但抽象总会泄露。

资深工程师之所以坚持学习底层知识,并非出于怀旧,而是出于对“凌晨三点,当你独自面对一个失效的抽象时”的敬畏。

12. 写作倒逼清晰。想学得更快,就去教别人

当你试图向他人解释一个概念时——无论是在文档中、演讲中,还是 Code Review 的评论里——你会立刻发现自己理解上的盲点。

把一个东西教给别人,本质上是在调试你自己的心智模型

这是最高效的“利己”的学习法门。

13. 那些让其他工作成为可能的工作,无价且无形

“胶水工作”——文档、新人引导、跨团队协调、流程改进——至关重要。

但如果你无意识地、仅仅出于“乐于助人”去做这些事,它们会吞噬你的时间,让你偏离技术主航道。

诀窍在于,有意识地去做,为它设定时间盒,将它转化为文档、模板、自动化等可见的成果,让它成为你明确的影响力,而非模糊的“性格特质”。

14. 如果你赢得了每一次辩论,你可能正在积累无声的抵制

当你“赢”得太轻松时,通常意味着事情不对劲了。

人们不再与你争论,不是因为你彻底说服了他们,而是因为他们已经放弃了尝试。

而这份未解的分歧,将会在未来的执行层面,以“神秘的阻力”的形式爆发出来。

真正的协同,需要你真正去理解他人,并有时公开地改变自己的想法。

15. 当一个指标成为目标时,它便不再是一个好的指标

古德哈特定律的经典再现。

人类会为了被测量的东西而优化。

资深的做法是,用一组成对的指标来响应管理需求(例如,速度 vs. 质量),并坚持解读趋势,而非崇拜某个具体的阈值。

16. 承认“我不知道”,比假装知道能创造更多安全感

当一个领导者或资深工程师坦诚自己的不确定性时,他实际上是在给予整个团队“提问”和“犯错”的许可。

这会创造一种心理安全的环境,让问题在爆炸前被暴露出来。

反之,一个“永远正确”的领导者,只会培养出一群沉默的下属和一堆隐藏的地雷。

17. 你的人脉,比你做过的任何一份工作都更长久

职业生涯早期,我们容易专注于工作本身而忽略人际交往。

这是一个巨大的错误。

那些在公司内外投资于人际关系的同事,在数十年后,会收获巨大的回报。

你的工作不是永恒的,但你建立的信任是。

18. 大多数性能的胜利,源于“移除工作”,而非“增加聪明”

当系统变慢时,我们的本能是增加缓存、并行处理、或者换用更聪明的算法。

但更具影响力的胜利,往往来自于问一个更根本的问题:“我们正在计算的这些东西,真的有必要吗?”

删除不必要的工作,远比把必要的工作做得更快要有效得多。

最快的代码,是那段从未运行过的代码。

19. 流程的存在是为了减少不确定性,而不是为了制造文书工作

最好的流程,能让协作更容易,让失败的代价更便宜。

而最坏的流程,是“官僚主义戏剧”——它的存在不是为了帮助,而是在出问题时用来甩锅。

如果你无法解释一个流程如何降低风险或增加清晰度,那它很可能就是纯粹的开销。

20. 最终,时间会比金钱更宝贵。请据此行事

职业生涯早期,你用时间换金钱。

但在某个临界点之后,这个公式会反转。

时间是唯一不可再生的资源。

答案不是“不要努力工作”,而是“清楚你在交易什么,并深思熟虑地做出交易。

21. 没有捷径,但有复利

专业知识,来自于经年累月的刻意练习。

但这里有希望的部分:学习是具有复利效应的。

你建立的每一个心智模型,你总结的每一条经验教训,都会成为你未来解决更复杂问题的“可复用原语”。

将你的职业生涯视为复利投资,而非一张张彩票。

小结:修炼的核心永远是人

Addy Osmani 的 21 条经验,最终可以归结为几个核心思想:保持好奇,保持谦逊,并永远记住,修炼的核心是人——你为之构建的用户,以及与你一同构建的队友。

对于我们工程师而言,这意味着,职业生涯的成长,是一场双螺旋式的攀升。

技术能力的“硬实力”是我们的根基,但决定我们最终能达到何种“境界”的,往往是沟通、协作、权衡、同理心这些看似“软”的、关于人的智慧。

这场“代码之外的修炼”,道阻且长,但行则将至。

资料链接:https://addyo.substack.com/p/21-lessons-from-14-years-at-google


你的“第22条”法则

读完这21条法则,相信你一定心有戚戚焉。在你自己的职业生涯中,是否有哪一条“生存法则”是你用惨痛教训换来的?或者,你觉得还有什么重要的经验是这21条没有覆盖到的?

欢迎在评论区分享你的独家心法! 让我们一起汇聚更多智慧。

如果这篇文章给了你新的启发,别忘了点个【赞】和【在看】,并转发给身边正在迷茫的工程师朋友,也许这就是他破局的关键!


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

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

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


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

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

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

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

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


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

AI 代码审查的“危”与“机”:从个体挣扎到 Uber 的系统化解法

本文永久链接 – https://tonybai.com/2025/12/27/code-review-hell-in-ai-age

大家好,我是Tony Bai。

最近,在与几位架构师朋友的交流中,一个在 AI 编码时代下越来越普遍的“灵魂拷问”浮出水面。这不仅是一个问题,更是他们正在亲身经历的“代码审查地狱 (Code Review Hell)”。

想象一下这个场景:由 AI Agent 生成的代码正以前所未有的速度涌来,堆积如山;你花费心力给出的精辟修改意见,却被开发者转身当作新的 Prompt 重新喂给了 AI;片刻之后,一个全新的 PR 诞生了——它看起来解决了旧问题,却可能带着一堆你从未见过的新问题。你感觉自己深陷于“生成-审查-再生成”的无限循环中,身心俱疲。

这场危机并非危言耸听。在 Uber,每周有超过 65,000 个变更(相当于 PR)需要审查。当 AI 辅助编码成为常态,传统的 Code Review 流程已濒临崩溃。

但这究竟是末日,还是进化的前夜?答案是后者。这场危机,正催生一场深刻的变革——一方面,它要求架构师完成从“创作者”到“导演”的角色进化;另一方面,它也催生了像 Uber uReview 这样复杂的、系统化的 AI 审查平台。

本文将结合对当前危机的剖析与 Uber 的大规模工程实践,为各位小伙伴儿揭示这场变革的本质与破局之路。

危机的剖析:我们到底在审查什么?

要逃离地狱,必先理解地狱的构造。这场危机的根源,在于 AI 颠覆了代码的“创作”过程,从而动摇了 Code Review 的根基:

  1. 思考过程“黑箱化”: 传统的 Code Review,我们审查的是代码,更是其背后开发者的思考路径。而 AI 的介入,将这个思考过程隐藏了起来。
  2. 审查对象“降维”: 审查被迫从“这段设计是否优雅?”降维到了“这次 AI 输出是否碰巧正确?”。
  3. 学习循环“断裂”: 开发者跳过了对 Review 意见最关键的“理解与吸收”环节,宝贵的经验传承被阻断。

天真地想用“AI 审查 AI”来解决问题,只会陷入更深的陷阱。正如 Uber 在其 uReview 项目初期所发现的,未经驯化的 LLM 会产生大量“幻觉”和“低价值的误报”,比如在非性能敏感的代码中挑剔性能问题。这些“噪音”会迅速侵蚀工程师对工具的信任,最终导致他们“调低音量并忽略它们”。

破局之路(上):架构师的进化——从“创作者”到“代码导演”

面对危机,架构师和资深开发者的核心价值,必须从 Code Writer (代码创作者),进化为 Code Director & Editor (代码导演与总编)

“导演”不亲自扮演每个角色,但他定义了整部戏的基调、框架和最终质量。这份“代码导演”的实战手册,为我们指明了方向:

  • 实践 1:审查“左移”,审查“剧本”而非“表演”
    在开发者大规模生成代码前,先审查其核心设计思路、任务分解和关键 Prompt。确保“剧本”是对的,再让 AI 这个高效的“演员”去表演。

  • 实践 2:制定 AI 时代的 Code Review 新规

    • 明确标识 AI 代码,为审查者提供“警示”。
    • 强制开发者解释“为何接受”AI 方案,夺回思考的主动权。
    • 禁止“甩锅式再生成”,保护学习循环。
  • 实践 3:定义“AI-Go”与“AI-No-Go”区域
    将 AI 的使用限制在单元测试、文档、模板代码等 AI-Go 区域,而在核心业务逻辑、安全代码等 AI-No-Go 区域保持高度警惕,让人类智慧主导。

破局之路(下):Uber 的 uReview——“导演”的智能副驾

如果说“代码导演”模型描绘了架构师的“个人修炼心法”,那么 Uber 的 uReview 平台则展示了如何将这些理念,构建成一个大规模、系统化的工程解决方案。uReview 并非要取代人类,而是作为一个“智能副驾”或“第二审查员”,来增强人类的能力。

面对 AI 生成代码的洪水,Uber 没有让 uReview 直接进行审查,而是构建了一个精密的、多阶段的过滤管道,这与“导演”的思维方式不谋而合:


图:Uber uReview 的多阶段处理流水线

  1. 预处理: 首先,系统会过滤掉配置文件、自动生成的代码等低价值目标,只聚焦于需要审查的核心代码。
  2. 专业分工: uReview 并未使用单一的通用 AI,而是设计了多个“专家助理”
    • Standard Assistant: 专注于逻辑缺陷、错误处理等 Bug。
    • Best Practices Assistant: 对照 Uber 内部的风格指南,检查代码是否符合规范。
    • AppSec Assistant: 专门寻找应用层的安全漏洞。
      这完美印证了“定义 AI-Go/No-Go 区域”的思想——让专业的 AI 干专业的事。
  3. 严格品控: 这是 uReview 的核心,也是对“警惕 AI 幻觉”的最佳回应。它包含一个多层过滤过程:
    • 二次评估:另一个 AI(Review Grader)会对生成的每条评论进行打分,过滤掉低置信度的评论。
    • 语义去重:合并相似的建议。
    • 分类抑制:自动压制那些历史上被证明对开发者价值不大的评论类别。

Uber 的实践经验,为我们带来了几条宝贵的“场内教训”,这些教训与架构师的直觉高度一致:

  • 精准比数量更重要: 充满噪音的建议会迅速摧毁信任。uReview 的核心策略就是“提供更少但更有用的评论”。
  • 护栏与提示词同等重要: 优秀的系统架构和后处理流程,远比单纯的提示词工程更关键。
  • 开发者讨厌文体说教: AI 提出的代码可读性、日志微调等建议,普遍不受欢迎。开发者更珍视对正确性、Bug 和最佳实践这种“高信噪比”的反馈。
  • AI 善于抓虫,而非评估设计: 由于缺乏设计文档、业务背景等上下文,AI 无法评估系统设计的优劣。这再次强调了人类“导演”在宏观设计上不可替代的价值。

如今,uReview 在 Uber 内部取得了巨大成功:超过 75% 的 AI 评论被工程师标记为“有用”,每周节省约 1500 个工时,相当于每年近 39 个开发者年。

小结:拥抱人机协同的新未来

AI 带来的代码审查危机,实际上是一场深刻的产业升级。它迫使我们从对“代码”的微观审查,转向对“创作流程”的宏观把控。

“代码导演”模型为我们提供了战略指引,而 Uber 的 uReview 则展示了实现这一战略的工程蓝图。未来的 Code Review,不再是人与人的博弈,也不是人与 AI 的对抗,而是一种全新的“人机协同”模式:

架构师作为“导演”,定义设计、划定边界、把控最终质量;而像 uReview 这样的智能系统,则作为高效、精准、不知疲倦的“副驾驶”和“场务”,处理海量的细节检查,将人类从重复、繁琐的工作中解放出来。

最后,回到那个终极问题:谁来为质量负责?答案从未改变,也永远不会改变:永远是工程师自己。AI 是我们手中最强大的工具,但手握方向盘、对最终结果负责的,永远是我们自己。

资料链接:https://www.uber.com/blog/ureview/


聊聊你的“审查之痛”

AI 时代的 Code Review,正在成为每个技术团队的新挑战。在你所在的团队中,是否也遇到了 AI 代码带来的“审查地狱”?你们是如何应对的? 是明令禁止,还是像 Uber 一样积极构建自动化防线?

欢迎在评论区分享你的真实经历和思考! 让我们一起探索人机协同的最佳实践。

如果这篇文章对你有启发,别忘了点个【赞】和【在看】,并转发给你的架构师朋友,也许能帮他从“地狱”中解脱出来!


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

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

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

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

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


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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 AI原生开发工作流实战 Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com
这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats