为什么说在企业级应用开发中，后端往往是效率杀手？

大家好，我是张飞洪，感谢您的阅读，我会不定期和你分享学习心得，希望我的文章能成为你成长路上的垫脚石，让我们一起精进。

在企业级应用开发中，如果你们团队人员是前后端分离的，你会发现联调让人很不省心，可以说往往是效率杀手，而提供联调的API一般由后端人员提供，为什么我要得罪后端开发人员，不是因为我是做前端的，恰恰相反，在我职业生涯的大部分时间里，我是做后端的，而且直接管理过不少前后端研发团队，不断试错的过程给了我极大的教训，下面是我的经验和分享，希望对你有所启发。

一、车祸现场

曾经我会不由自主觉得前端，产品、测试老爱夸大其词，把责任都归结给后端。可能是我没有认真取证，掌握的资料不够多，根本就没有深入思考过这个问题，总觉得相互碰撞不见得是坏事，让他们在磨合中把事情收掉也是可以的。

直到昨天，我们在做认证授权的身份源的时候，工期一拖再拖，让我彻底绷不住了，我让全部前端把所有联调还剩下的问题罗列出来，盘点一下截止收官还剩下哪些问题：

登录组件接口没有返回之前tota订的规范发送验证码接口500忘记密码接口500忘记密码不行导致重新设置密码接口调试无法继续验证码/邮箱登录接口405访问控制api/appcfg/control-access-grant?keyword=&skipCount=0&maxResultCount=10这个get接口应该有个默认all数数据api/appcfg/control-access-grant 添加后获取不到添加的数据登录控制身份源启/禁用接口身份源首次创建成功之后，返回的id与请求的新数据id不一，导致页签定位不到（时而行时而不行）创建成功之后，请求的列表数据为空，且总数count也没有发送变化（为0）/api/IdpCounn/id（修改名称） 传参太多

我刚整理完，前端又来投诉，还有几个接口问题刚刚发现，我一起发给你……

显然以上的问题大部分是后端产生的，我在想后端到底怎么了？

二、来龙去脉

事情的起因是这样的，公司要做认证授权配置（传送门），我对一个前端说，后端接口基本可以了，你可以联调了，评估一下时间吧？对方说要两天。我想了一下觉得差不多，就说可以。这是一个一年工作经验的前端，我觉得年轻人有冲劲，就按他的来，但是想到对方可能因为年轻而轻敌，于是过程反复交代确保代码质量和稳定性。

第一天复盘，问了下过程有没有问题，大家都说没什么，只有前端说有一个技术正在论证，还没突破。到了晚上我看他还在加班，就过去问他是否需要支援，他说自己再尝试看看，我说如果不行，我让某某谁帮你一下，他说协助需要占用对方比较多时间，暂时不用，我看干劲正浓，也就不打扰他，说晚上如果实在搞不定，明天我让人帮下你。

第二天中午，我觉得要提前了解下，于是问前端目前有遇到什么困难没有？前端说思路是有了，正要进行联调，但是接口目前有很多问题。多年经验告诉我，事情有点不妙，十有八九要延期了。因为下午还要预留时间用来测试和修改的不是？果不其然，到了下午，后端接口开始出现一连串的问题，群里的BUG清单一直再涨，待到7点多了，我想今天元宵，不能让大伙太晚下班，那就明早争取把这些东西收掉吧。

第三天，进入真正繁忙的联调时间，前端被我怼，后端被前端怼，接口问题随着联调不断暴露，简单BUG自不必说，不幸的是后端遇到其中一个接口一会儿正常，一会儿异常，后端始终搞不定，前端正联调起劲，结果又进入漫长的等待，我只好让对方先去忙别的去了，结果第三天搞了很晚，也没有全部完成，此时和评估的时间出现了2天偏差。

三 、不恰当比方

我把前端比作大厨，他需要的素材大部分是后端现做的，不是像大厂都是成熟的预制菜，随便用都不会出问题。但是在开发过程中，大厨想当然后端一切都是OK的，于是他套上围裙，打开大火，往锅里倒满油，当油烧到100多度的时候，发现蒜头没有了，菜洗的不干净，碟子也没有准备，炒起菜缺胳膊少退，原来10分钟的一盘菜，硬生生炒了1个小时。大厨心想后端你个老六，老是骗我说什么都好了，后端说我也没想到还有这个功能隐藏在这儿……

四、神探艾小坡

问对问题才能找到答案，通过和前后端沟通和自我反思，我很快就把自己管理过程的错误找出来，并发现了研发在流程上的问题：

开发前：

我犯了很多错误。

总之，开发之前，对后端来说，在时间范围内，再怎么准备都不过分，因为有太多的东西都是后端驱动的，而且这些活又细又多，需要提前准备，准备，再准备；检查、检查、再检查。因为你要提升效率，就要确保前端人员开箱即用，而且很好用。

开发中：开发完；五、解决方法

找到团队问题的症结，接下来就好办了。

前期

前期的一个原则是充分准备。

中期

开发过程，因为分工必然导致割裂，比如前端说后端接口有问题，后端因为其他任务，响应不定那么及时，有可能双方忙着忙着就都忘记了。这个时候，负责人肯定要进行过程管控，管控的时间、频率、方式方法就显得特别重要，避免过分干扰导致影响工作，又不能完全放纵，隔天再验。

我们曾经在这个环节犯了严重错误，因为我们前后端各自有负责人来管，出现问题，前后端各自解决，解决不了，反馈给各自负责人解决。这里的错误有两个：第一、流程过长，每个环节出现的问题很容易被掩盖；第二、项目没有牵头人，被掩盖的问题无法提前发现，提前解决。后面我们尝试了让后端的负责人充当项目经理角色，全程主导项目，目前还在尝试，这种方式可能不是最好的，至少会相对可靠一点。比如，每天中午负责人就发起状态询问，有问题立马反馈，当场决策。

后期

尽可能明确验收标准，在前期开发之前。因为很多时候东西收拾得不不干不净，除了过程管控，部分和验收标准模糊有关，当我们无法具象化我们的计划，其实我们是无法验收的。比如完成的标准是否包括自测，因为我发现个别前端对逻辑测试是不管的，或者测试会存在盲区；又比如验收标准是否包括代码评审，否则看似功能都ok了，但是代码可维护性很差，间接给后人运维埋下成本的坑位。最后如果一个完整的功能结束后，能开个短会，定期总结和复盘开发中的问题，效果可能就更好了。