我在 Big Tech 工作中学到的：前端工程师的反思

Source: Dev.to

引言

在大厂工作总像是一扇通往新世界的“门”。你写代码，开始思考技术、产品以及规模化的影响。多年在高流量环境中工作，每天处理服务数十万用户的系统后，我发现学习远超表面显而易见的内容。

在大厂里，你构建的功能不仅仅是“能运行”。每个组件、端点、查询和渲染都必须高效且可预期。这改变了作为开发者的思考方式：

• 考虑 回退、重试、超时、可观测性和弹性。
• 在改动前先测量（Lighthouse、Web Vitals、实验、A/B 测试）。
• 实现新功能前，先进行 spikes、POC 并与团队一起做架构决策。
• 明白 延迟就是用户体验。

你不再是单纯的执行者，而是关注未来和规模的工程师。

设计系统

以前，我把设计系统视为组织、文档和漂亮的组件。后来我意识到它是 基础设施，和 API、数据库一样重要。当数十个团队共用同一套界面时，一致性、可访问性和效率就变得至关重要。

• 组件必须安全、稳定且可测试。
• 可访问性（WCAG）不再是可选项，而是基本要求。
• 设计系统的演进会推动整个公司，而不仅仅是你的团队。
• 将组件视作“产品中的产品”来设计。

我学到的

• 在用户察觉之前解决 bug。
• 像 Sentry、Amplitude、LogZ、Datadog、Clarity 这样的工具表明错误随时会发生，关键在于检测、调查和解决的速度。
• 在交付功能之前先创建仪表盘是必不可少的；数据是所有人的语言（工程、产品、设计）。

指标与测试

• “没有指标的代码就是在黑暗中写代码”。
• 在错误会导致真实损失的环境中，测试不再是“可有可无”，而是必不可少。
• 高覆盖率重要，但 有价值的测试 更为关键。
• 编写良好的测试可以加速发布，而不是拖慢它。
• E2E 不能替代单元测试；单元测试也不能替代集成测试。
• 手动 QA 验证行为，而不是技术质量。

持续反馈

• 反馈体现在 PR 评审、RFC、技术对齐、回顾、需求细化和配对编程中。
• 这迫使你快速成长，无论是作为开发者还是作为人。
• 反馈不是攻击；1:1 交流非常重要。
• 代码审查是同理心 + 意图的练习。
• 在团队中大声思考可以对齐并避免技术债务。
• 传达决策和做出决策同等重要。

跨学科协作

你会与以下角色合作：

• 产品
• 设计
• 后端
• 数据
• QA
• 利益相关者
• 工程

没有人能单独完成所有工作。这种现实教会你：

• 谈判范围。
• 向非技术人员解释技术承诺。
• 做出权衡。
• 理解业务的真实优先级。

衡量影响

你的工作通过以下维度来衡量：

• 你减少了多少错误。
• 你提升了多少体验。
• 你加速了多少其他团队的进度。
• 你节省了多少成本。
• 你为用户消除了多少痛点。

代码只是手段；在最优秀的人才中，最大的差异不是技术天赋，而是 所有权（ownership）：

• 在被要求之前主动解决问题。
• 关注用户。
• 着眼长远。
• 理解自己构建的影响。
• 真正协作。
• 在不需要头衔的情况下引导方向。

大厂教会你宏观思考

在这样的环境中工作会改变你的世界观：

• 你懂得产品的优先级。
• 学会真正应对规模化。
• 技术上更加成熟。
• 获得工程纪律。
• 为做出正确决策提供上下文。
• 发展自主性。
• 学会简化复杂系统。

这段经历并不会自动让你成为更好的工程师，但它把你置于一个 要求 你成长的环境中。

我离开这段经历时，对以下方面有了更深入的理解：

• 规模
• 架构
• 协作
• 产品
• 影响
• 责任
• 真正的工程

最重要的是：

技术不在于代码，技术在于以规模化的方式解决问题。