最近与前端联调接口的一点反思

最近接到了一个移动端开发的任务，移动端是微信小程序，我在其中主要负责后端的开发任务。功能主要涉及到单据的操作以及单据相关的必要业务知识。

简单介绍一下我们的背景。我们现在做的这块业务是基于已经成熟的web端的功能，迁移到移动端上面去，其实有很多核心的逻辑，前人已经踩过很多坑，现在的核心流程已经是非常完善了。我要做的就是把这些功能通过接口暴露到移动端上去使用，当然也免不了一些移动端的定制化的改动。

起初接到这个任务我是有点胆怯的，因为涉及到我之前没有做过的一些流程，而且对于一些细节上，我更是懂，但并非能讲清楚。而且更多的是站在我自己的角度去理解，并非完全正确的认知。但是后来经过代码的摸索，发现确实还是可以复用很多的逻辑。这样也给自己的信心提高了不少的。

分享一下我和前端对接的经历，以及我的一个思想变化的过程。

1.0时期：

我始终关注点在于我要实现的功能层面。我首先把web端涉及到的接口以及业务逻辑进行了整理和复盘，捋顺了其中的逻辑和流程。

很开心都是自己能看懂的代码，根据代码也能顺利的把流程走完。不用去请教和麻烦别人，也是我庆幸的地方。

这个时期我和前端的沟通极少，他们在搭建他们自己的开发环境，画一些基本的页面架构。而我这个时期，开始准备下手写代码了。

2.0时期：

这个时期我就开始放手写代码了，我业务最核心的地方往外延申，一直到接口层。把其中的逻辑弄彻底后，我就开始开始犯我的第一个错误。

由于web端的单据业务大概是两块之前可能是不同时期开发的，导致接口的字段存在类似但又并未完全统一规范的问题。而这个阶段，我恰如其分的没有意识到这个问题，直接悠闲把之前的接口的字段进行了沿用。把接口的进行了定义，接口中属性全部都是沿用了之前，入参也是如此的。

3.0时期：

接口定义完成，业务逻辑也把需要补充的部分已经基本上完成了。接下来是要跟前端讲一下我的接口了。

这个过程中其实是分了两部分的，因为对接了前端的三个人，其中一个是幼儿时期版本的需求，后面两个人对接的是青少年时期的需求。

这个时候我就开始拿着我的swagger先给第一个幼儿时期需要对接的同学进行了宣讲。看着我对于整个幼儿时候接口的设计，以及各个逻辑的实现，前端的同学表示已经懂了，等有问题再详细沟通。正是因为有问题再详细沟通给我自己埋下了一个巨大的雷，这个雷整整伴随了这个产品的整个幼儿到青少年时期。

4.0时期：

开始暴雷了。这个时候前端在不断的质疑接口的规范性，因为很多用不到的接口字段进行了多余的返回，还有很多非必要的入参也存在。这个时候就体现出来了很多的问题，第一点：没有根据移动端的实际业务场景进行优化字段；第二点：之前写的代码也存在不规范的问题，但是到了现在，规范性逐渐提高，前面允许的问题，现在已经不再允许。

开始不断的被质疑接口的质量，这也给后面的前后端沟通带来了很大的影响，因为现在的前端对于后端就产生了很大的质疑，凭借着接口第一印象就非常的差。最直接的印象就是能力完全不够格。

后面的沟通和进度也如实的遭遇了极大的问题。经常被问到的一个问题就是:你确定这个东西是这样的吗？

5.0时期

经历了疯狂的吐槽之后，还是按照前端的要求改掉了很多规范性的东西，对接口的部分内容做了统一。

经历了很长时间的蹉跎，项目虽然困难，依旧危险着陆了。

在这个过程中，面对态度不好的沟通，以及各方的压力，让自己变得身心俱疲。整个项目开发过程中，由于前端的任务比较重，项目经历了延期，由于要去追进这个进度，在这个过程中，各方的压力汇集到自己身上的时候，自己感觉还是非常的难以招架。比平时写代码加班到深夜的那种感觉累多了。

总结与反思：

目前自己已经是一个工作三年的程序猿了。

之前的公司，做的项目基本都是前后端不分离，自己写的接口自己调用，用多少传多少，前后端都在自己的掌控之下，不存在前后端沟通交流的问题。其实整个过程更像是自己一个人，没有其他人的参与，自己即是核心也是全部。

但是真正参与到了前后端的项目中来以后，当自己去定义一个新的接口的时候，这个时候其实还好，因为所有东西都是新的，不涉及到之前的束缚。

但是当我们复用接口再提供新的时候，就会产生新问题。一方面被原来的接口束缚住了自己的思路和空间，这会导致自己开发新接口的思路会被这个原来的接口给限制住，丢掉了原来自己本身该有的东西。还有一点就是懒惰导致的，因为之前的接口已经稳定运行了这么长时间，自己也不想去打破这种平衡。导致原来的接口字段或者信息被大量复用。

其实上述的想法我认为也是有利有弊的，不能一概而论，当然我这次的开发中是把错误全都犯了一遍。其中很重要的一点因为漏掉了，就是前端思维，我在做这些事情的事情，没有站到前端的角度去考虑过，哪怕是我多考虑三分，也不至于出现这种问题。

后面再去定义接口的时候，我个人觉得应该遵循以下几点建议：

1. 站住后端的业务功能，去定义开发的字段内容，不必要的信息，能省则省
2. 接口的命名，以及多个接口之间的共享信息，一定要站在前端使用的角度去考虑。不应该出现同一个功能的字段，在不同的接口名称不统一的情况。例如同一个字段的信息（订单号）：A接口：bill  B接口： id  C接口：billId
3. 一定要和前端核对接口，确认接口信息是否满足，这是最关键也是最核心的一步。不能等到后期再去变动核心字段，或者说不合理。后期的改动对于后端影响往往是比较大的。