5 月份加入了新的团队，全力为开源网关 APISIX 开发新的 Dashboard。「路由」模块属于 API 网关核心功能，它包含了：路由列表、创建路由、更新路由、删除路由四个部分，如何让该模块易用、表现准确成为整个 5 月份首要解决的问题。

由于是初创团队，我们尚且没有懂网关的职业产品经理与设计师，因此初创成员们通过频繁地讨论较明确地定了第一版功能。通过这篇博文，记录下来在第一版开发期间遇到的、想到的问题。

首先，作为中后台应用，我们选择蚂蚁金服体验部出品的 Ant Design Pro 作为脚手架与 UI 组件库，暂时不需要职业设计师介入。

其次，开发前确认清楚需求是至关重要的，由于前端开发者对 API 网关了解不深入，又没有足够清晰的产品原型，仅靠 GitHub 的文档是远远不够的，因此需要做 3 件事：

1. 体验 AWS、腾讯云、阿里云 为代表的 API 网关服务；
2. 及时地与熟悉 API 网关业务的开发者沟通，以 Route 为例，在确保对其流程清楚后，再动手开发。必要时，前端同学可充当产品角色，绘制流程图或制作简易版原型。
3. 开发过程中遇到不确定的地方，一定要及时确认后再继续进行。

在研发过程中，我认为编写代码是为了验证自己所学技能程度的，「想」比「写」应该更多一些，在考虑可扩展性的同时也请避免过度设计。

以 Route 创建/编辑 为例，它是由 请求基本信息配置、后端服务配置、插件增强配置 三部分构成的，显然地，我们使用步骤条便可以将这三部分串起来，此时会想到，可以增加预览页，它承担两个功能：

1. 汇总展示每个步骤页的数据，让用户知道自己最终提交了什么内容；
2. 将每个步骤的数据整理成 API 所需要的格式。

在操作过程中涉及到了数据流向的问题，相比于让每个步骤页独立保存页面状态、最终提交时通过一些方法进行汇总，不如为「步骤页们」增加父组件来管理状态。后者优势有：

1. 步骤页只负责 UI 展示，在适当场景下可被复用；
2. 由父组件统一管理数据状态，清晰明了，也便于步骤页之间的状态共享。

如上图所示，父组件作为状态源，将状态按需、单向传递给步骤页，在需要更新状态时，由子组件调用 onChange 方法将父组件中的状态更新。

Ant Design Pro 默认使用 dva 作为状态管理方案，但我选择使用 useState 方法在父组件中为每个步骤页创建 state 便解决了整个流程状态管理的问题。

此外，因初期产品设计不明确，在开发过程中难免会遇到奇怪的需求点，在自己确定后，应及时提出、讨论、视情况更正。

代码 Review

在提交 PR 后一定要亲自先 Review，没问题后再 Assign 给其 TA 人帮自己 Review。

首先应检查是否有错误拼写，对于不确定的单词请先查询再使用。

其次，代码风格是否与团队一致？

以命名为例，对于「获取路由列表」这个方法，使用fetchRouteList 或者 fetchRoutes 均可，但 fetchRoutesList 有些奇怪了。此外，「获取路由（单个）」使用 fetchRoute 即可，fetchARoute也可以，但略重复了。关于命名，在保证清晰的前提下，应尽可能短小。

此外，在个人”经验“与团队规范冲突时，除非该规范不合理，那么应以规范为准。

对于功能性 PR，应思考其设计是否合理？是否有过度设计之嫌以及是否漏掉某些不常见的情况？在开发前确定清楚需求、做好开发设计、想清楚边缘情况，通常可以减少该问题发生。

前端相关 PR，借助于 Netlify、Vercel 这类服务，可以方便地看到每一个 PR 的预览效果，推荐使用！使用时，注意：

1. 根据测试案例测试其功能是否完备；
2. 样式是否错乱？
3. 在不变更需求的情况下是否可以更美观、交互更顺畅？

在帮助别人 Review PR 时，设计风格或其它方面发生冲突时，与其以这是我的经验为由，不如向对方展示如何可以让其设计的更好？让对方心服口服。在风格上，参考知名开源项目的做法是一个不错的方式。

API 对接

在 API 对接过程中，其开发者理应更了解、熟悉业务。尽可能充分的测试案例是必须的，避免接口上线后前端反复测试发现太多本可以避免的问题，避免让前端作为 API 测试人员。

此外，由于前端是在前后端约定接口后进行开发的，因此 API 应尽可能按照约定来设计。若的确需要变更接口，务必通知到相关人员。

最后，在开发完成后，记得积极地与社区、用户进行沟通，了解用户真实的需求！