调接口到底在调什么，工作量在哪儿？
程序员文章站
2022-06-13 11:53:53
...
做为一个不懂技术的IT从业者，经常听人讲，今天在调接口，然后调通几个接口就要好久，感觉好大工作量的样子。我想问，调接口到底在在调什么？工作量在哪儿？希望技术大神可以深入浅出的给我科普一下。万分感谢！（如果不能深入浅出，深入一点也好，我慢慢查百科，哈哈。再次感谢！）
虽然前期感觉时间好像被浪费掉了，但是眼光放长远，总的来说效率要提高好几倍。
0约定联调的那一天，他们告诉我，刚开始开发，过两天再联调。
1接口文档他们可以改三版，每版的出参名字都不一样。
2说好的五个出参可以突然变成两个，告知存在缺陷以后，回退修复花了半天，又在临上线前两天，又只有两个出参了。
3AB两个接口调用顺序，国庆加班的时候已经告知，十天以后发现顺序还是错的
4上线验证的时候发现调用C接口的时候多调用了D，昨晚我就没睡踏实
大家都是做IT的，哼╭(╯^╰)╮ 不会是我老板问的吧 标准项目流程是这样的。
PM出项目需求文档和MRD -> PM联系相关人员进行MRD评审 -> 设计师基于MRD做设计图 -> 后端工程师根据项目需求和MRD、设计图出服务端接口文档 -> 前端工程师进行接口文档审核 -> 前后端工程师并行开发和独立自测 -> 前后端开发完毕后进行接口联调 -> 测试人员进行测试 -> 测试完毕发布上线 -> 线上服务功能回归
如果完全按照这个流程开发，每一步都进行的很好，自然是ok的。但是由于后端工程师对自己的自信，经常没有进行充分自测(甚至压根不测)，导致前后端进行联调的时候，前端发现后端不可用，然后后端去修复问题，一来二去时间自然就没了(前端出问题，后端也不知道)，项目就delay了。同样的，如果接口文档写的不清楚，导致前后端对参数的理解不一样，也会导致接口的修改或前端实现的修改，次数多了，项目也就delay了。
由于这种事情太常见了，所以一般联调的时间都包含了自测的时间，所以这个测试时间一加进去，联调时间自然就长了。
我不认为*哥的方法是好方法，术业有专攻，人的精力是有限的。即使一个人是全栈工程师，那他也是有更擅长的一项，再者，不同语言，不同端的开发都有自己的开发规范，经常轮换的话，会浪费大量的精力，而且切换语言开发也降低开发效率。再说了，一个大的项目不可能完全由一个人开发，只要是多人协作，就会出现这种问题，如果是修改同一个模块的代码，更容易出现问题，即使不是在联调阶段，在开发阶段出问题就不降低效率么？流程上的问题，就应该通过规范流程解决，而不是拆东墙补西墙的方式。 首先，假设你说的是调（二声）接口，而不是调（四声）接口。因为后者不存在什么工作量的问题。
之前有个问题答案说的是护照过期重办时遇到的问题，和调接口的问题一致。
假设小明（我方）现在要出国，需要办护照（业务需求）。
小明到*局网站（接口提供方）上查询办证指南（接口文档），上面说办护照需要：
小明决定试试网上预约，结果网站显示“预约成功”（接口与文档不一致）。然后你想，好，成功了（我方疏忽）。
小明拿着照片和身份证去了*局，结果*局小妹手一摊：号儿呢？
啥号？
预约号啊？
没有啊？
没有不算，要不然你网上再约，拿到预约号，要不然你就现场约。（结果与预想不同，重来）
小明那一想，我就现场约吧。正要预约时，听到另一个工作人员跟小妹儿说最近系统在升级，可能还有些问题，还多人都预约了没拿到号（提供方在升级、重构）。小妹儿一看小明这可怜吧唧请一天假要被领导*的样子，就算了，让小明今天就办（双方协商处理方案）。
小明开心了，拿出了照片和身份证，准备办证（调用接口 2）。
小妹一看，说：你这是什么？
照片……啊？
不行，你这不合规矩，护照照片必须标准化，A 像馆是我们专门合作方，你去找他们照相，数据直接传我们这来，带身份证来就行（第 2 个提供方）。
小明无语了。你们为什么在网站上不说清楚啊？
小妹说原来你去看网站，我们网站那是前年做的了，政策早就变了（文档没跟上）。
小明只好去 A 像馆。
A 像馆一听，哦，知道，你来照吧。然后照了，说，可以了，我给你上传到他们系统，你直接去就行。
小明又回*局。
小妹：等下啊，今天网有点慢，照片一直没传过来（提供方之间的接口调用问题）。
等啊等，等到快下班了，终于传过来了。
小妹：好了，终于下载下来了，可以开始了。
小明长舒一口气。
小妹：等等，不行，我们系统提交通道关闭了。
小明：？？？
小妹：是这样，我们老大很爱我们，所以在设计办公系统的时候，要求还有半小时下班的时候就关闭业务通道，这样我们就可以整理下桌子，然后聊聊晚上去哪吃饭。
小明：？？？
小妹：不好意思啊，明天赶早吧。
小明只好第二天又去*局。
小妹：真是不好意思，昨晚英镑暴跌，忽然来了两千多人要办护照去英国扫货。
小明：？？？
小妹：我们这个系统有点老，只要排队的人超过 255 个人就会死机（意外情况）。
小明：？？？
小妹：我们负责系统的人今天二婚，明天就回来。
小明：？？？
小妹：啥时候能修好，不知道啊。你明天或者后天打电话问下吧。
小明口吐鲜血。
============
调接口就是这样一个过程。
工作量和麻烦不外乎：
除了这些之外，接口在某些意外情况下会出现意外的问题（比如高并发之类），这也是需要调试的。
知道了这些之后，就会对秦始皇统一度量衡的壮举狂竖大拇指，因为他避免了不同标准和接口之间的沟通。全天下用同一个接口，沟通成本大大降低。
所以，调接口这件事，你是大爷，你就是调教接口，你是小弟，你就调整自己心态。
老大去包子铺问，你们这有没有汉堡？老板分分钟跑到对面麦当劳买个汉堡回来然后把馅儿换成鲜肉的笑嘻嘻地双手捧上来。这就没什么工作量，对方可以来适应你。
反之，你就只能自己去麦当劳买个汉堡，自己买个鲜肉包子把馅儿拆出来，忍受别人的白眼，默默把汉堡吃掉。
这工作量自然就大了。 就跟你去银行办卡一样 好在我们团队是js跑通前后端的，一个需求可以从migration文件写到前端效果。而设计师给的设计交付物是点一下图形就能取到相关css信息的展示页面，所以并没有扯皮的机会。
回复内容：
调接口调的是你跟你同事对同一份需求的不同的理解，这种东西是无法估量的，谁让你们不从第一天开始就密切合作。这就是为什么我反对server和client用两个人来写。IT都已经这么多年了，把人当CPU超流水线不就好了吗，你先做server，等你做完了去做client。就算因为临时原因*server和client一起写，也应该每次都同时启动真实的server和client，出了事不要担心block了别人，两个人合作一起搞定。虽然前期感觉时间好像被浪费掉了，但是眼光放长远，总的来说效率要提高好几倍。
理想情况。
server：我ok了你调用吧！
client：我测试调用ok，准备提测！
实际（国内）情况。
server：我ok了你调用吧！
client：500了
server：我看看，好像某段老代码异常。。
（半小时后）
server：我ok了你调用吧！
client：还是500
server：算了我重构下老代码。
（俩小时后）
server：我ok了你调用吧！
client：还是500。。你吖的把参数改了？
server：重构了嘛，按新的参数来调
client：这个接口ok了，那个又挂了
server：我都改了一遍参数，你也该改
client：搞个文档吧
server：有个线上故障我要紧急处理下
client：ok（然后泡个茶刷刷知乎）
（一小时后）
client组长：联调ok没？我们客户端要赶紧出新版，我怎么看你好像很闲
client：在等server给新文档
client组长：等个p啊赶紧给我搞完，不然绩效给你-1s
client：server快过来我们快速搞定接口啦，要死人啦
server：妈蛋故障还没处理完呢，我就帮你十分钟哈
server组长：故障排除了么？我们得服务要保证质量啊
server：在跟client联调稍后过来
server组长：联个p啊，赶紧给我搞定故障，不然绩效给你-1s
client&server：我真是日了狗了
调接口的精髓在于“等” 工作量就在调上啊。软件生产这东西为什么叫开发不叫制造，就是因为要不断试。 与某关联系统联调接口，0约定联调的那一天，他们告诉我，刚开始开发，过两天再联调。
1接口文档他们可以改三版，每版的出参名字都不一样。
2说好的五个出参可以突然变成两个，告知存在缺陷以后，回退修复花了半天，又在临上线前两天，又只有两个出参了。
3AB两个接口调用顺序，国庆加班的时候已经告知，十天以后发现顺序还是错的
4上线验证的时候发现调用C接口的时候多调用了D，昨晚我就没睡踏实
大家都是做IT的，哼╭(╯^╰)╮ 不会是我老板问的吧 标准项目流程是这样的。
PM出项目需求文档和MRD -> PM联系相关人员进行MRD评审 -> 设计师基于MRD做设计图 -> 后端工程师根据项目需求和MRD、设计图出服务端接口文档 -> 前端工程师进行接口文档审核 -> 前后端工程师并行开发和独立自测 -> 前后端开发完毕后进行接口联调 -> 测试人员进行测试 -> 测试完毕发布上线 -> 线上服务功能回归
如果完全按照这个流程开发，每一步都进行的很好，自然是ok的。但是由于后端工程师对自己的自信，经常没有进行充分自测(甚至压根不测)，导致前后端进行联调的时候，前端发现后端不可用，然后后端去修复问题，一来二去时间自然就没了(前端出问题，后端也不知道)，项目就delay了。同样的，如果接口文档写的不清楚，导致前后端对参数的理解不一样，也会导致接口的修改或前端实现的修改，次数多了，项目也就delay了。
由于这种事情太常见了，所以一般联调的时间都包含了自测的时间，所以这个测试时间一加进去，联调时间自然就长了。
我不认为*哥的方法是好方法，术业有专攻，人的精力是有限的。即使一个人是全栈工程师，那他也是有更擅长的一项，再者，不同语言，不同端的开发都有自己的开发规范，经常轮换的话，会浪费大量的精力，而且切换语言开发也降低开发效率。再说了，一个大的项目不可能完全由一个人开发，只要是多人协作，就会出现这种问题，如果是修改同一个模块的代码，更容易出现问题，即使不是在联调阶段，在开发阶段出问题就不降低效率么？流程上的问题，就应该通过规范流程解决，而不是拆东墙补西墙的方式。 首先，假设你说的是调（二声）接口，而不是调（四声）接口。因为后者不存在什么工作量的问题。
之前有个问题答案说的是护照过期重办时遇到的问题，和调接口的问题一致。
假设小明（我方）现在要出国，需要办护照（业务需求）。
小明到*局网站（接口提供方）上查询办证指南（接口文档），上面说办护照需要：
- 一张照片
- 身份证
小明决定试试网上预约，结果网站显示“预约成功”（接口与文档不一致）。然后你想，好，成功了（我方疏忽）。
小明拿着照片和身份证去了*局，结果*局小妹手一摊：号儿呢？
啥号？
预约号啊？
没有啊？
没有不算，要不然你网上再约，拿到预约号，要不然你就现场约。（结果与预想不同，重来）
小明那一想，我就现场约吧。正要预约时，听到另一个工作人员跟小妹儿说最近系统在升级，可能还有些问题，还多人都预约了没拿到号（提供方在升级、重构）。小妹儿一看小明这可怜吧唧请一天假要被领导*的样子，就算了，让小明今天就办（双方协商处理方案）。
小明开心了，拿出了照片和身份证，准备办证（调用接口 2）。
小妹一看，说：你这是什么？
照片……啊？
不行，你这不合规矩，护照照片必须标准化，A 像馆是我们专门合作方，你去找他们照相，数据直接传我们这来，带身份证来就行（第 2 个提供方）。
小明无语了。你们为什么在网站上不说清楚啊？
小妹说原来你去看网站，我们网站那是前年做的了，政策早就变了（文档没跟上）。
小明只好去 A 像馆。
A 像馆一听，哦，知道，你来照吧。然后照了，说，可以了，我给你上传到他们系统，你直接去就行。
小明又回*局。
小妹：等下啊，今天网有点慢，照片一直没传过来（提供方之间的接口调用问题）。
等啊等，等到快下班了，终于传过来了。
小妹：好了，终于下载下来了，可以开始了。
小明长舒一口气。
小妹：等等，不行，我们系统提交通道关闭了。
小明：？？？
小妹：是这样，我们老大很爱我们，所以在设计办公系统的时候，要求还有半小时下班的时候就关闭业务通道，这样我们就可以整理下桌子，然后聊聊晚上去哪吃饭。
小明：？？？
小妹：不好意思啊，明天赶早吧。
小明只好第二天又去*局。
小妹：真是不好意思，昨晚英镑暴跌，忽然来了两千多人要办护照去英国扫货。
小明：？？？
小妹：我们这个系统有点老，只要排队的人超过 255 个人就会死机（意外情况）。
小明：？？？
小妹：我们负责系统的人今天二婚，明天就回来。
小明：？？？
小妹：啥时候能修好，不知道啊。你明天或者后天打电话问下吧。
小明口吐鲜血。
============
调接口就是这样一个过程。
工作量和麻烦不外乎：
- 供应方对于业务的描述不完整。其缘由可能是：1、没想清楚；2、懒或者没动力；3、升级或者业务改变之后没跟上；4、故意制造麻烦。所以，需要不停地去沟通，去反复确认，或者调用接口来看看结果是否符合预期。
- 我方与各供应方，以及供应方与其他供应方之间出了合作问题，一个步骤的问题影响全局。这是经常发生的事情——我过单行道也会左右看，因为即便你能保证你自己做好，也没法保证别人能同样做好。其道理一致。所以，需要等，或者从中调和，或者想别的办法解决。
除了这些之外，接口在某些意外情况下会出现意外的问题（比如高并发之类），这也是需要调试的。
知道了这些之后，就会对秦始皇统一度量衡的壮举狂竖大拇指，因为他避免了不同标准和接口之间的沟通。全天下用同一个接口，沟通成本大大降低。
所以，调接口这件事，你是大爷，你就是调教接口，你是小弟，你就调整自己心态。
老大去包子铺问，你们这有没有汉堡？老板分分钟跑到对面麦当劳买个汉堡回来然后把馅儿换成鲜肉的笑嘻嘻地双手捧上来。这就没什么工作量，对方可以来适应你。
反之，你就只能自己去麦当劳买个汉堡，自己买个鲜肉包子把馅儿拆出来，忍受别人的白眼，默默把汉堡吃掉。
这工作量自然就大了。 就跟你去银行办卡一样 好在我们团队是js跑通前后端的，一个需求可以从migration文件写到前端效果。而设计师给的设计交付物是点一下图形就能取到相关css信息的展示页面，所以并没有扯皮的机会。