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

3nbVvF7r

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

在企业级应用开发中，如果你们团队人员是前后端分离的，你会发现联调让人很不省心，可以说往往是效率杀手，而提供联调的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个小时。大厨心想后端你个老六，老是骗我说什么都好了，后端说我也没想到还有这个功能隐藏在这儿……

四、神探艾小坡

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

我犯了很多错误。

• 第1个错误，我告诉前端说接口基本可以了，但是我说不出可以在哪儿，只是听从后端的人员说可以了；
  
• 第2个错误，我只是让前端评估工期，我并没有做整体评估，让前后端人员一起参与进来评估；
  
• 第3个错误，虽然过程中我有实时管控，但是前期我并没有让前后端人员聚在一起，一同分析产品设计、产品边界、原型图、各自实现思路；
  
• 第4个错误，对后端接口的管理比较松散，没有提前约定接口文档（包括接口的数量、Payload、DTO、注释）；
  
• 第5个错误，没有明确的评估时间和科学有效的评估方法；
  

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

开发中：

• 第1个现象，虽然我会主动去问状态，但是对前后端来说，他们负责的内容是比较具体的，他们没有整体思维（分工使然），一小部分人员过程比较被动，不会主动沟通，遇到问题如果一直没有回复，比如前端问后端要结果，如果后端一直没回复，前端人员向上反馈的力度会比较弱，因为他表达过了就不会一直催，这是合理的。
  
• 第2个现象，有时候后端因为忙，会说先等下，然后忙着忙着就忘记了，最后不了了之，如果不是负责人督导，这件事会一直悬而未决；
  
• 第3个现象，后端人员的接口太超前了，在前端忙组件封装的时候，可能提前一个月就把接口写完了，然后前端一个月后才开始调试；
  
• 第4个现象，联调后才发现，一个功能漏了接口，表关系也没有设计等等。
  

开发完；

• 第1个问题，没有后端参与整体测试，就交付产品或测试了。或者有，但是预留测试时间不多，因为后端还是要做一个逻辑测试闭环，毕竟前端对逻辑测试会比较弱；
  
• 第2个问题，测试完成后，代码审查缺失，核心代码可能没注释，扩展性很拉胯，这为将来的可维护性埋下雷，整体没有闭环；
  
• 第3个问题，整体功能完成后，前后端缺少复盘。
  

五、解决方法

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

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

• 后端交付确保：（1）完整的接口文档，包括接口数量、接口注释、接口payload和响应DTO；（2）接口校验不能存在遗漏；（3）接口不能出现明显的500错误；
  
• 针对评估方法：（1）前端评估自己的时间（不包括联调）；（2）后端评估自己的时间（不包括联调）；（3）前后端各自开发时间 + 加上联调时间 = 整体时间；
  
• 针对产品设计：（1）开发之前把相关材料分发阅读；（2）请产品、前端、后端聚在一起，一同分析产品设计、产品边界、原型图、各自实现思路，并控制好会议时间；
  
• 后端接口管理：（1）在开发之前先写文档；（2）如果你觉得写文档比较耗时，可以优先定义控制器，把路由、payload、response、注释都写好，然后通过swagger交付给前端，然后再推进开发；
  
• 针对评估方法：可以公开评估或者多人同时评估（翻卡牌的方式，避免相互影响），再取一个折中时间；
  
  

中期

开发过程，因为分工必然导致割裂，比如前端说后端接口有问题，后端因为其他任务，响应不定那么及时，有可能双方忙着忙着就都忘记了。这个时候，负责人肯定要进行过程管控，管控的时间、频率、方式方法就显得特别重要，避免过分干扰导致影响工作，又不能完全放纵，隔天再验。
我们曾经在这个环节犯了严重错误，因为我们前后端各自有负责人来管，出现问题，前后端各自解决，解决不了，反馈给各自负责人解决。这里的错误有两个：第一、流程过长，每个环节出现的问题很容易被掩盖；第二、项目没有牵头人，被掩盖的问题无法提前发现，提前解决。后面我们尝试了让后端的负责人充当项目经理角色，全程主导项目，目前还在尝试，这种方式可能不是最好的，至少会相对可靠一点。比如，每天中午负责人就发起状态询问，有问题立马反馈，当场决策。
后期

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

感谢您的阅读，以上就是我的分享，希望我的文章能成为你成长路上的垫脚石，让我们一起精进。