记在新团队首次协作开发后

琚致远 

2020-06-07

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. 由父组件统一管理数据状态,清晰明了,也便于步骤页之间的状态共享。

image

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

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

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

代码 Review

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

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

其次,代码风格是否与团队一致?

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

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

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

前端相关 PR,借助于 NetlifyVercel 这类服务,可以方便地看到每一个 PR 的预览效果,推荐使用!使用时,注意:

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

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

API 对接

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

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

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