联调接口时的一些感悟

最近在做APP时，在与平台组成员对接接口时，在一个接口上耗费了整整两天，并且没获取什么实质性的进展。然后我的主管在今天晚上帮我调试接口，只花了2个小时便打通了。我观察了主管解决问题的方式，意识到自己身上还有太多不足的地方，所以写了小结，供日后参考和警示

1、自己害怕和人交流，阻碍了工作的进度

这次要调试的是一个生成订单的接口，这接口的协议规范很多，格式上很容易有疏忽和纰漏，在这种情况下，应当仔细阅读接口文档规范，并且加强和接口开发人员的沟通，但我却采取了回避沟通，打算只凭自己的力量来打通接口。但这个接口中有一道非常繁琐的验证码校验规范，我没有告诉接口人员屏蔽这项功能，而是一次又一次地调接口去获取验证码。浪费了大量的时间和精力。

反观我的主管，处理问题的方式和我大相径庭。他一直在要求接口开发人员屏蔽校验码验证功能，虽然一开始就遭到了对方的强烈反对，但他并没有轻易放弃，在他的坚持下，开发人员明白了他的目的，采纳了他的建议，取消了复杂的验证功能，大大提高了调试的效率。有力地促成了问题的定位和解决

2、 没有安排好任务的轻重缓急

在今天的接口调试中，我应当解决的问题是生成订单的请求一直失败。但我的注意力却一直放在了验证码校验上。甚至因为验证码校验无法通过，认定这个接口无法再调试下去。其实校验码只是生成订单这个模块中的一个功能点，屏蔽校验功能不会影响订单生成的其他模块。但我却固执地认定只有解决了校验失败问题才能接着解决订单生成问题。在校验失败上耗费了许多不应该的时间和精力。应该重点关注的订单请求报文反而被我忽略了。

3、缺乏对难点和问题的正确认识

在这次调接口的过程中，我对问题和难点的认识并不充分，甚至有偏差和错误。还是校验码验证的问题，校验码的发送一共有五个流程。我最终的结论是：校验码发送失败只和第五个流程有关。但在一开始的调试中，我因为在自己的手机上发送校验码失败，便武断地判断这五个流程都有问题，便下结论说校验码接口存在问题，没法解决，并且一直以为这个接口没法用。但在后续的调试中我又发现，同事的手机大部分可以成功发送校验码，我最初的判断过于草率和武断，阻碍了自己对问题的深入研究。这点需要在后续的工作中避免。

4、缺乏灵活变通的意识

在调试的一开始阶段，项目部署在UAT环境中，于是我的思维也跟着被固定了。在调试接口遇到问题时，一直在UAT环境下重复而徒劳地一遍遍地调用接口。但其实UAT环境比较复杂，子系统也比较多，不利于定位问题，相比之下，相对单纯的本地环境才更适合调试。但我却一直在UAT环境里没有目标地摸索，一直地认定只有UAT环境才能提供接口，实现功能。这一方面源自我对后台接口机制的不熟悉，另一方面也是因为缺乏开阔的思维和尝试探索的精神。

5、不重视文档和规范约束

这次对接接口的失败，原因是两个业务数据的格式没有遵循。这两个都是核心的业务数据，都在文档里有比较严格的规范约束，但我却没有阅读文档，也没有考虑业务的具体内涵，一上来就直接动手开发。接口请求失败后，也只是单纯地从技术角度去检查报文的合法性。压根没有考虑到业务上的要求和约束。这种忽略业务场景，忽略业务现实意义的倾向，其实是思维的狭隘和贫瘠，这也是要在后续的工作中克服和注意加强的地方。

前段时间一直只是埋头做项目，沉浸在个人的小天地里。这两天调试接口，和许多不同的人打交道，才猛然发觉自己的眼界狭隘，所知所识都极为有限。做开发工作，因为总是埋头干活，加上性情内向，渐渐地便不爱和人说话，走向了半封闭的状态。但实际上工作是一种合作，只有多交流，多彼此了解对方的做法和想法，多相互学习，相互帮助，才能促进工作的进展。和人的交流沟通，在以后的工作和生活中都该加强和注意。