前端业务开发

前端业务开发的通用经验(二)

参考资料


接口复用导致的问题

有三个层面的复用,会面临不同的问题,分别是:跨项目复用、跨页面复用、跨端复用。

1. 跨项目复用

通常是因为新开项目需要紧急上线,为了求快,直接在新项目里复用老接口,说是后面要拆,但大概率没时间拆,后续新项目的需求迭代会前赴后继的加入老接口里。等到因维护、交接、组织变动、项目拆分等原因导致接口必须独立和迁移的时候,必将付出成倍的成本。

复用的基本前提是【同步】,只要不同步,复用就一定会变成多套逻辑的杂糅。既然已经划分项目了,那么业务逻辑大概率是不同步的,如果同步,应该考虑抽成公共服务。偏离了正确的设计,早先欠的债/偷的懒最终一定会加倍偿还。

2. 跨页面复用

通常是某些公共配置,比如每个页面都需要的前置信息,因为存在重叠,就全部融合到一个公共接口。这将导致某一个页面如果要单独增加配置信息,就不得不继续加到公共接口里,越到后面,公共接口的逻辑越膨胀,性能越差,所有页面都受影响。而且公共逻辑的维护成本和变动风险也越来越大,一是历史逻辑越堆越多,就算看不懂也不敢改;二是一旦出错,就是所有页面全挂。

接口设计上,复用的层级应该降到微服务层,然后单独为每个页面提供各自的接口。

3. 跨端复用

接口一旦有 native 端使用,就应该视为“被封印”的接口,因为通常后续开发只能加字段,不能删字段,也不能改字段(除非接口作版本控制)。一定程度上这给前端带来了某种好处,因为很多时候前端可以凭此特性,强势要求把逻辑挪到后端:“因为咱 native 有版本问题,不能改 😁”。哈哈,其实更合理的理由是:跨端复用。

接口格式不统一的问题

这估计也是个行业普遍的老大难问题,有个老兄在微信四面还是五面的时候就被问到过。前端作为聚合各类资源的生产链终端,只要对接超过 1 个后端团队,大概率会遇到这个问题。具体表现有:

  • 数据格式不一致。主要是状态码和异常信息的定义不一致,比如状态码,用哪个 Int 表示【正常】无法统一倒也罢了,连用 Int 表示状态码都不见得统一,竟然有字符串格式的数字
  • content-type 不一致,有的 form,有的 json
  • 参数位置不一致。有些 post 接口偏要在 query 里取参,有些接口遵照 restful 规范把参数定义到了 path 里。明明可以也应该从 cookie 里取的参数偏要在请求时传参
  • 多种不同的异常,共用同一个状态码

面临上述问题的情况下,请问公共的网络请求方法怎么封装?

约定往往解决不了问题,因为约定根本没有约束力,而且你不见得有那个权力,有这个权力的人不见得关心这个问题。

如果按照【谁痛谁解决】的原则,前端自己写接口,肯定会增加工作量和维护成本,对人要求太高,除了大厂里少数团队外,在其它地方大概率搞不动(小公司另说,可能总共就一个后端团队,或者前后端没分那么彻底,不存在数据格式不统一的问题)。当然前端可以参与接口的定义,对接口提要求。

一种解决思路是:网络请求 request 方法,做成可配置的。比如:

const requestServiceA = new Request({
    contentType: 'json',
    normalStatus: 0,
    commonParams,
    host
})
const requestServiceB = new Request({
    contentType: 'form',
    normalStatus: 200,
    commonParams,
    host
})

还有一种思路是:在网关层做一次适配改造。

字段复用与二义性问题

假设有三个页面用到了同样的内容,复用同一个字段是否合理?是否复用同样取决是否【同步】,假设这个内容是在后台配置的,那么修改配置的人,知不知道改了这个配置,不仅会影响到页面 A,还会影响页面 B 和 C?假设页面 B 的内容要换成另一个怎么办?

以“提高效率、省事”为理由的复用,大概率是会出问题的。

另一种类型的复用,是语义上的复用,这个问题就更大了。举个例子,假设公交卡有三种类型:普通卡、学生卡、老年卡,普通卡都是余额,学生卡都是次卡,老年卡都是免费卡,那么能用【卡类型】来判断【计价模式】与【是否免费】吗?

const isFree = cardType === '老年卡'
const isPayPerUse = cardType === '学生卡'

如果你这么做了,需求一定会出来狠狠打你的脸,一定会出现非免费的老年卡、以次数计价的老年卡、以金额计价的学生卡。

每个字段应该只具备一个语义,不要用一个字段干两件不同的事情。

接口请求的防重、节流和竞态问题

如果一个按钮只是绑定了请求事件,没做任何处理,那么短时间咣咣点击,连续发送多个异步请求,很容易出问题。如果是 create 型接口,那么会导致重复创建;如果是 get 型接口,那么可能遇到竞态问题

原则上,非幂等接口,要考虑防重;幂等接口,要考虑节流和竞态处理。

posted @ 2020-12-16 22:08  zc-lee  阅读(244)  评论(0编辑  收藏  举报