百木园-与人分享,
就是让自己快乐。

三方对接「心得」与「体会」

和三方的关系要处好;

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

说了这么多,沟通才是三方对接的主旋律,保持高效的沟通,就是成功的第一步;

那么,问题来了

遇上难以沟通的甲方,你会如何处理?

Gitee主页: https://gitee.com/cicadasmile/butte-java-note


来源:https://www.cnblogs.com/cicada-smile/p/17265709.html
本站部分图文来源于网络,如有侵权请联系删除。

未经允许不得转载:百木园 » 三方对接「心得」与「体会」

相关推荐

  • 暂无文章