阅读 10271

接口写好了,进度的锅都在前端?

前后端分离这件事绝对是好事,职责分离的同时,也意味着互相的进度不受影响,但真的是这样么?相信很多前端同学深受其害,有苦说不出,工作量不减反增。

前戏:工作量多了?多在哪里?

前后端分离之后,后端更多时候实现的只是对业务本身的底层支持,对外提供基本的接口基本是以下几种类型:

1 基本信息的查询与修改接口 2 流程流转的接口

而前端的工作量由原来的纯页面制作,工作量激增,包括:

  • 交互设计,尤其一些用户操作习惯、产品友好体验都在前端上
  • 各种奇怪的设备兼容,不同环境下的使用(网络环境)
  • 对接口的串联,对接口的调用,对接口各项数据的使用,当联调成本高的时候,你就像对接第三方一样(后端有不少接口是对界面不友好的,所以曾经一段内bff的概念炒的很火)
  • 对产品的理解,了解产品想达到什么目的,产品的逻辑接口是否匹配
  • 产品整体的功能自测
  • 后端接口的验收

后端接口写完了,然后就剩前端了?

这里先不讨论后端是不是真写好了,假定后端真的自测过了自己的单接口是通的,然后就把项目的进度和瓶颈认为都在前端这里,合适么?不合适!

首先,先澄清第一个概念,什么叫自己的接口写好了,你写的接口是自测通过了就算好了么?肯定不是,考虑下以下的问题:

  • 你的接口实现的功能和产品理解的一致么
  • 接口的出入参,是否符合前端的需求,自己不仅仅是功能的完成方,还要保证前端能以尽可能小的成本接入,而不是让前端一个手机页面,就调用5-8个接口,其中有不少不明所以的接口调用,就因为一个页面的不同字段来源于不同接口,或者就因为返回信息的某个字段是个key,你数据库没存就再提供一个查key-value定义的字典枚举接口给前端查。接口要以能完整的提供业务信息,完成基本的功能点为基本需求,而不是你怎么简单怎么解耦怎么来,对于后端来说,你想解耦,可以内部解耦,不用把这部分成本摊在前端上。
  • 是否利用接口完成了多场景,完整链路的测试,大多数情况下没有。大多后端会以最简单的场景下,完成单场景的单接口的单测就算自己通过了,实际等前端链条的时候,单接口以及接口串联上还有不少的问题存在。

其次,大家是一个团队,后端完成自己的工作并不代表,你就没有责任了,你能保证联调过程中,肯定不会发现你的任何问题么?如果发现了你的接口带来的问题,以及因为后端项目重启导致的问题解决的前端资源损耗,算是前端联调的问题么?

最后,ui、交互、细节的验收,大部分都卡在前端这里,甚至于后端都会来提意见说,你这里哪里哪里不好,因为看起来,前端做任何的改动都是时间成本最低的,而后端哪怕是做个小的功能变动都要增加额外的时间,让需求延期,但前端就很少能得到这样的话语权,这对前端来说,任何细节都会导致前端的工作量和压力的增加。而后端的部分,基本在联调环节后端和前端都解决90以上的问题了。所以在这点上,希望研发团队能给到前端一个合理的说法,能在ui、交互、细节上在前端工作开始之前就确认好,并避免过程和提测后的过度优化。针对这种,前端有权说:接受建议,但并不修改。

一个小案例:外门锁接口写好了的一波三折

一个外门锁接口写好了,就差前端联调了,然后来找前端,怎么?就差你没联调了,后端都自测过了,你啥时候提测啊?

涉及人员:后端负责人1,后端开发人员1,前端1 ,产品经理1

第一阶段:初期方案,方案判断影响范围,上海,判断城市 第二阶段:后端负责人觉得城市判断,太耦合,给外门锁设定为一个额外房间,产品不同意 第三阶段:产品同意并妥协了,前端按照此方案实现了 第四阶段:后端1 开发阶段自己额外定义一个接口,让前端去请求(与二阶段方案完全不同)。后端内部讨论变更方案,确定结果 第五阶段:和产品再讨论,产品、前端、后端确定使用变更后的方案。 第六阶段:前端按照新方案变更接口,变更字段,再次联调

所以在这种变更过程中,后端在第二阶段、第三阶段、第四阶段都说自己完成了接口,然后就差前端了,这种问题真的责任在前端么?恰恰因为后端对产品、对前端没有合适的交接,自认为的方案好了就算好了,就差前端你调下接口,调下功能了,你是代码写好了,前端代码还没写啊,凭啥你刚写好,就来催前端的进度如何??

我还想说

前端从需求评审、ui评审、交互评审、研发、接口联调、提测各个阶段,工作量都是不少的。

如果说真有差别的部分,只能说是研发阶段,对于复杂点的功能,后端工作量更大。但常规的业务开发,对于工作量这点,前端只多不少,ui的细节是前端的,交互细节是前端的,联调主要是前端调(后端基本是等前端提问题、等前端反馈什么情况下不行以及期望的数据是什么),功能测试基本是前端。虽然说功能的完成者是后端,但前端的工作真的是非常繁琐杂乱,并且从开始到最后,几乎要关注的内容特别多,只有研发的中期在等接口的空挡会稍微空一点。

所以针对前端来说,一定要把自己当产品经理,对产品有足够的把握,对各种交互、ui以及功能细节有足够的把握,沉淀解决方案,不要成为纯碎的接口调用者这样的角色,对于什么样的接口和后端服务能够让产品逻辑更加清爽,前端做的事情单一、可排查同样很重要。

原文地址:www.yuque.com/robinson/wo…

文章分类
代码人生
文章标签