关于前后端接口联调的问题讨论

[zy0829]

技术经理提出了一个要求： 后端提前设计好 api 文档，前端按照文档 mock 开发，然后也不需要联调这个过程。

我在想这样真的就不需要联调了吗？往往身边的同事连个文档都不会看，让前后端按照文档开发真的可行吗？这样会不会更繁琐

[weixind]

前后端按照约定开发完了，放到一块不用联调就能跑通这个效果能实现。不过很看开发和前期沟通水平。你既然问了，贵司九成九实现不了。

[est]

这个其实你不用想，问问身边的人有没有成功案例就知道了


我估计 90%后期也要改 api 的。哪有一次设计成功那么简单的。。。。。

[Morii]

>>>.后端提前设计好 api 文档

这个也是需要前端参与的，有些前端是不处理任何业务逻辑的，格式要求很敏感。

[wangtian2020]

开发完毕后还是会进入联调的阶段的。不需要联调就纯扯淡
水平想当的情况下，前端设计的 api 会更完善一点，后端设计接口时容易页面看都不看，页面该显示的数据不返回。
后端设计接口也好，我当前端的省力，接口有问题再对后端提出修改意见
写 api 文档要用成熟的 api 接口管理网站，用过 eolink 、apifox 功能齐全都不错

[whoami9426]

简单业务下没有问题,复杂的业务依旧需要联调,当然后端把单测写的足够好也能减少联调的必要

[xianyv]

我(后端)也想这样,可是受限于和我合作的前端的水平,他连个接口文档都看不明白的人, 我还不如直接开发完,告诉他怎么用呢.

[Jinyang7]

只能说这样，测试时候一堆 bug/doge

[liangxiaowen]

还是按项目来。
如果接口多，可以这样做，几十个接口还有有文档查询一下好。
如果要改，改完知会一下就好了。
这么多接口应该也不会改太多，毕竟工作量也大。
手写文档复杂，就使用 swagger 之类就好

[xFrye]

开发不联调，到时候上线是不是要通宵测试 🐶

[zy0829]

经理提出这个要求目的是为了提高版本质量， 我是感觉跟质量不质量的不太搭嘎

[sarices]

我们就是这样做，但因为水平，或者对业务理解不够透彻，有时候会在实际联调的时候做大改动，还有就是有前后端没有严格按照文档来做，导致有些字段类型明明是 string ，偏偏返回了 number 之类的，还有就是文档有误，字段太多，检查不过来，特别是我们这些做后台业务的，一个接口返回几十个字段是常有的事

[debuggerx]

全栈开发，一个人把前后端都写了，自然也就不需要联调过程了。
当然对开发水平要求比较高，不是随便一个会写点前端的后端或者对后端一知半解的前端就能玩得转的。
有幸曾在一家外企创业团队待过，开发时一个人就负责一整个需求，需要什么就写什么，前端、后端、db 、mq 、cms 后台，信息模板……，需求涉及到的就一口气全做了，效率极高，问题很少，对团队和个人成长都有好处……

[zy0829]

@sarices 那不是很痛苦吗

[zy0829]

@Jinyang7 经理说这么做是为了减少 bug ，还说我们做单元测试没意义

[zy0829]

@weixind 水平确实拉

[zy0829]

@est 不用问工作 6 年没见过这么执行的

[zy0829]

@whoami9426 经理说单测没意义，我感觉他只会一张嘴也没意义

[linshuizhaoying]

你技术经理是不是没啥项目经验

[liuyd]

前提是前端也要理解业务逻辑，不了解业务逻辑看文档费劲，我遇到的前端基本只关心页面交互，写了文档还得讲一遍，沟通成本高所以我们直接干掉中间环节，后端先启动，文档用 swagger 啥的生成一个就行。

[zy0829]

@linshuizhaoying 菊花厂出来的

[chendl111]

没有银弹

[zy0829]

@liuyd 这个也行，我觉得不妥的是 他在全公司推行干掉联调这个环节我是理解不了的

[debuggerx]

@zy0829 单元测试肯定有意义，但是投入产出值不值得，更多的是取决于项目环境，其次才是开发水平，比如需求频繁变动的，快速迭代经常把刚上线没多久的功能直接砍掉的，pm 设计需求很少考虑复用的，这种项目追求单元测试覆盖真就没啥意义……
所以，不知道项目和团队的具体情况，没法直接下定论到底经理的想法对不对。当然如果这个经理就是纯粹凭个人喜好做的这些决定，那大概率是要出问题的

[zy0829]

@chendl111 在他那边全是银弹

[liuhuihao]

取决于 1. 前后端开发时能否完全按照文档来开发 2.文档的定义是否全面以及明确。
做到以上两点就可以不用联调了，但实话说基本做不到，很多时候文档定义的是 number 后端会给你个 string ，还有就是 文档最初在写的时候可能大家就没有考虑到会有一些额外的情况，开发过程中还要不停的修正文档，如果双方同步好了还行，没同步好就会出问题

[liuyd]

@zy0829 不联调是不可能的，俩人得多有默契，有改动不只要改代码还得改文档真的烦

[Hudiebbk]

前期给出 api 文档我觉得不是为了后续不链调,而是为了开发能在动手写代码前一起先给出一个初步方案

[LcDraven]

我后端，我以前这样实现过。得后端定义好接口，让前端审核一边。开发好之后就算接口有什么问题也能很快解决。

[captain55]

取消联调不可能，不过可以大大的缩短联调时间。
比如 5d 的开发量，配合 0.4h 的联调。

[谁文档写的不清晰，谁承担责任。谁不看文档，谁承担责任。]

[liuyd]

@Hudiebbk yes ，就是个初步方案，如果说俩边都按照文档开发，那就需要的不仅仅是一个 API 文档，而是一个更加详细的项目设计文档及接口文档，这对开发人员的文档能力有要求，而且需要前后端共同参与，那么写文档的时间将会大大拉长。

[acerphoenix]

就是想白嫖联调排期时间, 压缩工期. 你猜这个经理会不会把文档完善的时间加到开发工时里?

[freezebreze]

后端得懂前端才好让另外一个前端好做 快进到经理让大家全干

[MRG0]

不可能不联调，除非全干

[leaves615]

这个要求是合理的。
设计优先。良好的设计可以有效降低软件工程的成本，提供软件质量。

OP 应该思考采取什么的方式方法加强设计的一步到位，以及前端和后端在沟通和文档质量的高效信息传递。
而不是基于本身就不合理的工作常态中找方式方法来否定要求的合理性。

如果一个人开发，在充分设计好后的完成开发的效率为 1 。
在前后端分离开发的环境中，这个效率多数情况下不能达到 1/2=0.5 。 很多场景下比 1 还有高。效率差的情况下甚至达到了 1+1>2 。

这种情况下就必须采取措施提升效率。而不是降低效率。

[sampeng]

我身边有成功案例，但是。可不是写普通文档，是写 swag api 文档。然后自动生成 sdk 。server 和 client 各自去实现。有问题再回来改。是一个正向循环。
联调时间忽略不计。api 质量变高很多

[jiangnan01]

我去开发商买房，开发商让我去银行贷款，银行让我公司出收入证明，银行把贷款打给了开发商，理论上我每月还月供，拿到了房子，开发商拿到了房款，银行拿到了利息。但实际执行的时候.....

[morenacl]

理论上没问题

[iyiluo]

简单的接口可以模拟，但是遇到复杂的业务接口，一定要后端实际的调用才行

[fao931013]

这不就是把 联调时间 算进 测试时间吗 朝三暮四罢了

[jixiaopeng]

我一般都会要求 mock 文档先出，共同评审，然后并行开发，如果有没考虑到的再进行范围影响的讨论，尽量避免时间浪费，这样确实很能提高团队效率。

[xiang0818]

没问题。我们已经这样子搞了 5 年了。
1 、后端开发定义好接口（接口定义网址： https://nei.netease.com ）直接给到前端
2 、前端查看接口，如果觉得有问题，直接给后端说，或者汇总后抽个时间两个人过一次接口，约定接口后端完成时间。
3 、接口确定完成后。前、后端并行开发，与此同时 QA 完成测试用例评审并提供冒烟用例。
4 、前后端完成冒烟用例能够正常执行，那么就提测。（这一步要说也是联调，只不过换个说法）
5 、前端负责提测演示，提测演示过程中记录提测问题（或者记录需要调整的部分细节）。
6 、提测问题修复完成，发布提测邮件到项目组成员。

[bojackhorseman]

怎么可能不需要联调了，只能说减少了联调的时间。

[Duanpei]

我是觉得根据规定好的接口格式， 各自开发是可行的
虽然可能还是需要花费不少精力去联调
接口足够简单/配合足够默契， 这种方式的确可以省事不少

[sarices]

@zy0829 #13 只能这样了，没有完美的方案

[estk]

swagger + 版本控制可以有效解决前后端扯皮

[lplk]

理论上可以做，我们这样做过，但会面临一些问题：
- 后端出文档前必须把所有业务逻辑的实现理个大概，才能给出 api 文档，这个挺需要时间的（业务简单的话还好）
- 后续后端大概也会改 api ，因为前期思考，大概率没有实际投入开发深入，这时某些需求可能会有更好的方案，然后可能会改 api 的数据结构，不过第一步做的好的话，改动应该不会太大，只是说存在这个风险。
- 接口会有很多相互依赖，比如最简单的一个业务，必须先创建数据，才能有展示数据。如果业务复杂了，mock 可能会有些麻烦

所以，个人来看，联调的时间还是需要的，只是提前有接口文档，联调的时间相对会短一些

[ZZ74]

这种需要一直有实际做开发 10 年左右的前后端，写好文档后，双方过一遍就好了。
国内的环境一般很少有这样匹配条件。这个年数的不是被淘汰了就是当领导去了

[moyechen]

我们使用 graphql ，每次也确实是先定义 schema 再写逻辑的，但是很多时候前端还是需要真实数据，联调是少不了的。

[treblex]

后端靠谱才行，我对接口就相当于给后端做一遍测试，除了 curd 没一个靠谱的接口🙉

[treblex]

@treblex curd 也有创建数据不验证，外建啥的，查数据的时候咔咔崩溃

[phieo2018]

这个理念是没问题的 就是比较看双方的水平

[OrionParker]

照着你技术经理的脸扇就行

[wanniwa]

没问题的，我们就是这样对接的，除非文档写的不行。
有的时候为了快，我们开发先写 web 层的接口，不写里面的实现逻辑，前端有个框架可以直接根据 swagger 导入生成接口，这样只要后端接口在代码中设计完了，前端就已经能对接了。mock 起来也很方便

[cmonkey]

后端先出 api 文档，前端基于 api 文档做开发，但是不连调是不行的.
从形而上来说, 实体无法直接面对变化，因为变化被视为不影响实体本质的外在现象
api 文档我们可以理解为一个实体

[lc5900]

开发过程就应该这样，但是肯定得有联调环节，不然肯定很多预期外的异常

[cc11]

我之前公司就是这样：
1.后端先设计开发文档和 api 文档，拉产品和前端开评审
2.后面等前端端开发完毕之后再联调
3.中间过程中也不可避免会不断修改文档，但是大体不会变

[lei2j]

肯定还是需要的

[pkoukk]

能减少联调时间和周期，但是不可能不联调
在没有接触到后端真实逻辑产生的数据之前，mock 的数据不太可能覆盖全部 corner case

[blackcellcode]

只能说缩短联调时间，不可能不联调

[karnaugh]

连文档都不看的话我觉得这程序员有点不合格吧，文档是一个约定，也是一个保证

前端的完整开发需要原型、设计图、接口三方面，既要等待设计图，又要等待接口

如果不提前出 api 文档，那说白了联调的时候前端是在开发，而后端在干啥呢，在修 bug

那么联调的时候后端把 bug 修完了，测试的时候干啥呢?

而前端在联调的时候实际是在开发，那最终这个联调阶段就有些奇怪了

[yufeng0681]

你也不要过分解读项目经理说的： 不需要联调就能通。
这个就是理论上最完美的情况。把接口定义清晰透彻，剩下的都是自己分内黑盒的事情。
只是能不能把接口文档做到 100 分，这个要靠大家努力， 如果能力不足，那就只能在联调时发现问题，成本也会高起来。
如果你们公司前端，后端都没这样的经验，那开发前就要做好培训，赋能。 不然这个就是个样子货，落地失败，或者说要做几次项目迭代，大家才能掌握，顺利开展项目工作。

[sampeng]

换句话说。。联调其实应该是份内的事，而不是项目开发周期中一个明确的时间点。。

[woscaizi]

我猜测你们现在是前端等后端开发完毕后才开始写代码；
而你技术经理的意思是两边按照文档同时开发，最后咔嚓一对接。

[yor1g]

前后端本来就是要 mock 做单体测试的吧 文档设计够详细基本没问题

[qping]

@zy0829 #17 我觉得你说的有道理

[dongzhuo777]

看需求啊。有些需求本身就原来的 API 上面加个字段 那还联调个鬼。或者就是一个表单查询。但是涉及到一些业务交互的肯定是要联调的，比如一个业务操作本身设计到 5 、6 个接口的调用 纯 mock 你有 mock 数据的功夫代码都写完了。

[yc8332]

前面是对的。不要联调，那估计是神仙吧，复杂一点的功能不联调怎么可能，而且开发当中肯定也是要加字段啥的，不太可能已开始定的就完全够用了

[visper]

这样做主要目的是开发的时候减少两边沟通两边互等的时间。大家都开发完了肯定得拿起来综合测试下，这里就算是联调了吧。

[Techcj]

他能把所有报错情况，文档模拟出来吗，什么字段类型错了，空了，少了字段多了字段

[breadykidliu]

不可能的，可以参考调用三方接口为例，即使接口文档完善，调用方也需要实际数据看不同场景的效果来做调整，纯 mock 数据开发实际测试肯定会有问题

[error451]

如果前后端都对对方的工作很熟悉的话，这么做会非常顺利。

否则就会无限扯皮，尤其是前端完全没做过后端项目，后端完全没做过前端项目。

其实这个事情关键要看是谁来干活，理论上技术经理应该是前端，后端都是熟手， 然后由他来把控方向做大量的工作，比如写 API 文档和 mock ，前端只需要调 Mock 接口做渲染，后端只需要按照 API 文档提供数据，那么基本上这么干就没啥问题。

如果技术经理仅仅是给你们说，然后活都让你们自己干， 那么必然成不了

[shaozelin030405]

这样没问题，但是一定要联调

[leqoqo]

有段时间后端全靠 swagger, 接口字段什么时候变了不知道,一到最后阶段,哪哪都是坑

[z1154505909]

前提是需求所有细节完全确定,且不会变更,不然,呵呵呵哒

[deno2h]

按照文档 mock 开发没有问题，前提是文档必须要前后端达成一致

[xingdaorong]

@xianyv 业务简单的，比如表格返回字段什么性别等，这一般加个注释就好了，就怕业务复杂，传递的参数嵌套层数多等，前端需要什么样的字段等，都需要交流来设计

[IamUNICODE]

如果两边能对上，直接后端写接口，前端调页面，最后联调，这样搞更省时间；
但是两边时间脱节的话就先出文档，前端模拟一下；
我还是更倾向于前者。

[xianyv]

@xingdaorong 我现在都不跟我的前端交流了, 我是接口返回什么他用什么,除非少了字段, 和我合作的前端开会都不带听业务逻辑的, 就是照着设计图还原一下,页面逻辑一概不写. 就等测试出来,才出业务逻辑.

[MaxJin]

好是好，问题是就怕后台更新了接口还不和前端说，然后甩锅是一绝。

[yangblink]

swagger openapi

[ALLLi]

挺好的，可以缩短开发周期，都写完再联调就行

[iyaozhen]

没有问题呀，一般都这样，而且后端都是先写 idl 生成接口文档和模板代码

但有个磨合的过程，成熟的项目确实这样很快。但不能去掉联调和测试这个环节

[ccagml]

我们就是这样，有排联调时间，基本不需要联调。

[liiihhhh]

说下我们公司的方案：
背景：前端用的 TypeScript React ，后端是 Spring
后端使用 springdoc 插件生成 swagger scheme 并且经可能的写上注释
前端使用 swagger-typescript-api 插件根据后端的 swagger scheme 生成接口文件，然后直接调用即可
这样在后端有接口变动的时候只要前端重新生成并通过 TypeScript 类型检查基本上就没啥问题

[importmeta]

太理想了。

[leegradyllljjjj]

根本不操心这个问题，前端后端测试全包了

[akira]

这就是正常的开发流程吧，文档先行。。。

[idealx]

我觉得设计接口，mock 数据都是没问题的，是可以提升开发效率的，但要说这就能不联调就有点过了，只能说可以减少很多联调过程中的问题。
怎么保证文档设计完，mock 的数据直到提测过程完全不会变动的？后端提测时的接口质量怎么保证？
就算不联调，测试团队也需要进行集成测试，只不过是把问题都堆给测试阶段，各种问题再返回开发去排查效率更低。

[kkwa56188]

我喜欢这样的, 起码出了问题的时候 找得到人背锅.

[fuyun]

理想的情况是全栈，各人按业务模块划分；其次是搞个 mock 接口服务，后端提前定义好接口的出入参，前端直接调用 mock 服务开发，不需要手写 mock 的数据；最后才是 op 说的后端先给文档，前后端再根据文档开发。
不管是 mock 服务，还是文档，都难免遇到需求、设计变更导致的文档变更问题，这时就需要维护文档，并将文档变化实时通知到关联开发人员，最好还需要记录变更历史（谁什么时候因为什么导致了什么变更），避免甩锅。

[xuanbg]

根据文档，也就是按照约定来进行开发是对的。至于这个过程遇到的问题，解决问题就好。没有什么模式是完美的，是不会出任何问题问题的。只要是人干的事，就必然会有各种稀奇古怪的问题。

[rookie2luochao]

可以让后端接入 swagger/openapi 规范，先出接口定义，前端根据定义生成接口文档和 axios 请求，也是一种凭据
这个是根据 swagger/openapi 规范生成的接口文档，https://github.com/rookie-luochao/openapi-ui