三方对接心路历程

从业这几年，因业务的需要，对接过不少三方，有大公司也有小公司，其中感受颇多，这里回顾以及总结一下。

初入职场即与某大型X公司进行业务对接，其实很简单，我只需将公司内部数据提供一个接口给对方调用即可，然而没想到跟我对接的人疑似为对方公司的运营类人员，我按照对方要求完成接口开发，并顺利提供给对方使用，后来对方找到我们说是还需要接口提供其它字段云云，后因公司之间的一些博弈不了了之了，这件事给我的印象是：对接首先要保证按需要完成，但如果能站在对方角度，提前发现，对接一些问题，想必也会减少不少麻烦。

后与大型跨国S公司进行业务对接，真颠覆了我对大公司的想象：文档给的是有，但是服务器接口不通，接口定义不完整，看起来像是基于某某语言的接口定义，微信、电话、邮件沟通，真是巨慢，骨子里透露着大公司的傲慢，我虽算不是特别的急性子，但也是相当之恼火，其实要做的事情也没多复杂，我只有一个开发与我进行完成时间段内的对接即可，或者提供一个完整、清晰的技术文档，然而这只是我一厢情愿的想法罢了。事情的收尾也很奇葩，因双方业务调整，暂停对接了，算是白忙活了。

在现在这家公司跟大型P金融公司对接金融系统，对方给的文档和技术资料都相对清晰，跟我进行技术对接的对方的一个外包人员，进行调试的时候还挺配合，但是当遇到突发问题的时候，就比较被动，首先要将问题产生的场景，数据报文以邮件形式给到外包人员，外包人员审阅发现无法解决，再将邮件转发给后台都是（核心系统开发），通常等待的时是都是以小时计算的。对方的技术文档是以doc文件给到，更新难免不及时，许多时候都需要电话沟通对照着文档确认一些技术细节及疑问。当然，毕竟是老版企业，对接后系统稳定性相当高。

后因公司业务发展，与代付公司进行业务对接，对方给到了技术文档及加密算法的java版demo，我仔细研究文档后发现有几处纰漏，多次沟通后改动了几个版本，也是那种电话沟通接照文档来的，后将java版demo转成golang过程中有一些小问题，也跟对方一一确认并解决，之后调度速度挺快，因为接口也不多，一周内就做完了，然后，公司因有其它更重要的业务，暂停了这个项目，后又不了了之了……（我可是用了自己的银行卡做了代付验证，还解绑不了，心在滴血）

与小贷P公司对接，其实也不算对接，是将离职同事写的java服务转成golang，然而文档并不够清晰，由于之前对接也存在着一些问题，文档资料比较混乱，也不清楚最新的版本，只能硬着头皮跟对方开发打电话讨论、修改达成一致，上线过程还算顺利，只是对方系统不够稳定，有几次比较大的宕机，对我方系统影响较大，业务上表的索引设计有问题，没有保证幂等，也是双方对文档的理解存在一些偏差。这次给我的教训是：1. 永远不要相信对接方的接口 2. 细节是魔鬼，一定要抓清楚问题 3. 对于理解上的偏差，尝试用example来解析或消除（说起来都是泪）

与小贷W公司对接，这个更奇怪，接口文档居然要我方来定，没办法，只好在石墨上建立共享文档，一个接口一个接口进行确认。在接口对接阶段，对方有三到5个开发同时与我对接，因为对方公司是按接口分任务的，果然人力充足，然后这只是灾难的开始。每个人对文档的理解竟然不一样，有的想要换另一种写法，有的想要字段写错了，有的字符串中混入了中文字符，加密算法在不同编程语言间的描述区别问题等等。所以，没办法，所有不按照文档来的，都会导致工期延后。这次给我的教训是：文档是个好东西，它是一个协议，这份协议是跟编程语言无关的，最好要有示例，如此，双方都能省心。

跟F公司对接，对方直接告诉我，我要对接的这套系统已经转了好几手，现在在他手里，很多地方也不是很清楚，文档是有的，技术看起来比较老旧，签名客户端只有windows版本（无奈，只能弄一台windows机器了），没有网络拓扑图，配置说明也比较老旧，对接过程磕磕绊绊，服务器与签名客户端是两拨人，回消息比较慢，好的时候以小时计，不好的时候以天计，最后终于完成对接，发现数据唯一性跟当初对接时描述还不一样…… 此处教训是：一定一定要跟想办法跟核心开发人员对接，一定一定想方设法拿到最准确文档，虽然我们是甲方，但在对接中，从来都感觉是乙方，由此，我养成了使用敬语的习惯，话说修养真的是好。

还有其它小的、印象不深的第三方对接，虽然每个公司都有各种各样的问题，但是作为从业人员，对接人员代表的是公司的形象，说话做事定当需要审慎的态度，无论甲方乙方，都需要更加严格的要求自己，有问题势必先要自查，以数据说话，毕竟，口碑就是这么建立起来的，信任也是这样累加的。

分享经历，以此共勉。