最近加入了一个 1000 多人的中型公司, 在做项目的过程中, 后端不愿意先协商接口定义, 坚持等他开发完后才给接口文档, 理由是先给接口文档, 实现的过程中难免有变动, 改动起来很麻烦.
而作为前端, 我的理由是, 产品需求文档以及设计稿已经具备的情况下, 先约定接口定义, 前后端可以并行开发, 提高效率.
几番交涉之后还是没有达成一致, 现在是他开发一个接口, 给一个接口的文档.
之前就职的小公司是开发前给接口定义, 所有人评审接口之后再开发的. 我觉得效率很高, 定义好的接口, 开发过程中的改动也只是简单的增减, 不会有很大的变化.
是公司规模造成的开发流程差异吗? 请朋友们说说
1
bangq 2019-04-18 22:43:29 +08:00 via iPhone
easymock 很方便,还是要提前约定的
|
2
zjp 2019-04-18 22:44:13 +08:00
我是这几天第一次和前端对接的新人...
公司现在的做法和楼主之前就职的公司一样,但是我在做实现的时候经常发现要改接口,前端也提了好几处修改...产品支持后端开发完才给接口文档其实对前端不是更有利吗 |
3
kevinlm 2019-04-18 22:46:39 +08:00 via iPhone 6
我是安卓,接了一个外包,后端让我们列出所需接口,然后他们才去写。妈的我想弄死他们,这帮鸟人压根不想动脑子。
|
4
zhuzhibin 2019-04-18 22:48:06 +08:00
应该是 先出接口文档 然后前端 mock 并行开发吧 最后才联调 ?
|
5
Chingim OP |
6
zhuzhibin 2019-04-18 22:58:07 +08:00
@Chingim 我各种场景都有经历过。。。 我是后端出身 之前公司是写完接口 补文档 同步给前端 后面也是因为效率问题 前端不可能干等后端接口 项目赶的时候 效率会差 所以才说了上面的那个方式 而如今 我自己一个人撸完页面 自己写接口 自己对接口 over 我要继续搬砖了
|
7
also24 2019-04-18 23:01:44 +08:00 2
先出全部详细文档的话,对后端来说工作量确实比较大。
工期确实紧张的话,我一般会建议先约定好大致的接口分类,和每个接口包含的大致内容(具体结构暂不约定),这样在前期就可以先做功能逻辑推演,及早发现问题;至于细节部分就留在开发过程中解决。 |
9
changdy 2019-04-18 23:07:43 +08:00
前后端都是个小菜鸟发表下自己看法:
前端属于所见即所得,不会涉及太多的状态流转。 而后端并不完全所见即所得,经常在开发过程中修改结构和实现方式。 一般来说越是逻辑复杂和初始阶段的项目,后端越难给定义。 不过前端也不算是等到后端有定义了才开始能写页面吧。刚开始的时候也可以写写样式 dom 结构等等.. |
11
kidtest 2019-04-18 23:08:34 +08:00
理想情况肯定是先沟通,两边技术对好方案,商量好接口,同步开发。但实际上两边的排期可能会有出入,所以,尽量不影响双方开发进度就好
|
12
Chingim OP @changdy 对于一些富前端应用, 其实并不是单纯地进行状态的展示, 也存在状态的变化.
没有接口文档也不是不能开发, 只是在开发过程中定义的各种数据结构可能和最终的接口相距甚远. 当接口出来之后要多加一层适配器. |
13
Chingim OP @kidtest 嗯, 可能是我的要求太过于理想了.
我决定在前端维护一套数据模型, 接口定义好之后再写适配器进行转化. 试试效果 |
14
hyyou2010 2019-04-18 23:34:13 +08:00 2
这里面很可能是一个怕背锅的问题,比如现在商定好了,但后端以后需要更改一下,他怕你把责任都推到他头上。只要大家都理解这个研发工作存在不确定性,告诉后端不用担心背这种锅就好了。
|
15
reus 2019-04-18 23:37:08 +08:00 3
需求确定了,接口就能写出来了,实现时改接口,说明需求没有搞清楚,或者根本就没有试过去理解需求,就开始做了,那当然要一边做一边改。
这种后端就是个坑货 |
16
ChefIsAwesome 2019-04-18 23:54:35 +08:00 via Android 1
其实就两种情况:
页面长什么样,接口就给什么样。一般这都是后端套了一层的结果。 接口跟页面不一致。前端自己拼出需要的数据。 前端开发的时候,只要把 getData 和 render 分开就行了。对 render 来讲,getData 只是一个函数,总是返回自己需要的数据。getData 里头你返回假数据也好,取真正的接口也好,取几个接口再拼出来结果都跟 render 没关系。这样就灵活多了。 |
17
AngryMagikarp 2019-04-19 00:01:15 +08:00 1
如果真的要先给出全部文档,而且是那种不更改的,那要花很多时间,而且也绝不是后端自己就能定的,还要参考前端的意见,不然到时候还是大概率要改。你就说说你们以前的迭代规模,接口评审花了多少时间,效果如何。
另外就算要推动这一流程,绝不是后端程序员的事,找你们的技术总监。 很多公司连产品需求都要改来改去,更别说是接口了。 再其次,既然需求已经定了。某种意义上前端自己也能设计出一套接口,你们完全可以按照自己的思路先做,正常情况下,你们自己假想的接口和实际后端提供的,应该只是结构不同(字段名等)。如果有很多出路,很可能是你们的产品理解就不同,赶快开个会统一一下。 反正我无论是做客户端还是服务端,都会积极推动接口规范。我觉得接口不是只是后端的工作,前端也要积极参与其中。 |
18
rizon 2019-04-19 00:06:44 +08:00
这种事情,事实话和你说:
如果工期紧张,肯定是先出 mock 接口的(有各种 mock 接口平台就是为此而生的)。前后端并行开发。但是开发中,接口绝对改来改去的,这个不全是个人能力问题,总之接口变动是必然发生的。 如果工期不紧张,那公司要是允许你们等到后台开发完再出接口,其实对你们有好处不用改来改去,踩的雷后端自己踩个差不多了没让前端一起跟着踩。但是等接口联调的时候,如果前端对接口不满意说是这种方式做不到,那后端就会很被动了。而且在这种时候后端接口还是会有可能发生变化的,原因很复杂,只不过不像先出 mock 接口那么频繁。 |
19
metrxqin 2019-04-19 00:08:04 +08:00
我是服务端。
新需求首先由我这边出接口文档初版供应用端开发参考,之后将服务端实现部署至测试服务器,联调过程中决定是否迭代接口文档。 |
20
Sanko 2019-04-19 00:25:52 +08:00 via Android
每次让前端给我写文档的后端小菜鸡路过~
|
21
Chingim OP @AngryMagikarp 所以先出接口文档,前端才能够从自身角度提意见,达成一致之后把坑都排除。
如果后端一直闭门造车,到时不能满足产品需要,变动起来岂不是更麻烦。 接口文档是前端参与接口建设的重要契机,如果开发完才提供,那就不是讨论,而只是通知了 |
22
Sparetire 2019-04-19 01:26:17 +08:00 via Android
以前公司都是前后端产品设计需求过完,后端花个一天设计接口,前后端再一起过一遍接口,定好接口文档,然后并行开发,接口偶尔有变动,但基本上变动不大,并且变动后及时更新接口文档通知对方
就这,我当时还觉得协作不顺畅。。看完楼上我想是我身在福中不知福 |
23
frandy 2019-04-19 01:34:37 +08:00
前端:原型图扫一遍 -> 画页面
后端: 原型图扫一遍 -> 抽取出给前端返回的数据和相关接口 -> 定义 VO->出 mock&实现具体逻辑 上面两者并发执行,之后联调,查缺补漏。 |
24
frandy 2019-04-19 01:36:34 +08:00
上面有提到出接口文档,emmm,有了 swagger,还要什么文档,代码即文档,具体不清楚的字段具体沟通。
|
25
dajj 2019-04-19 01:39:38 +08:00
按照经验, 首先技术方案确定,难点解决之后才能出第一版接口文档,
然后后期开发过程中,肯定要改动接口的。 那种认为需求定了,接口就定了,简直无知。 需求难道还规定了具体字段名? 举个例子, 页面中有个字段, 一开始想到用 英文 1, 后面发现其他人也用到,然后又改成 英文 2, 这是多么常见的现象。 如果前端不肯跟着变的话,我是不乐意先出文档的。 我觉得正常来说 开始开发前,可以先对前端页面进行讨论, 大概页面给几个接口,接口包含哪些数据。 后端做好开发设计, 解决难点和创建好数据库后, 可以给出大致的接口名和请求参数 后端初步开发完成后, 这时候可以给出具体的响应格式 最后联调阶段,再稍微调整接口 |
26
scnace 2019-04-19 01:47:30 +08:00 via Android 3
后端真是惨 明明是产品经理的锅 要被前端吐槽接口怎么老是改 /接口怎么还没给 还要被 DBA 怼这个人怎么老让我帮改表结构 被怼到可能还要被项目组 leader 说 block 项目进度…(互联网寒冬,请体谅下每一个还奋斗在一线的后端码畜 🌚
|
27
akira 2019-04-19 02:59:51 +08:00
1000 多人的中型公司 ,不会就你们 2 个研发吧,这个后端是典型的个人开发作风啊
|
28
fakeshadow 2019-04-19 05:49:45 +08:00
请问我这样前后自己来还不停改接口的,是不是逗逼。
|
29
ackfin01 2019-04-19 08:01:32 +08:00
怎么说呢,简单接口可以约定好定义,有些复杂的怎么给啊。所以一般是一部分给,让前端先忙起来,然后增量式开发完一个接口测的没问题给一个接口定义,这样增加效率,减少问题。
|
30
johnhsm2333 2019-04-19 08:04:51 +08:00 via Android
小外包公司提过无数次,但是后端接口写好了也不会写接口文档。每次开发都要被后端拖一拖进度。然后给骂。
|
31
hantsy 2019-04-19 08:36:26 +08:00
参考 CDC(Consumer Driven Contract) 开发, 首先一起协商,定义好前后端一致的 Contract,生成 stub。 前后自己各自做自己该做的事,自己实现,写测试去验证 contract, 前后端的工作可以说可以完全分开。
流行的 CDC 工具包括,pact.io 比较适合基于 REST/HTTP 的开发,语言支持丰富,另外 Spring Cloud Contract 比较适合 Spring 全家桶,支持更多协议,比如 AMQP,等。 后端开发过程中,部分成果可以部署到公司内部 staging 服务器(当然你应该在用 CI ),应该很容易提供 Swagger UI 的在线工具来查询 APIs。文档是什么鬼? |
32
luozic 2019-04-19 08:42:42 +08:00 via iPhone
码农,而不是设计或者软件工程师就是这么干的
|
33
passerbytiny 2019-04-19 08:43:00 +08:00
请问,你们的项目经理 /开发主管 /系统工程师呢?没有这些,1000 多人跟 5 个人没啥区别。
|
34
justfindu 2019-04-19 08:44:54 +08:00
我都是先给接口文档. 整理接口文档就是整理自己思路. 然后前端模拟.
|
35
Antihank 2019-04-19 08:50:15 +08:00
请问阁下以前就职的小公司是哪家方便说一下吗,我准备一下面试材料。。。
1000 人的公司确实不应该了,开发团队规模是不是跟得上另说,小公司产品改来改去的哪有文档这么奢侈的 |
36
Cbdy 2019-04-19 08:54:26 +08:00 via Android
我是一个“前后端分离”的反对者,前后端最好由一个人开发,效率高
|
37
yxcoder 2019-04-19 08:55:20 +08:00
表示一直做有接口适配,随他怎么改接口
|
38
lihongjie0209 2019-04-19 08:56:07 +08:00
@reus 一个需求可以有 N 种实现,具体选哪一种是由开发人员,开发进度共同决定的,并不是说需求定好了, 代码基本也确定了
|
39
bojackhorseman 2019-04-19 08:57:55 +08:00
我都是先写好页面,然后再和后端对接口。如果页面画完,接口还没出,就可以光明正大地摸鱼了(逃)
|
40
reus 2019-04-19 09:00:38 +08:00 1
@dajj 需求确定了,后端就可以根据需求写接口,接口就是传什么参数,返回什么,字段名是后端决定的。接口写好了,后面不是十分需要的话,是不会改字段名的,因为前端可能已经把字段名写入代码里了,你改名字,就是给前端添不必要的麻烦。其他人用了不同的字段名,就是因为你不肯先出文档,所以你才会认为“常见”。不好意思,先写文档的,根本就不会碰到这种破事。
另外,前后端分离的架构,接口应该是各种对象的 CRUD,加上一些特殊用途的,不是根据页面来的,根据页面那就是前后端耦合了。所以写文档,就是对业务本身的建模,主要是定义对象的字段等等,相当于后端的初步开发了,甚至可以根据字段定义自动生成文档。如果你的接口是按照页面来分,那页面需求变了你的接口也要跟着变,这就不是前后端分离的架构了,开发效率自然就低了,没法前后端并行开发的。 |
41
lihongjie0209 2019-04-19 09:03:58 +08:00
前端先写静态页
后端先设计表结构 然后就一个具体的功能点二者一同开发,这样后面的联调就比较简单了 |
42
reus 2019-04-19 09:05:03 +08:00
@lihongjie0209 我说的是前后端共同遵守的接口约定,参数是什么,返回是什么,先定下来,怎么实现是后面的事情。例如一个加法接口,参数就是加数和被加数,返回另一个数,文档就是参数叫什么名字,例如 A, B,怎么传,post josn 还是 query string 还是都支持,返回的是什么结构,等等。至于后端怎么实现加法,这个前端不需要关心。
如果你连要做的是加法而不是乘法,参数是两个而不是多个,都不能确定的话,那就是我说的“需求未明确”。 |
43
Aprilming 2019-04-19 09:07:05 +08:00
我们公司都是前端把静态页面写好,搞点假数据,后端负责后端开发以及前端的数据渲染。
|
44
Godykc 2019-04-19 09:08:10 +08:00 via iPhone
服务端进度领先前端一个迭代周期
前后端分离完全可以错开啊 |
46
reus 2019-04-19 09:09:58 +08:00
@lihongjie0209 你把“表结构”换成“参数和返回”,写下来,就等于是给了文档了,前端就可以把字段写进代码了,表结构那是后端实现阶段的事情。
|
47
lihongjie0209 2019-04-19 09:10:17 +08:00
@reus 想多了, 你数据不按照页面的需求给, 前端不得骂死你?一个展示页面需要调用三个接口来组装数据?后端可以把接口设计的尽量通用,但是前端的复杂度就上升了。
WEB 层和页面耦合那是必然的,WEB 存在的意义就是展示页面。 我们要避免的是核心业务对象和展示层的耦合 |
48
wweir 2019-04-19 09:15:37 +08:00 via Android
没有任何技术难度的项目,咋搞都行,推荐做法是后端负责人写接口文档草案,前、后端、测试等所有相关部门审阅后人手一份,基于文档进行开发。
有(后端)技术挑战性的项目,后端现行,开发出大致解构后,前端再参与开发。前端初期更多应该是理解业务、简单画界面、设计交互(划重点)。 |
49
lihongjie0209 2019-04-19 09:17:04 +08:00 1
@reus 你要把所有的接口定下来, 那就意味着你要做出很多假设, 而且这些假设会有依赖关系, 一旦其中的一个假设改变, 那么会导致一组假设全部失效,那也就是说你的接口全需要改。
需求是确定的,但是开发员人对需求的理解是随着开发慢慢增加了, 你期望别人在项目开发前就理解全部的需求并且不产生任何误解,我能想到的也只有简单的 CURD 了 |
50
a0000 2019-04-19 09:18:19 +08:00 via Android
我们公司是需求确定好,后端先定义接口,客户端确认有没有什么问题,没有问题,后端造假数据,让客户端先用着。并行开发,10 几个人的小团队
|
51
a0000 2019-04-19 09:21:11 +08:00 via Android
我们不是所有的都列出来,按界面出接口,边写边出,理想状态是后端不影响客户端开发
|
52
owt5008137 2019-04-19 09:21:31 +08:00 via Android
一般来说我是会先给接口,再实现功能。不过不排除中间会调整的可能性。
|
53
Chingim OP @frandy
@hantsy swagger 暂时没见使用。这个可以慢慢推,不用 word 我已经知足。 @passerbytiny 产品和项目管理同意延长工期,所以就没再探讨了。 @Antihank 以前公司确实开心,swagger/postman/zepin/Invision/asana/circleci/quip 各种服务各种协作工具,可惜产品赚不到钱 @yxcoder 适配也是一种办法,但是不能推进接口的规范化 |
54
reus 2019-04-19 09:31:27 +08:00 2
@lihongjie0209 那这就是你们的架构的问题,你们还活在前后端耦合的蛮荒时代。一个页面调几次接口也算问题?
后端当然会组装数据,但这些数据是符合“模型”,而不是符合“页面”。例如时间字段,返回的就是时间戳,不是 YYYY-MM-DD 之类的具体格式,因为前端可能需要显示的是“ xxx 前”。关联的数据也可以通过复合的字段返回,尽量减少前端的组装工作。现在的前端复杂度本来就是上升的,早就不是单纯写 css + html + jquery 的时代了。有时接口数据不复合需求,需要组装一下,是常见的事情了。前后端耦合,整体来讲就是低效率的。根据页面分接口,那多个端的,你也另外做一套? 后端服务的对象不是单纯的“ web 层”,web 只是前端的一种。移动端你另外写接口?小程序你另外写接口?内部调用你另外写接口?人力不是这么浪费的。 |
55
ala2008 2019-04-19 09:31:55 +08:00
小公司,后台先出文档,前后端初步同意,进入开发。有修改或缺,及时补上。整个过程是保持沟通的
|
56
reus 2019-04-19 09:38:42 +08:00 1
@lihongjie0209 你以为 CRUD 简单?能把复杂的业务模型整理成纯粹的 CRUD 接口,给前端调用,这就是后端架构功力的体现。
要做“假设”,说明需求还没有厘清。厘清了,就不需要假设。整理需求直到接口显而易见,本来就是开发的正常过程。何况题主已经说了“产品需求文档以及设计稿已经具备”,设计稿都出来了,你还想怎么大改?产品设计可能改,这就是你不先整理接口的原因? |
57
yogogo 2019-04-19 09:56:19 +08:00
我们是前端先画页面,后端同时写接口,前端画完页面,后端也差不多写好接口了,然后联调。
|
58
AngryMagikarp 2019-04-19 10:12:47 +08:00 1
@reus 接口完全不照顾页面,那么前端(尤其是移动端)用起来会很难受。比如一个页面有三张表的数据,可以使用三个接口,但那样前端就要考虑先调用哪个,先展示哪个,还是全部调完再展示。这个也跟 UI 设计有关系,UI 说要一个 loading 一起展示,还是三个 loading 分别展示?因此接口不可能不照顾页面设计,那样做的才是真正的坑货。
多个端写多种接口很正常,很多应用多端的需求本身就有区别,就算当前没有区别,以后也很可能会有区别,分开容易维护。我遇到两端用同一个接口的情况下,我也会提供两个 URL 给他们分别用,但内部实现是同一套代码,这样方便以后改。内部调用更是一定要另外写接口了,都说了是内部调用怎么可能和外部接口用同一个? 接口在正式上线前变更字段很正常,只是上线后不改。一旦上线,做的也一定是兼容的更改。 你说的那些接口约定其实前端自己也能定,为什么必须后端定?前端就没有看产品需求?显然不是的,归根到底是市面上 90%的前端都不具备这个能力,因此就强依赖于后端。时间多的话,完全可以让前后端都出一套接口方案,然后开个会统一一下。那样就没有任何问题了。接口是前端和后端通信的方式,并不是后端说了算的,把接口设计的责任完全推给后端也是推卸责任的行为。 就你说的那个时间戳格式问题,我遇到过多少个前端都希望后端替他们返回“ XX 前”格式的。现实中那种真正为技术考虑的人少之有少,大部分人都只是想减少自己的工作量。这点不分前后端。 我的观点是:做一个“差不多”的接口文档是没多大意义的,因为这个东西开完产品会议前后端脑子里都应该有。做一个“完备”的接口文档则要投入很大时间精力,(前端也要参加!)并不值得,如果你们公司并不在乎的话也可以搞,不过这是公司上层决定的事,没必要针对后端程序员。 |
59
Chingim OP @AngryMagikarp 其实我也不排斥前端出接口, 但是很多后端的接口跟数据库是耦合的, 如果前端出具的接口跟数据库表结构 /字段命名 /字段类型相去甚远, 那后端能接受吗?
我是赞成前端参与接口建设的, 但是如果没有开发前的接口讨论, 那么很难说什么接口建设. |
61
guyujiezi 2019-04-19 10:26:06 +08:00
那个开发没有听说过 TDD 么?
开发完再给接口,也太随心所欲了 |
62
ryonanamizu 2019-04-19 10:45:24 +08:00
@kevinlm 我宁可这样
|
64
Gea 2019-04-19 10:46:18 +08:00 1
小公司,小业务,当然可以先出文档了,如果业务足够简单,不需要看之前的代码,不需要调用其他服务,评审会上都能给出接口定义,如果你现在的公司是这样的,那喷一下后端我觉得有理。
大公司,复杂业务,前端状态复杂,后端也要多服务调用,你一开始给出接口定义,到最后开发出来可能完全不一样,或者很大一部分不一样,再调再改的话,接口定义很没意义也很蛋疼。 其次,写一个接口给一个接口文档提供给前端,你自己都不觉得很打乱开发节奏吗,后端要做的是: 看之前的代码=>结合需求,做业务 balabalabala=>提供文档,再循环往复。需要反复的思维转换,我觉得很影响开发效率。 最后我觉得还是看业务的情况,公司规模大小。一个前端转后端,小公司大公司都待过的我是这么觉得的 |
65
Alex5467 2019-04-19 10:46:55 +08:00
@AngryMagikarp 同意加一
|
66
AngryMagikarp 2019-04-19 10:48:33 +08:00 1
在某些人眼里,产品需求明确了,接口文档下一秒就应该出了,不出就是能力不行。
在实际中,只要不影响开发进度,我并不关心他什么时候出。很多时候都是可以先作页面的,大部分简单的接口后端也能在前端需要之前就给出。一个项目的开发是多方面的合作,而不是谁要顺着谁。如果后端接口开发真的慢,也应该反应到上级,才能让他们调整开发流程。 互相理解互相帮助,及时沟通才是正解。当然这是理想情况下。 |
67
DavidNineRoc 2019-04-19 10:50:01 +08:00
我感觉楼上是不是理解错了? >>>前端不得骂死你?一个展示页面需要调用三个接口来组装数据?>>>
一个页面只给一个接口的真是神人, 我只能这样说. 我司的做法: UI 出设计图 => 前端画页面 && 后端写接口 ==> 后端给接口文档 && 前端渲染数据 ====> 稍后不同步, 前端做其他模块的页面, 后端开发其他模块的接口. |
69
AngryMagikarp 2019-04-19 10:53:21 +08:00
@DavidNineRoc 我随便举了个例子,说一个页面三个接口的情况,你的理解就是一个页面必须一个接口?你的阅读理解才是神。
|
70
reus 2019-04-19 11:08:16 +08:00
@AngryMagikarp 我可没有说完全不顾,像一个页面需要三个接口的数据,那一起发过来,一起返回,甚至做更复杂一些的处理,都不是什么大问题。一次请求对应多个接口调用,这个可以实现成通用的机制。
内部调用和外部调用的方式可以有不同,但基本的参数和返回字段,难不成还用不同的?总得提前决定吧,后端之间也等实现了,才来改字段名或者加适配层? 接口可以有通用的,就是一堆 CRUD 的,可以有非通用的,例如只给某些页面或者终端用的。通用的,在初期就给出文档,不难吧?非通用的,可以在后面根据需求增加。至于前端还是后端写,需不需要讨论,这些都不是重点。楼主说的是后端在“实现”了接口之后才给文档,你真的觉得这样合适? 要加个格式化的时间字段,也不是大问题。注意是“加”,不是“改”,后端加了,你想用就用不想用就不用,不影响协作。 这一套流程不是我发明的,这里其他人一样有使用同样流程的。我们用得轻松愉快,不然楼主也不会发帖了对吧? |
72
Gea 2019-04-19 11:10:12 +08:00
还有让返回 xx 前的?数据完全不复用?完全不能二次使用,只用来渲染?客户端性能全部用来渲染,不做一点计算,全部交给服务端计算?
|
73
atonku 2019-04-19 11:19:32 +08:00
@Sparetire 你这明显不是套路啊,应该是这样的:
后端花个一天设计接口,前后端再一起花一天过一遍接口,定好接口文档,然后第三天上线。 |
74
DavidNineRoc 2019-04-19 11:20:09 +08:00
@AngryMagikarp 说话不能好好说, 动不动就阅读理解有问题, 自己阅读理解有问题吧? 自己把 三个大于号之间的文字复制,搜索. 看我是和你说还是和另外的人说. 这是理解障碍?
|
75
reus 2019-04-19 11:21:42 +08:00
@AngryMagikarp “大部分简单的接口后端也能在前端需要之前就给出”,这不就是楼主想要的吗??问题就在于楼主连这个都拿不到,完全等后端开发完接口了,才有!
|
76
reus 2019-04-19 11:34:29 +08:00
@AngryMagikarp 我希望你能理解“能写出来”和“下一秒就应该出”的区别。
|
78
aa1072551507 2019-04-19 12:01:13 +08:00
在我的小公司 都是我前端写先完页面 然后我把需要的接口格式写文档给后台人员 最后后天才开始写接口哈哈....
|
79
IvanLi127 2019-04-19 12:04:22 +08:00 via Android
这人数。。直接怼,没文档你没办法开发。或者你约定 api 文档,重新调整人员分配。编码明显是在这些东西之后的,他反驳你,你就质疑他专业能力
|
80
947211232 2019-04-19 12:17:02 +08:00
理应新定好接口再开发
|
81
rockagen 2019-04-19 12:42:05 +08:00
前端还是图样图森破,对一个 http 业务请求到后端的复杂度一无所知,按你们的公司的人数来看的话,内部系统应该是解耦合的,后端拿到需求是要去其他部门沟通 RPC 接口的吧,只能说后端能先实现大体流程,保证业务能跑通的同时输出接口,细节部分放后面去优化。好了,我要上台拿衣服去了。
|
82
lihongjie0209 2019-04-19 12:42:26 +08:00
@reus 就一句话 多个接口怎么保证事务?
后端把 post 拆分为 post1 post2 post3, 前端怎么做事务? |
83
lihongjie0209 2019-04-19 12:53:34 +08:00
@reus 不好意思, 我们多端还真是多个接口的, 我们只需要保证核心的领域逻辑不变, 适配任何端都是可以的。
至于你说的 web 和页面耦合, 我这套接口就是给 web 页面做的, 只要由这种需求,那么我也会把 xxx 前 返回给前端, 因为类似小程序你要改 UI 还需要重新发布。 |
84
lihongjie0209 2019-04-19 12:54:46 +08:00
@Chingim 套一个 DTO 的事情
|
85
reus 2019-04-19 13:01:26 +08:00
|
86
xuanbg 2019-04-19 13:07:39 +08:00
当然应该先定文档再来按文档实现咯,你们的后端太菜,缺少自信。
|
87
sichuyoudang312 2019-04-19 13:07:46 +08:00
同 23 楼
|
88
reus 2019-04-19 13:08:43 +08:00
@lihongjie0209 “套一个 DTO 的事情”,说得轻松,假如有上百种类型,每个类型平均 10 个字段好了,那就是上千个,一个个手工适配?本来不需要干这种活的,就因为后端不肯先约定接口,就要做无谓的工作。
|
89
lihongjie0209 2019-04-19 13:14:00 +08:00
|
90
lihongjie0209 2019-04-19 13:14:55 +08:00
@reus 代码生成了解一下, 本来把数据库的结构暴露给前端就是一个很 sb 的事情
|
91
alakey1989 2019-04-19 13:24:57 +08:00
@Cbdy 可爱
|
92
Chingim OP @lihongjie0209 你太理想了,接口字段名称 /类型和数据库耦合是常见的(虽然很不合理)
曾经沟通过接口字段的语义化,被“数据库里就是这么存的“搪塞过去了 @rockagen 接口是对外的服务,应该隐藏所有内部的复杂性不是吗?如果因为技术不可行,那在产品评审阶段就砍掉需求了。如果有调研的需要,那这部分前后端都可以暂停开发这部分功能。其余部分的接口还是可以先协商的吧? |
93
kulove 2019-04-19 13:28:27 +08:00
开发完再给接口定义,不然难免会有改动且会有考虑不周的地方。
应该是后端对照产品原型开发,同时 UI 设计,基本 UI 图给到前端的时候后端接口也开发完了。 |
94
Chingim OP @kulove 那如果开发完发现对需求的理解有偏差呢,那岂不是推倒重来。开发前协商接口,其实就是统一了对需求的理解,双方都有照亮认知盲区的机会
|
95
lihongjie0209 2019-04-19 13:34:07 +08:00
@Chingim 字段名称和我说的数据库结构是两回事
数据库结构是你的表结构是怎么设计的 如果把表结构对于的实体类直接返回给前端, 那么前端拿到的数据会有很多冗余,并且嵌套层级非常深 我一般的做法就是按照 UI 图单独定义一个 Response 类,返回一个扁平的对象,这样做的好处 1. 网络传输的数据少 2. 客户端只依赖于 Response, 不依赖于我的数据库结构 3. 前端写起来简单一点 |
96
reus 2019-04-19 13:34:08 +08:00
@lihongjie0209 你这个接口的逻辑,可以用一句话概括:doX,然后根据条件判断是否需要发通知。一句话能概括,那当然能一个接口实现,加个条件判断而已啊。前端有的用户想发短信,有的不想发,你也拆两种接口?有的用户想发短信,有的用户想发邮件,你也拆两种接口?这是一个功能,不是两个功能。
我觉得你根本就没有理解,我说的是接口的参数和返回,从来没有说“数据库的结构”,接口字段和数据库字段,不是必须对应的。代码生成有什么用?你前端用了 gender,结果后端接口用了 sex,代码生成怎么直到这两个字段是对应的?还不是要一个个对。 |
98
lihongjie0209 2019-04-19 13:36:17 +08:00
|
99
reus 2019-04-19 13:38:10 +08:00
@lihongjie0209 所谓的“给接口定义”,就是你把 Response 类的定义写出来之后,就给前端看,让他知道这个对象长什么样,就这么简单,后面你再实现。这样前端后端就可以达到题主说的“并行开发”。
|
100
kulove 2019-04-19 13:38:23 +08:00
事实上,开发完成后给接口文档并不怎么会产生偏差,如果经常有很大偏差,要么是默契度不够,磨合一段时间就好了,要么就是太菜。
|