初级和高级工程师的区别不在于他们写的代码

Source: Dev.to

请提供您希望翻译的完整文本内容，我将为您翻译成简体中文。

Seniors Design for Failure First

一名初级工程师只构建顺利路径：用户注册，数据保存，响应返回。一切在开发环境中都能正常工作，但在生产环境中却全部崩溃。

资深工程师则从“如果失败会怎样？”这个问题开始。他们在外部 API 调用上添加断路器，防止一次下游超时导致整个系统宕机。他们配置 DynamoDB 的 TTL，使陈旧数据自动过期，而不是让表无限增长。他们在第一天就接入 SQS 死信队列，确保失败的消息不会悄然消失。

区别不在于偏执，而在于经验。只要你曾在凌晨 2 点被第三方 API 宕机并拖垮整个服务的警报叫醒，你就再也不会跳过故障处理。

高级工程师阅读代码多于编写代码

当一名初级工程师接到新任务时，他们会打开一个空白文件并开始编码。当一名高级工程师接到同样的任务时，他们会先花 30 分钟 阅读已有的代码库。

这并不是慢，而是精准。他们会寻找已有的模式、共享的工具、命名约定以及已经做出的架构决策。他们想在加入任何新内容之前先弄清楚现有的东西。

在我为一家 美国客户 维护的 NestJS monorepo 中，已经有共享模块、自定义装饰器以及花了数周时间建立的 TypeORM 仓库模式。跳过阅读阶段的初级工程师会复制逻辑、破坏约定，进而产生技术债务，导致其他人在下一个 sprint 中必须清理。

阅读代码是最被低估的工程技能。我合作过的最佳工程师花在阅读上的时间比写代码的时间更多。他们对代码库足够熟悉，能够复用已有模式而不是重新发明，从而将产出时间减半，错误率降低一个数量级。

Seniors Debug the System, Not the Symptom

一个初级工程师看到 500 错误，找到抛出异常的那行代码，添加 try‑catch，然后继续。看似 bug 已经修复，但其实没有。

一个高级工程师通过 CloudWatch Logs 追踪请求，检查 Lambda 冷启动延迟，查看 DynamoDB 的消耗容量，进而发现真正的根本原因是上游的两个服务：SQS 可见性超时配置错误，在负载下导致重复处理。

症状是 500 错误；原因是一个已经部署六个月却没有人检查的队列配置。高级工程师不只修复症状——他们会追踪完整路径并修复系统。

这正是可观测性工具体现价值的地方。没有结构化日志、分布式追踪和 CloudWatch 仪表盘，你只能凭猜测进行调试。高级工程师会在需要之前就搭建好可观测性。

高级工程师问：“如果是 10 倍会怎样？”

初级工程师为当前的流量设计。高级工程师为六个月后预期的流量设计。

这并不意味着提前进行优化；而是在每一次架构决策之前都要问一个问题：“当负载达到当前的 10 倍时会怎样？”

在为 Menthera 构建实时语音 AI 系统时，我一开始就在应用层和 DynamoDB 之间加入了 Redis 缓存层——并不是因为第一天就遇到扩展性问题，而是因为我知道并发的 WebRTC 会话如果没有读缓存会对数据库造成冲击。

高级工程师会在流量激增之前就加入分区策略、连接池、缓存层和速率限制器——而不是在故障之后才去补救。事后再添加这些组件的成本总是高于从一开始就做好准备。

真正的区别

大多数工程师优化的是写代码。高级工程师优化的是 不 写代码。

• 他们在写之前先阅读。
• 他们在设计功能之前先为故障设计。
• 他们在打补丁之前先进行追踪。
• 他们在需要之前就规划可扩展性。

代码本身是工作中最不重要的部分。围绕代码的系统才是一切。

如果你只能从中学到一点：下次坐下来构建东西时，先把第一小时花在除写代码之外的所有事情上。阅读现有代码库。添加故障处理。建立可观测性。思考在 10× 规模下会发生什么。然后再写代码。这样你可以更快交付，睡得更安稳。

是什么习惯改变了你对工程的看法？