携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第7天，点击查看活动详情
经常在群里看到有前端小伙伴吐槽，跟自己对接的后台水平贼la，随心所欲命名，约定也是说变就变。
最重要的，很多时候后端说接口已经写好了，等到联调的时候，前端发现这也不对，那也不对。本来几小时就能聊调完，一拖就是两三天。
退一步越想越气！
前端想要的API
- 接口自测通过
大型团队有良好的规范和机制，一般不会出现啥大问题。但在小团队中可就花样百出了，一些开发写好接口简单测测一提，任务技术，具体有啥bug。等前端或者测试找到了再修，及其不负责任。
其实后端对业务需求了解的程度是相当高的，提前考虑到可能出现的情况，写好用例，自测完成，基本上就不会出现啥问题，所以至少自测完成吧。
- 正经接口文档
业务复杂度不同，编写好的接口文档的难度也差异很大。有用过微信API的小伙伴应该都深有同感，四个字形容：什么玩意？
接口文档的版本管理，变更时的检查，修订记录，审核等关键步骤。多数后端开发是不愿意写接口文档的，所以用来一系列的工具，导出文档。导出简单，维护确是需要下功夫的。
- 参数命名规范
之前在跟某个团队对接时，看到一些参数命名简直随心所欲。虽然没有离谱到拼音或者abc，但aParam这种参数，还不带注释，真的让人捉摸不透。不求语义化，至少也要加上注释吧。参数的命名规范团队约定一个版本
- 异常情况处理
之前我们的系统中在某些错误出现时，会统一抛出一个错误，msg是“系统错误，请稍后重试”。上线后（内部系统），不出现异常情况还好，一出现同事懵了，这个系统错误是啥错误呢。
后端也只能去日志里查看，后来就建立了规范化的异常处理，后续前端也对各种异常进行了封装，引导同事进行反馈。
重点重点！
其实只要需要沟通，都会有问题。即使是一个人开发整套系统，也会出现考虑不全的情况，导致返工。
多人协作时，即时沟通可以解决多数问题，并且提高效率。
如果发现团队中有需要优化的流程，或者规范，即时提出，评审改正。对于一些同事的问题最好也当面提出，当面解决，一味的退让，最终加班的还是自己。
当然，如果你的团队不让说话，有问题不改正，除非钱多事少不加班，要么钱多也行，否则就赶紧提桶跑路吧！！！
你还有什么新想法吗？有的话咱评论区见，我是正经程序员，欢迎点赞收藏关注，感谢！
