这是一个创建于 2044 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近加入了一个 1000 多人的中型公司, 在做项目的过程中, 后端不愿意先协商接口定义, 坚持等他开发完后才给接口文档, 理由是先给接口文档, 实现的过程中难免有变动, 改动起来很麻烦.
而作为前端, 我的理由是, 产品需求文档以及设计稿已经具备的情况下, 先约定接口定义, 前后端可以并行开发, 提高效率.
几番交涉之后还是没有达成一致, 现在是他开发一个接口, 给一个接口的文档.
之前就职的小公司是开发前给接口定义, 所有人评审接口之后再开发的. 我觉得效率很高, 定义好的接口, 开发过程中的改动也只是简单的增减, 不会有很大的变化.
是公司规模造成的开发流程差异吗? 请朋友们说说
第 1 条附言 · 2019-04-19 17:52:56 +08:00
我不是求认同, 也不需要 v 友站队.
我想要的是: 充分了解其他公司的协作流程, 充分了解其他后端同事对出具接口协议的看法，心智负担在何处。以及探讨怎么样才是合理的可实行的协作方案。
如果你没有探讨的想法，你可以保持沉默.
no war, make love
我想要的是: 充分了解其他公司的协作流程, 充分了解其他后端同事对出具接口协议的看法，心智负担在何处。以及探讨怎么样才是合理的可实行的协作方案。
如果你没有探讨的想法，你可以保持沉默.
no war, make love
 |
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 1
@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 1
@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
事实上，开发完成后给接口文档并不怎么会产生偏差，如果经常有很大偏差，要么是默契度不够，磨合一段时间就好了，要么就是太菜。
|
Select Language