想问一下大厂的前端开发是如何对接口的？

資深大佬 : npm 5

我目前在一家小公司，后端写完接口之后，就直接丢给前端，然后前端自己照着文档对接口，先不说文档有多稀烂。

重点是接口经常有问题，有时候去找后端，他们还有时很不耐烦。

表面上看测试接口很简单，去找后端问一句也很简单，但是前端在测试接口时，是需要做大量的测试来证明这个接口确确实实有问题。需要用很多很多不同的方法走很多很多遍流程，没有十足的把握，前端是不会随意去找后端的，不会随意打扰后端的。看到他们一开始不耐烦，最后又乖乖滴改 bug 时，心里很恼火，搞得前端好像是故意找茬似的。

有时候会感觉前端好像低人一等似的，像求人一样，很不舒服！

测试工程师只测试项目的整体流程，说白了，也就是只测试前端代码，而后端工程师可以随意编写 bug，毫无顾虑！

而测试一旦发现有问题，就只会把 bug 提给前端，让前端来背锅，很烦！

感觉前端工程师根本就不是前端工程师，而是专业的背锅侠！

大佬有話說 (17)

資深大佬 : jangit

同问，和别人做小项目的时候经常遇到这种问题。幸好小项目前后端直接开个语音就可以解决了，但是这样的带来的损耗也蛮多的
資深大佬 : whoisix

我们公司是先出接口文档，后实现功能
資深大佬 : jangit

@whoisix 请教下，如果有时候设计的文档和实际有出入，是要怎么解决的呢
資深大佬 : AllenHua

前端的确最容易背锅，因为和用户交互了

但是后端的逻辑其实客观的说还是相对复杂一些的

只是希望后端能够谦虚诚恳一些并且保持缜密的思维你说的这种现象我觉得很普遍记得之前站里有人讨论过来着要看主要领导是前端大佬还是后端大佬（逃
資深大佬 : hyy1995

是的没错，前端基本上就是背锅侠，因为是直面客户的，大部分 bug 都是先流转到前端这边
主資深大佬 : npm

后端可以随心所欲的编写各种 bug，没有任何后顾之忧，因为最后所有的锅全部都由前端人员来背。

而前端人员往往需要浪费掉大量的时间来排查后端的 bug，往往加班的都是前端人员，真的是很难受。

后端写完 bug 啥都不用担心，正常下班周末双休。然后由前端人员来背锅加班。
主資深大佬 : npm

有时候恨不得自己去写接口，现在 node.js 一样可以写接口。
資深大佬 : anguiao

有点责任心的人自然会先自己测好，要是遇到没责任心的嘛，那确实是比较难受。
資深大佬 : bojackhorseman

别的不知道，我们的后端在旁边，随时有问题随时问
資深大佬 : Jaosn

相信自己的代码，一有问题直接推给后端
資深大佬 : uxstone

这是开发流程上的问题，要解决是要花时间花成本的。
資深大佬 : night98

让开发写接口文档，并要求提供对应接口返回的 json 内容

这样做的目的第一是有文档方便核对，第二是开发必须自己先走一遍接口才能给出 json 内容
資深大佬 : suzic

最烦的是在开发过程中接口字段甚至数据结构都会经常有改动，而且不给前端商量，（有时改了后也没通知到前端）增加了很多的工作量。我们前端的建议是先开个接口评审会定义好相关数据，但后端似乎不太愿意，原话是需求复杂，很难一开始就定义好具体内容。很无奈
資深大佬 : demonlin

像这种情况，前端直接扔 cURL 给后端就行了
資深大佬 : whoisix

@jangit 编码前会开会与前端先约定下接口，尽量提前暴露问题。如果开发过程中确实有不得不修改的情况，就与前端沟通一下就可以了。联调的时候可能还是有和预期不一样的东西，不过都是稍微调整一下就可以了
資深大佬 : red2dog

先写文档，mock，方便单元测试。后面连调换个接口就行了。
資深大佬 : whisky221

唉，更加坚定了我转后端的心
虽然目前公司里没这些问题