和三方的关系要处好；
01
如果你看到这个话题，并不知道是什么意思，那么恭喜你，安安静静的当个小码农也挺好；
不过我敢说，随着职业生涯的缓缓倒退，大家都得碰到，到时候就细细领会吧；
那年，我双手插兜，不晓得什么叫三方对接；直到入职了一家金融公司后，承接了一个需要：跟银行对接数据流水；
从此就一发不可收拾，踏上了漫漫对接路，之后跟三方对接的活，都被我全副承包了；直到我起初办理到职手续，写的交接文档上，除了跟 xxx 对接，就是 yyy 对接；
起初想想，也没有那么不堪，我大抵梳理了的下，分为以下几个点：
如果想做好对接，每个环节上都不容许呈现问题；否则，因为某个环节拉胯，就会导致整盘对接停滞，最终，我的项目 延期交付；
说到延期交付，那你就做好被 开大会 的筹备吧；
会议上那是“八仙过海，各显神通”；大家各说各的，反正，并不是本人的问题；谁想背锅？背锅就是绩效问题，就是 money 问题；
02
【对接文档】
哦，在说对接文档之前，我还不得不提一下对接之前的事宜；
公司商务人员或业务人员可能会频繁的出差，有时候还会把你们技术老大叫上，为啥？还不是为了防止聊到技术问题，不会解答，让他兜底去的；
好吧，持续说回对接的事件；
个别拿到这种跟甲方对接的需要，对方会有文档抛过去的；至于这个文档是什么模式，反正形形色色，可实在有用的内容，也就那么几行；
在对接的文档中，咱们次要关怀的还是以下几个要点：加密形式、接口、传输模式；
首先，加密形式；每个对接的三方各有各的要求，个别都会对申请报文做加密、加签等解决，或者申请做受权解决；也不排除少部分不须要做解决；
申请报文加密：能够应用对称性加密，非对称性加密等形式；对称性加密，就是应用同一个密钥，对数据进行加解密，这样相对来说安全性差点；所以会应用非对称性加密的形式较多，非对称性加密，三方会生成一个密钥对，分为私钥和公钥，私钥三方保留，用来对数据解密；公钥提供给咱们，咱们通过公钥对数据进行加密；
申请报文加签：与下面一样，应用非对称性加密形式，对于原始数据进行加签；只不过这里须要留神的是，密钥对是本人生成的，本人保留私钥，用私钥对数据签名，把原始报文和签名后的报文，一起传给三方；而后三方通过咱们提供的公钥进行验签；
如果用两种形式一起应用，是可行的；如果在理论状况下，那就依据甲方的要求，具体应用哪种形式吧；万一，他们要求不须要什么加密，这，也没故障；
总结一下就是；
加密：保证数据不被泄露，公钥加密，私钥解密；
验签：保证数据不被篡改，私钥加签，公钥验签；
私钥：本人保留；
公钥：公开，可多人持有；
申请受权解决：有些三方接口，在你申请之前，须要对方开明 apiKey 和 appSecret，而后拿到一个受权的 token；在申请业务接口的时候，须要将这个 token 一并带过来，否则，申请有效；
这个不难理解，为的就是给零碎接口多一层保障；看对方怎么要求，就怎么做吧；
最初还会有一层保障，在网络层面，单方运维会配置 IP 白名单；
第二个，传输模式；首先得看清接口的协定，常见是 HTTP、HTTPS，少部分也是会用 SOCKET，RPC 等形式；
报文的格局：我感觉常见的还是两种，一种是 JSON 模式，另一种是 XML 模式；JSON 格局次要搭配的是 HTTP 或 HTTPS 协定，常见的零碎都是这么对接；XML 格局个别会和 SOCKET 搭配，少部分会用这种模式，比方银行零碎；
最初，接口自身；这个也是最重要的环节，话中有话就是接口的字段；包含字段的命名、类型、限度长度、业务意义等；
字段命名，这个没什么好讲；简直所有零碎都是英文命名，在英文命名的根底上，许多零碎会采纳驼峰命名法；
字段类型，一共几种模式；
字符串，这种类型想必大家都不生疏，是最常见和最罕用的一种类型；
数值，次要是金额、年龄、数量等，会上该类型，蕴含浮点和整型；
对象，它是根底类型的综合，如字符串、数值、对象等，对立组合在一起，组成一种业务意义的类型；比如一个学生对象类型，蕴含姓名（字符串）、年龄（数值）、班级（对象）；
汇合，就是一种或多种同类型的对象；还是学生的例子，把一个或多个学生对象放在一起，就组合成一个汇合类型；
如果还须要三方将数据传输给我方零碎的话，那就须要咱们提供接口和接口文档了；
写接口，那是开发方面的事件，暂且不谈；提供接口文档，其实也是个技术活；
因为是我方的接口，个别上文讲的方面，都是我方决定的，然而，总有个别特例；
我已经遇到过，明明是对方须要调用我方接口，可是，接口文档，传参，传输方式，协定等等，都曾经“帮”咱们定好了；
惊呆了，老铁！好吧，谁让你是甲方呢；
言归正传，失常流程是咱们定义好本人的接口，而后再依据接口，拟定一份文档，文档内容无外乎就是上文提到过的内容；
编写接口文档的工具有很多，大家能够参考我之前写的 《文档 & 工具》 篇，外面具体列举了好用的一些工具；
总之，拿到对接文档，并且提取下面有用的内容，只是整个对接流程的第一步；
最初再说一遍，接口的字段很重要，千万别弄错了！
03
【对接沟通】
熟读对方提供的接口文档之后，其实还不能进入开发阶段；原因无他，就是这份文档并不是最终的版本，它须要在沟通的过程中一直去批改和欠缺；
须要沟通什么？总不会和他人去聊家常吧，当然是在看文档的过程中发现了你把握不住的问题，或者有疑难的业务场景；
和谁沟通？这时候你须要沟通的有两类人，一个是我方的业务经理或产品经理，另一个是三方的开发；
对应的问题找对应的人，当你感觉业务上有疑难，能够跟自家产品经理去进行 battle；当你们产品经理不懂技术的时候，那么事件就变得简略多了；
在不影响最终性能的前提下，能够尽可能将技术实现变得简略点，这是跟自家产品探讨需要的外围因素；反正他不分明技术实现，就使劲忽悠，总之本人要讲的有理有据，虚实联合；局面堪比旺仔碰到奥姑，一个真敢说，一个真敢信；
然而有那么一小部分产品经理，他是懂点技术的，或者他就是开发转的产品，那就当我没说；
回归文档自身，当你感觉接口存在问题，那就不得不找到三方的开发了；
最初一顿沟通下来，如果对方文档是有问题的，就绕不开文档的批改和调整，务必让对方将调整过的文档发过来，记得做好文档变更，最好将上一版的文档也一并保留；
沟通路径：个别常见的有群聊、电话、会议、外部通信软件等等；最初还有一种，叫口头沟通，这种形式水很深，坑很大，要小心提防，至于为何，懂的都懂；
在对接过程中，沟通是必不可缺的一个环节，良好的沟通可能提高效率和产出，与其说是和第三方对接，倒不如说和三方放弃沟通；
04
【协调资源】
协调其实也是沟通的另一种表达方式，只不过协调过程中会波及更广的方面，所以独自拿出来说说；
所谓协调，其实是对资源的协调，资源大抵分为三种：人力、工夫、老本；
人力资源：即参加对接流程的所有人；
我方人员次要波及后端开发，运维，测试；这里的这几类人，包含我方和三方的人，这里没有将前端开发归类进去，因为个别不会波及到前端开发；
整个对接流程环环相扣，一旦某个环节卡壳，就会导致下一步不能进行上来；
在不同的环节下，都会有不同的人去参加，如果你是主导开发，就须要正当施展本人的协调能力，将每个环节的人正当利用起来，记住要放弃高效的沟通；
工夫资源：就是须要破费的工夫；
一个优良的主导人员，在人员协调的过程中，解决的得心应手，沟通起来也很顺畅，那么事件必定是事倍功半的；
反之，团队中的人员不仅各个叫苦不迭，甚至到了前面都不愿配合，最初必定是事倍功半的；
所以，要想得到更高效的工夫，次要取决于上述的人力资源是否失去正当的协调，是否保持良好的沟通；看来，领头的尤为重要；
老本：顾名思义，就是须要的开销，这里个别指服务器资源；
服务器波及到老本管制的问题，须要部署多少台服务，每台服务须要的配置，会不会波及到中间件服务器等等；
从下级的角度思考，他们必定感觉破费越少的老本越好，服务资源越少越好，然而最终决定还得是甲方；
比方须要一个专项文件交互的 FTP 服务器，这时候不仅仅得有零碎服务，还得额定加上中间件服务器；
大多数状况下，咱们作为一名开发，只须要拧好咱们的螺丝，别的，也的确跟咱无关；
然而，经验过跟三方的对接，你会关上新世界的大门，特地是这次对接需要全权由你作为主导的时候；
你会发现，开发仅仅只是占用了你一小部分工夫，更多工夫都用来沟通和协调去了；
已经接到过一个紧急的对接工作，要求三天对接完结，一周内上线；上线后我发现，除去测试两天，残余五天只有一天实打实坐在地位上开发，其余工夫不是在跟对面会议群聊，就是在跟产品经理斗智斗勇，还有一天工夫在运维那边配合他部署服务，并且连通与对方的网络；
05
【开发排期】
这是每次承接到需要都不得不去做的一份表格，为的是合理安排工夫，做好开发计划；
然而也有一部分特例，好多流程都能够疏忽，甚至不必测试；想必都猜到了，那就是传说中的 紧急需要；如果需要中波及到与三方的对接，在紧急也没用，上线工夫全凭对方的配合度；
言归正传，其实开发排期是门技术活，它不仅须要你正当的安顿好每个开发的工夫，并且还要为测试预留好短缺的工夫，最初，还须要思考到跟三方的沟通工夫，联调工夫等等；
如果排期评估的工夫过长，下级脸色难免会不太好看，可是评估的工夫过短，须要让每个成员做好加班的筹备，这种极限拉扯，举棋不定，不得不说，难啊；
换做是我，我会将本人团队须要开发的局部按成员的能力调配，工夫按难易水平调整，整体把控不超过下级默认的工夫，最初加上附加状况，“因为波及到三方局部，不能把控具体工夫”；意思间接将这个锅甩到领导身上，他又不得不接，他会去被动协调三方资源；
06
【对接开发】
上文提到过，其实开发是整个对接流程中占用工夫起码的，但却是最重要的环节，毕竟说的再多，最终还得代码逻辑和执行没问题；
在我承接的对接需要中，我通常会先确定好其中的接口、需要、排期等等没有异议了，再去做开发，因为只有熟知了其中的套路，开发起来并不难；
如果承接需要是一整个团队，而在整个对接的环节中，一不小心只被调配到了开发的活，那么就中奖了，这次工作你最轻松；
不过，大多数状况下，参加的人就那么两三个，那么得身兼数职，沟通、协调、对接等等都得你来，等你心力憔悴的时候，还须要交叉写点这次对接相干的接口；
往年领会过一个人承当整个流程，为何？人都被优化没了，只能单独抗下所有；
好好享受仅作为开发的时刻，回想起来，那会是你职业生涯中最开心的一段时光；
07
【流程提测】
费尽“九牛二虎”之力，实现对接联调，所有流程都感觉没问题，那就能够进入下个环节，提测；
在提交测试之前，还须要做一步操作：与测试一起过一遍要测试的范畴，以及各自对需要的了解；
单方达成统一的共识，对业务需要放弃对立的了解，这是十分有必要的，当然最终的解释权在于产品经理；
若是三方对接的测试需要，还须要额定提供一份模仿数据，以供测试同学可能模仿走残缺个流程；
波及到单方都参加的流程，无非是单方的接口交互，当测试走到这块流程的时候，更多状况下，是须要用到模仿数据的；
怎么筹备模仿数据，分两种状况：我方申请三方，三方申请我方；
- 当三方将数据传输过去，能够让对方提供一份不便测试的未加密的申请报文，如果对方不提供，能够在平时的对接过程中，对三方解密后的报文进行入库存储，在提测时提供给测试同学即可；
- 当须要我方将数据传输三方的时候，个别我方测试会通过走流程的形式，去调对方的接口，能够不须要模仿的数据；然而以防万一，也能够将申请报文提供，非凡状况下，能够跳过流程，间接测对方接口；
在这个阶段，也会波及到沟通，但更多的是测试同学和三方开发之间的沟通；然而当他们在沟通过程中，波及技术方面的问题，也是须要咱开发去染指；
当依照单方约定的数据、报文格式等走完测试流程，是该到了公布的时刻，只须要单方沟通好，对立工夫公布即可；
08
说了这么多，沟通才是三方对接的主旋律，放弃高效的沟通，就是胜利的第一步；
那么，问题来了；
遇上难以沟通的甲方，你会如何解决？
Git-「butte-java-note」仓库
https://gitee.com/cicadasmile/butte-java-note