《软件工程师记》EP.3: 五周年

前言

今年是我成为软件工程师的第五年，也刚好是在今年，我将踏上异地求职的旅程。虽然不确定是否能在英国顺利找到理想的工作，但回顾过去这五年，作为一名软件工程师，我学到了许多，也经历了许多。这段旅程是奇妙也是幸运，或许正值得好好记录下来。

五年，说长不长，说短也不短。现在回头看当初写的 《软件工程师记》EP.1: 从零到一 与 《软件工程师记》EP.2: 街口支付，总觉得那时刚踏入职场的自己成长得非常快。每天都有接触不完的新技术与新知识，日子过得充实且有挑战性。

求稳不求新

结束了在街口支付两年的工作后，我加入了一间美商公司，这间公司刚好符合我当时的求职目标，不错的待遇、有跨国合作的机会也有良好的团队文化。但我对于新技术的追求在这三年间慢慢地消失了。

起初我以为是自已变得懒惰了，导致看到新技术的欣喜程度开始钝化。为了找回那份热情，我在 2024 年开始写 前端电子报，想说通过整理趋势与新知来保持自己的新技术敏感度。但我慢慢发现，我并不是失去了对于软件技术的热情，而是我开始更重视系统与框架的稳定性。

刚加入这间美商公司时，发现团队使用的并不是 Next.js 或 Remix 这类当时正夯的 Meta Framework，而是一套自研的框架。那时候的我难免有些失望，毕竟正值 Next.js 如日中天、话题性十足，而我却没有机会亲手接触它。

但三年过去，我渐渐看见这套自研框架的价值。它虽然使用的技术有点老旧，开发体验也有乏善可乘，但已能稳定支援公司各个服务项目的多种需求。无论是垂直扩展，或是进一步拆分成微前端架构，它都能够做到。这种架构层面的弹性，让我对于前端工程有一个新的认知。

如果真的想要学习新技术，其实不妨通过写博客或经营自己的 Side Project 来练习跟探索，这也是当初参加 铁人赛 跟写 电子报 的原因。而在工作中，更重要的往往不是使用多新的技术，而是如何写出稳定且高效的代码。除非新技术或框架能够明确带来超越稳定性的价值，否则在团队开发中贸然引入，反而可能增加维护成本与风险。

保持开放

起初我对后端开发还非常陌生。记得在每次会议在安排下个 Sprint 工作项目时，我总是下意识地避开后端任务，更倾向选择自己熟悉的前端项目。每当看到需要碰后端的任务，脑海里总会冒出一个声音：「我不够格，会搞砸的。」而这些声音，其实都是我自己对自己的否定。

不久之后，公司组织经历了几次重整，导致有些小组虽然有后端需求，却缺乏足够的后端工程师。那时候的我才开始主动的去接触这些后端的开发，有些项目刚开始研究时真的很茫然，但只要敢问跟花时间，慢慢地就会开始对它感到熟悉，尽管自己还不是后端的专家，但至少不会在像是先前一样逃避，而只是把它当成是需要被解决的问题。

功能交付

在前一间公司，我其实从未接触过 A/B Test。当时的开发流程相对直线，所有功能只要项目经理评估没问题，就会直接进入开发并上线。直到加入现在这间公司后，我才开始真正接触到 A/B Test 的流程与价值。

由于我所在的团队是负责面向消费者的产品，因此在功能交付后，最重要的两件事通常是：错误监测（Error Monitoring）与观察 A/B Test 的表现。而后者是否成功，通常会依据项目经理在 One Pager 中定义的成功指标（Success Metrics）来判断。

• 若功能的目标是提升 GMV，那么就需要观察实验组（Treatment）在功能上线后的营收表现是否优于控制组（Control）。若表现显著较高，就代表这个功能的发布是正向的。
• 如果这项功能只是单纯的服务迁移，A/B Test 则可以当作一个功能旗标（Feature Flag），理论上 Treatment 与 Control 的表现应该趋近一致。若其中一组表现异常且具统计显著性，则代表事情不单纯，需进一步排查。
• 若功能目标是提升某个区块的点击率（CTR），则需辅以其他追踪工具进行验证，例如在程序中埋设事件追踪，搭配数据库查询，或通过第三方分析平台（如 Amplitude）观察点击比例与使用行为。

经过这三年的洗礼，也体会到了开发新功能时，真正困难的往往不在于开发本身，而是在功能交付后，如何有效地进行监测与验证。

当监测结果未如预期，我们又该如何找到问题并进行改进？这些工作不再是工程师单打独斗，而是需要与团队的数据分析师、项目经理密切合作，从数据中找出线索，看使用者对于新功能的使用行为，甚至重新思考与设计功能，整个验证与调整的流程，有时候可以比开发本身耗时数倍，但却也正是产品是否可以为公司创造价值。

Scrum Master

Scrum Master 这个职位是我加入这间公司后才认识的。这个角色的核心任务，是协助团队顺利执行敏捷开发流程。加入公司满一年后，我刚好有机会担任这个职位，也是在那段时间，开始与项目经理和主管有更多的交流与协作。

从规划每个冲刺（Sprint）的待办事项、掌握团队每位成员的 Bandwidth，与主管和产品经理讨论下一阶段的任务细节与所需资源，到将任务分配给团队成员，乃至于冲刺结束后的回顾与调整，这些都成为我在开发以外的日常。

同时，如何让项目的利害关系人（Stakeholders）清楚掌握团队目前的进度，以及在遇到紧急任务时该如何合理地插入冲刺中，这些都是需要花心思设计与沟通的。

举例来说，我会鼓励项目负责人每周将他目前的进度同步到相关项目群组，让主管或是项目经理能够保持在同个频率上。以及有突发任务时，先列出所有潜在插单的项目，厘清哪些是真正「紧急且重要」的事项，再经与主管和产品经理协调后，谨慎地安插进当期 Sprint。

通过这样的机制，我们才能在满足业务需求的同时，维持团队开发节奏的稳定，避免每次 Sprint 回顾时出现「插单失控」的局面。

不过对我而言，真正挑战的地方，并不是这些流程与规划，而是在于「人」的层面。比起分配任务，更困难的是：如何让每位团队成员清楚知道接下来要负责的项目？又该如何与主管讨论，是否有成员希望基于职涯发展的考量，尝试不同类型的项目？

以「让成员知道下一个项目是什么」为例，挑战常来自信息的不透明。多数时候，项目经理未必能提前提供下下个 Sprint 的需求规划，除了看着每个季度的 roadmap 观落阴以外，这时我通常会采取两种策略：

1. 增加需求预测量：主动与项目经理协调，请他们提供略多于当前 Sprint 所需的任务，让团队有余裕预估未来的走向。
2. 主动创造任务：与主管共同讨论团队有哪些可改善的内部流程或技术债，当成员手中的项目做完时，在等待下个任务的过程中可以顺边优化团队的系统。

总之 Scrum Master 这个角色其实还蛮有趣的，同时也可以加强自己的沟通技巧，在这段时间也通过这个职位学到不少。

其他想法

• 工作上的所有权 (Ownership)：

  这几年来，我对「工作所有权」有了更深的体会。无论职级高低，尽可能成为某个项目或系统的关键人物（Go-to Person），是提升自己在团队中影响力的最好方式。

• 帮助他人解决问题：

  这个过程本身也是学习的机会。很多时候，在厘清他人问题的同时，也让我对某些知识点有了更深入的理解。这不只是协作，更是双向成长。

• 刻意挑战自己，做那些觉得困难的事：

  成长往往来自走出舒适圈。当你开始接触自己不熟悉的领域，所学到的往往会远超预期。让自己成为一个说「我可以试试看」的 Yes Man，反而能加快学习速度，也让自己对未知少一点恐惧，多一点好奇。

• 把项目当成自己的孩子一样对待：

  每当负责一个新功能或项目时，尽量将它当成照顾小孩一样，除了自测以外，也加上功能旗标（Feature Flag）以便真的出事的时候，能够即时响应；功能上线后，也会进行实时监控，确保一切如预期运作。

总结

把这些零碎的想法写下来，也算是为这三年的历程做个整理。如果之后还有什么新的体会，再慢慢补上！

看着 AI 进步的速度，有时会觉得当前软件工程师这个职业是否会成为工业革命时的纺织工，毕竟当前的顶尖 LLM 模型在写程式的速度上是一般人的数倍，品质不差甚至更好，而现在我们所用的顶尖模型一定是未来最差的模型 😂。如果这个假设为真，希望这一篇文章不是《软件工程师记》的最后一集，即使未来的角色有所转变，我仍期待自己能在 AI 时代里，亲手用 AI 打造出一个让自己感到真正骄傲的产品。