从首席工程师身上学到的10条经验教训

向最优秀的人学习，成就最优秀的自己！

核心摘要

• 首席工程师的价值不只体现在技术深度，也体现在判断力、沟通方式和对团队的影响。
• 好代码要服务未来维护者：命名清晰、结构简单、注释有意义，避免只追求“聪明”写法。
• 稳健交付不是变慢，而是通过更好的假设验证、更少返工和更少技术债来真正变快。
• 工程师需要理解业务、阅读代码历史、识别复杂性、选择合适抽象，并在不同角色之间有效沟通。
• 资历不是只看自己写了多少代码，而是看你让团队变强了多少。

这 10 条经验回答什么问题

这篇文章不是“如何晋升首席工程师”的清单，而是一次观察记录：一个工程师在和首席工程师共事一年后，哪些工作习惯被改变了。

我仍然记得我与我们首席工程师的第一次一对一交流。我刚加入团队，急切地想要证明自己。我原以为会面临一场技术上的严苛考验，但相反，我们谈论了设计原则、业务影响，以及他称之为“工程成熟度”的东西。那次谈话彻底改变了我的思维方式。

在接下来的一年里，我跟着他参与棘手的项目，参加远超我职级水平的架构讨论，观察他在压力下如何工作。我从他身上学到的东西改变了我的编码方式、沟通方式以及做出贡献的方式。

以下是影响最大的10条经验教训。

每读完一条，请静静的回味 30s

可引用地说：工程成熟度不是写出更复杂的代码，而是在约束、风险、业务目标和团队协作之间做出更可靠的判断。

1. 为接替你的工程师编写代码

“你的代码应该讲述一个故事，” 他说，“一个下一个人无需猜测情节就能读懂的故事。”

这让我深受触动。我不再写那些巧妙的单行代码，而是开始留下有意义的注释。我会把函数名写得更清晰，编写模块化的代码，这不仅仅是为了我自己，也是为了半年后调试代码的可怜家伙（那个可怜家伙可能是我自己…）。

这条经验的核心不是“多写注释”，而是降低未来维护者的理解成本。可维护代码应该让后来者快速看懂意图、边界和风险。

2. 慢即稳。稳即快。

我过去常常匆忙进行部署，以速度为名敷衍了事。他向我展示了这种匆忙往往会导致错误，而这些错误日后会花费更多时间来解决。每做一个功能，都要打磨到位，不要留技术债。

相反，他处事冷静，即使在生产事故中也是如此。他会反复核实各种假设，提出更有质量的问题。有趣的是，他的方法实际上能更快地完成工作，而且返工更少。

这里的“慢”不是拖延，而是先把问题看清楚。少一次错误上线、少一次返工、少一次生产事故，最终都会变成更快的交付。

3. 理解业务，而不仅仅是代码

“你可以打造出完美的功能，”他说，“但如果你不知道它为何重要，那依然没有抓住重点。”

他教我去问：

• 我们为谁打造这个功能、产品？
• 它解决了什么问题？
• 它是如何创造商业价值的？

这种心态帮助我更好地确定优先级，必要时予以拒绝，甚至提出更明智的解决方案。

如果不知道功能为什么重要，工程师很容易只优化局部技术指标。理解业务之后，才能判断哪些需求值得做、哪些复杂度不值得引入。

4. 像读历史书一样阅读代码库

在一次代码审查中，我问道：“为什么要这样做？”他回答道：“你查看过git历史记录了吗？”

事实证明，我所质疑的奇怪模式是三次产品调整和一次客户升级的结果。不要认为代码很愚蠢——要想到其背后必有原因。

读代码库时只看当前代码是不够的。提交历史、事故记录、客户诉求和历史迁移，往往解释了为什么系统会长成今天这样。

5. 永远不要说“只是”、“仅仅”、“就”

• “我们就快速添加一个API吧。”
• “我们就不能改一下架构吗？”

他在架构会议上禁止使用“仅仅”、“只是”、“就”这些词。它会过度简化问题，掩盖复杂性，并导致糟糕的规划。

现在，每当有人说“只是”的时候，我都会停下来问自己：真的有那么简单吗？

“只是”这个词危险的地方在于，它会把隐含成本藏起来。架构调整、数据迁移、兼容性、权限、监控、回滚和沟通成本，都可能被一句“就改一下”掩盖。

6. 选择合适的抽象，而非最抽象的抽象

他曾经把我那个优美、可复用、通用的类重构为三个简单且重复的函数。他说：“过早抽象比重复更糟糕。”

我了解到，优秀的架构并非不惜一切代价追求“不要重复自己”（DRY）原则，而是注重可读性、可维护性以及是否符合实际目的。

重复有时只是重复，过早抽象却可能把未来变化锁死。合适的抽象应该来自真实重复和稳定边界，而不是来自对“通用性”的想象。

7. 学会向上、向下和横向沟通

看他向领导层做展示，堪称大师级教学。没有术语，权衡清晰，商业影响被置于首要和核心位置。

他会向不同群体表达不同内容：为工程师提供技术深度，为项目经理阐述高层次目标，让利益相关者安心。

沟通并非无关紧要的软技能，而是成为高级开发人员的核心要素。

高级工程师的沟通要能翻译复杂性：对工程师讲清技术细节，对产品和项目讲清影响与取舍，对管理者讲清风险和决策。

8. 日志是你写给未来自己的情书

“写日志的时候，想象你在凌晨2点半睡半醒地试图调试生产环境中的崩溃问题，那时你希望看到什么样的日志？”

从那以后，我就痴迷于精心记录日志：

• 该系统试图做什么？
• 它接收了哪些输入？
• 哪里出了问题——原因是什么？

好的日志就像时光机。有时，它们比测试更能帮到你。

日志的目标不是“多打几行”，而是在事故现场回答关键问题：系统当时想做什么、输入是什么、失败在哪里、下一步该看哪里。

9. 知道何时该让问题（暂时）搁置

并非每个漏洞都需要立即修复。并非每个技术债务都值得专门花一个冲刺周期来解决。

他教我如何有效地进行分类处理——了解风险、评估影响并做出战略决策。

“工程学无关完美，”他说，“而是关乎判断力。”

不是所有问题都值得立刻修。成熟的工程判断，会同时考虑风险、影响范围、用户伤害、修复成本和机会成本。

10. 资历是由你对他人的助力程度来衡量的

最令人惊讶的领悟是什么？他的影响力不仅仅体现在他的代码上，还在于他如何让其他人变得更出色。

• 他指导他人时毫无私心。
• 慷慨地认可他人。
• 退一步，好让他人能进一步。

他告诉我：“你之所以成为一名更出色的开发者，不仅是因为你的代码有了改进，还因为你的团队取得了进步。”

这也是首席工程师和资深个人贡献者最大的区别之一：影响力不只来自个人产出，也来自让别人更容易做出正确决策。

10 条经验可以如何落地

结语

和他共事之后，我并没有成为一名首席工程师，但我的思维方式开始像首席工程师靠拢。这种转变影响了我此后参与的每一个项目。

这些经验教训并不总是让人好受，有些我是通过艰难的方式才学到的。但每一条都帮助我成长——不仅是作为一名开发者，还作为一名团队成员、领导者和思考者。

如果你有幸能与这样的人共事，那就留心观察。留意他们的行事方式。多倾听，少发言。并将从他们身上学到的东西传承下去。

好的工程师打造功能。更好的工程师培养人才。

FAQ

首席工程师最值得学习的是什么？

原文最核心的答案是工程成熟度：写可维护代码、理解业务、识别复杂性、选择合适抽象、稳健交付、有效沟通，并帮助团队一起变强。

为什么“只是”“仅仅”“就”这些词要谨慎使用？

这些词会过度简化问题，掩盖迁移、兼容、监控、权限、回滚、沟通和长期维护成本，容易导致糟糕规划。

过早抽象为什么危险？

过早抽象可能把尚未稳定的变化点固化到通用结构里，反而增加理解成本和修改成本。有时三个简单函数比一个复杂通用类更容易维护。

好日志应该回答什么问题？

好日志至少应该帮助未来排障者理解：系统试图做什么、接收了哪些输入、哪里出了问题、可能原因是什么，以及下一步该看哪里。

enjoy ：）

原文：https://medium.com/the-pythonworld/10-lessons-i-learned-from-a-principal-engineer-that-made-me-a-better-developer-2d1337eb85b8