《软件工程师记》EP.2: 街口支付

前言

上周 LinkedIn 突然跳出了通知，写着 "OOO, liked your work anniversary". 回想起来，从开始写第一段程序到当工程师已经满一年了，这个过程充满着幸运，也许值得记录一下。

如果还没有看过第一篇，可以先看看 《软件工程师记》EP.1: 从零到一。

这一年我学到了什么

回想刚进公司的自己，还只是个做过几个简单作品、对真正的软件工程与团队协作毫无概念的菜鸟，当时的蠢样至今仍历历在目，虽然一年又过去了，看起来好像也没好到哪去（？）。

初创公司的迭代速度非常快，往往没有太多时间能手把手地带新人。加入团队不久，我便接下了人生中第一个项目。这段经历迫使我快速成长，也让我学到很多。非常感谢当时愿意信任我的主管，以及这个充满挑战的环境。

一年下来，我陆续参与了四个项目，虽然规模都不算大，但要在有限的时程内完成，对当时还什么都不太懂的我来说压力山大。为了赶进度，我几乎天天加班，差点就睡在公司了。而以下是我总结出来的心得:

技术

模块化 UI 组件

刚进公司的时候，我在 UI 开发这部分非常不适应。进公司之前，我从来没有接触过「组件复用」或「CSS-in-JS」的概念，更没听过 Storybook 协助开发与测试的好用工具。记得第一次和后端同事讨论 API 数据格式时，光看到他传回的变量名称和我预想放进组件参数的名称不一样，就让我当场慌了，还跑去问主管：「这样我要怎么办？」

毕竟以前做作品都是自己开 API 自己接，没合作与标准流程，更别说团队协作了。老实说，那时候我真的有点搞不清楚自己来干嘛的 🫥。

一年后，我参与了组件库的建置，从一开始四、五个共用组件，慢慢累积到二十多个。在这个过程中我学到，一个好用又能被重复使用的组件，不只是把画面做出来而已，而是需要和设计师充分沟通，了解设计的逻辑和实际的使用情境，在拿到最终设计稿后，写出一个既有弹性又能延伸使用的组件，并根据实际使用的情况进一步优化。

React & Redux

目前项目的技术栈都是用 React + Redux，一开始根本不知道同一个组件底下 React.useEffect 可以放多个，也不知道 Custom Hooks 是什么东西。

还记得开发第一个项目的时候，因为对这些概念一无所知，干脆就把所有东西都塞在同一个文件里 从 UI、逻辑到数据处理通通混在一起，最后整个文件超过上千行，完全失控。这份代码在被主管审阅后，就被宣告无法使用了，被主管要求全部重写，也拖累到主管假日跟我一起加班 Q_Q。

一年后，我逐渐掌握了 React 的各种 API，也开始在开发过程中思考效能与架构设计。像是会评估某段逻辑是否有必要使用 React.useMemo 或 React.useCallback 来优化；也会在撰写时注意组件的 re-render 行为，让程序更干净可控。

此外，我也开始熟悉如何使用 React + Redux 搭配 Formik 与 Yup 来处理复杂、多页的表单流程，包含表单验证、数据管理与错误提示等细节，让整体用户体验更顺畅。

目前则是负责的迁移旧的 MPA 项目到 SPA，也让我更深刻体会到当一个平台逐渐扩展时，所需要的抽象化与模块化设计能力，如何在灵活性与可维护性取得平衡，是我现在特别关注与学习的方向。

代码质量

以前写程序只求「能动就好」，完全没有程序设计的典范概念。现在回头看自己几个月前写的代码，就会觉得非常痛苦，副作用满天飞、命名混乱、可读性差、几乎没办法扩充。

现在则是努力将一个函数可以让审阅代码的人在几秒内看懂，开始使用函数式编程的概念，减少程序的副作用，训练自己的抽象化能力，让程序可以复用以及扩充。

也在部分项目中导入测试流程，实践过 TDD（Test-Driven Development）与 BDD（Behavior-Driven Development）。这样做的好处是：能在开发前就先厘清产品需求与使用流程，同时也能避免自己写出一些基本错误的 bug，当程序进入测试阶段时也能更有信心。

产品开发流程

软件开发中，任何一方的延迟都可能导致整体时程延宕，而这对前端特别明显，因为我们极度依赖设计与后端的交付。如果大家都压线交付，最后承压的一定是前端。那么，当我们看完开发文件后，设计图还没定稿、API 也尚未完成时，该怎么办？前端总不能等所有条件就绪后才开始开发，那一定来不及交测。

面对设计图未定的情况，我会先根据已知需求产出所有页面结构与基本 User Flow，并与项目经理反复确认流程是否符合预期，快速调整方向。如果有导入 BDD，可以先把 feature spec 与项目经理对一次，并同步实作初版页面版型，让整体流程有个清晰雏形。

至于 API 尚未完成时，我会主动与后端工程师讨论是否能先提供初版 API 文档。只要有规格，我就可以使用 Mock Service Worker（MSW）进行 API 模拟，这样至少能模拟页面基本的操作、后端回传格式，甚至预演错误情境的处理。

通常等这些初步工作都完成后，实际设计图与后端 mock API 也会陆续就绪，这时就能迅速补上剩余逻辑与细节，并尽快上到测试环境进行自测，确保整体流程顺利推进。

沟通技巧

良好的沟通能大幅减少开发过程中与其他团队之间的认知落差，对时程掌控与需求对齐都非常关键。例如：

• 与项目经理沟通时，需要清楚争取合理的开发时间，并确认功能是否真的是他们所预期的样子，避免开发方向走偏。
• 与设计师协作时，要讨论组件设计的可行性，理解设计背后的逻辑，并确认我们实作出来的 UI 是否能满足他们对细节的期待。
• 与后端或移动端串接时，则需要厘清 API 或 WebView 函数的定义与整合方式，确保两端对接顺畅。
• 向主管汇报项目进度时，要能简洁清楚地说明目前的进展、遇到的问题、解法，以及团队讨论后决定采行的策略。

这些情境都需要不断地沟通与协调，才能达成双方都满意的结果。直到现在，我仍在学习如何在这些协作中更有效率、更有同理心地传递信息。希望未来能更加从容地处理各种沟通挑战，让每一次合作都更顺利。

结语

一年前加入这间公司时，公司的网页前端团队还处于草创阶段，只有我跟主管。组内的开发文化都还尚未成形，从项目的开发到 Nginx 建置与项目的发布都是弄脏自己的双手去摸索出来的。这过程会踩到无数多个坑也犯过无数个错，前期压力或许稍大，又或许没有所谓的休假日，但当问题是由自己的双手解决时，心里的成就感真的是无法言喻。也感谢主管以及各组的同事们，总是愿意回答我无知且基础的问题。到现在网页前端团队已经有五位成员了，而且同事们个个都是高手！