> 和三方的關係要處好；

### 01
如果你看到這個話題，並不知道是什麼意思，那麼祝賀你，安安靜靜的當個小碼農也挺好；

不過我敢說，隨著職業生涯的慢慢發展，大家都得碰到，到時候就細細體會吧；

那年，我雙手插兜，不知道什麼叫三方對接；直到入職了一家金融公司後，承接了一個需求：跟銀行對接資料流水；

從此就一發不可收拾，踏上了漫漫對接路，之後跟三方對接的活，都被我全部承包了；直到我後來辦理離職手續，寫的交接文件上，除了跟xxx對接，就是yyy對接；

後來想想，也沒有那麼不堪，我大致梳理了的下，分為以下幾個點：
![](http://img.blog.itpub.net/blog/2023/03/28/e22ed2c6c5c6992f.png?x-oss-process=style/bb)

如果想做好對接，每個環節上都不允許出現問題；否則，由於某個環節拉胯，就會導致整盤對接停滯，最終，專案**延期交付**；

說到延期交付，那你就做好被**開大會**的準備吧；

會議上那是“**八仙過海，各顯神通**”；大家各說各的，反正，並不是自己的問題；誰想背鍋？背鍋就是績效問題，就是money問題；

### 02
**【對接文件】**
哦，在說對接文件之前，我還不得不提一下對接之前的事宜；

公司商務人員或業務人員可能會頻繁的出差，有時候還會把你們技術老大叫上，為啥？還不是為了避免聊到技術問題，不會解答，讓他兜底去的；

好吧，繼續說回對接的事情；

一般拿到這種跟甲方對接的需求，對方會有文件拋過來的；至於這個文件是什麼形式，反正五花八門，可真實有用的內容，也就那麼幾行；

在對接的文件中，我們主要關心的還是以下幾個要點：**加密方式、介面、傳輸形式**；

首先，**加密方式**；每個對接的三方各有各的要求，一般都會對請求報文做加密、加簽等處理，或者請求做授權處理；也不排除少部分不需要做處理；

**請求報文加密**：可以使用對稱性加密，非對稱性加密等方式；對稱性加密，就是使用同一個金鑰，對資料進行加解密，這樣相對來說安全性差點；所以會使用非對稱性加密的方式較多，非對稱性加密，三方會生成一個金鑰對，分為私鑰和公鑰，私鑰三方儲存，用來對資料解密；公鑰提供給我們，我們透過公鑰對資料進行加密；
![](http://img.blog.itpub.net/blog/2023/03/28/c0e2e796b0d47f9e.png?x-oss-process=style/bb)

**請求報文加簽**：與上面一樣，使用非對稱性加密方式，對於原始資料進行加簽；只不過這裡需要注意的是，金鑰對是自己生成的，自己儲存私鑰，用私鑰對資料簽名，把原始報文和簽名後的報文，一起傳給三方；然後三方透過我們提供的公鑰進行驗籤；
![](http://img.blog.itpub.net/blog/2023/03/28/e075d9fce467edec.png?x-oss-process=style/bb)

如果用兩種方式一起使用，是可行的；如果在實際情況下，那就根據甲方的要求，具體使用哪種方式吧；萬一，他們要求不需要什麼加密，這，也沒毛病；

總結一下就是；

加密：**保證資料不被洩露，公鑰加密，私鑰解密；**

驗籤：**保證資料不被篡改，私鑰加簽，公鑰驗籤；**

私鑰：**自己儲存；**

公鑰：**公開，可多人持有；**

**請求授權處理**：有些三方介面，在你請求之前，需要對方開通apiKey和appSecret，然後拿到一個授權的token；在請求業務介面的時候，需要將這個token一併帶過去，否則，不能請求；

這個不難理解，為的就是給系統介面多一層保障；看對方怎麼要求，就怎麼做吧；

> 最後還會有一層保障，在網路層面，雙方運維會配置IP白名單；

第二個，**傳輸形式**；首先得看清介面的協議，常見是HTTP、HTTPS，少部分也是會用SOCKET，RPC等方式；

報文的格式：我覺得常見的還是兩種，一種是JSON形式，另一種是XML形式；JSON格式主要搭配的是HTTP或HTTPS協議，常見的系統都是這麼對接；XML格式一般會和SOCKET搭配，少部分會用這種形式，比如銀行系統；

最後，**介面本身**；這個也是最重要的環節，言外之意就是介面的欄位；包括欄位的命名、型別、限制長度、業務意義等；

欄位命名，這個沒什麼好講；幾乎所有系統都是英文命名，在英文命名的基礎上，許多系統會採用駝峰命名法；

欄位型別，一共幾種形式；

字串，這種型別想必大家都不陌生，是最常見和最常用的一種型別；

數值，主要是金額、年齡、數量等，會上該型別，包含浮點和整型；

物件，它是基礎型別的綜合，如字串、數值、物件等，統一組合在一起，組成一種業務意義的型別；比方一個學生物件型別，包含姓名（字串）、年齡（數值）、班級（物件）；

集合，就是一種或多種同型別的物件；還是學生的例子，把一個或多個學生物件放在一起，就組合成一個集合型別；

如果還需要三方將資料傳輸給我方系統的話，那就需要我們提供介面和介面文件了；

寫介面，那是開發方面的事情，暫且不談；提供介面文件，其實也是個技術活；

由於是我方的介面，一般上文講的方面，都是我方決定的，但是，總有個別特例；

我曾經遇到過，明明是對方需要呼叫我方介面，可是，介面文件，傳參，傳輸方式，協議等等，都已經“幫”我們定好了；

驚呆了，老鐵！好吧，誰讓你是甲方呢；

言歸正傳，正常流程是我們定義好自己的介面，然後再根據介面，擬定一份文件，文件內容無外乎就是上文提到過的內容；

編寫介面文件的工具有很多，大家可以參考我之前寫的**《文件&工具》**篇，裡面具體列舉了好用的一些工具；

總之，拿到對接文件，並且提取上面有用的內容，只是整個對接流程的第一步；

最後再說一遍，介面的欄位很重要，千萬別弄錯了！

### 03
**【對接溝通】**
熟讀對方提供的介面文件之後，其實還不能進入開發階段；原因無他，就是這份文件並不是最終的版本，它需要在溝通的過程中不斷去修改和完善；

需要溝通什麼？總不會和別人去聊家常吧，當然是在看文件的過程中發現了你把握不住的問題，或者有疑問的業務場景；

和誰溝通？這時候你需要溝通的有兩類人，一個是我方的業務經理或產品經理，另一個是三方的開發；

對應的問題找對應的人，當你覺得業務上有疑問，可以跟自家產品經理去進行battle；當你們產品經理不懂技術的時候，那麼事情就變得簡單多了；

在不影響最終功能的前提下，可以儘可能將技術實現變得簡單點，這是跟自家產品討論需求的核心要素；反正他不清楚技術實現，就使勁忽悠，總之自己要講的有理有據，真假結合；場面堪比旺仔碰到奧姑，一個真敢說，一個真敢信；

但是有那麼一小部分產品經理，他是懂點技術的，或者他就是開發轉的產品，那就當我沒說；

迴歸文件本身，當你覺得介面存在問題，那就不得不找到三方的開發了；

最後一頓溝通下來，如果對方文件是有問題的，就繞不開文件的修改和調整，務必讓對方將調整過的文件發過來，記得做好文件變更，最好將上一版的文件也一併保留；
![](http://img.blog.itpub.net/blog/2023/03/28/ea99ce873060e063.png?x-oss-process=style/bb)

溝通途徑：一般常見的有群聊、電話、會議、內部通訊軟體等等；最後還有一種，叫口頭溝通，這種方式水很深，坑很大，要小心提防，至於為何，懂的都懂；

在對接過程中，溝通是必不可缺的一個環節，良好的溝通能夠提高效率和產出，與其說是和第三方對接，倒不如說和三方保持溝通；

### 04
**【協調資源】**
協調其實也是溝通的另一種表達方式，只不過協調過程中會涉及更廣的方面，所以單獨拿出來說說；

所謂協調，其實是對資源的協調，資源大致分為三種：**人力、時間、成本**；
![](http://img.blog.itpub.net/blog/2023/03/28/5665ebc80d7785e6.png?x-oss-process=style/bb)

**人力資源**：即參與對接流程的所有人；

我方人員主要涉及後端開發，運維，測試；這裡的這幾類人，包括我方和三方的人，這裡沒有將前端開發歸類進去，因為一般不會涉及到前端開發；

整個對接流程環環相扣，一旦某個環節卡殼，就會導致下一步不能進行下去；
![](http://img.blog.itpub.net/blog/2023/03/28/bc765240463a5f8a.png?x-oss-process=style/bb)

在不同的環節下，都會有不同的人去參與，如果你是主導開發，就需要合理發揮自己的協調能力，將每個環節的人合理利用起來，記住要保持高效的溝通；

**時間資源**：就是需要花費的時間；

一個優秀的主導人員，在人員協調的過程中，處理的得心應手，溝通起來也很順暢，那麼事情肯定是事半功倍的；

反之，團隊中的人員不僅各個叫苦不迭，甚至到了後面都不願配合，最後肯定是事倍功半的；

所以，要想得到更高效的時間，主要取決於上述的人力資源是否得到合理的協調，是否保持良好的溝通；看來，領頭的尤為重要；

**成本**：顧名思義，就是需要的開銷，這裡一般指伺服器資源；

伺服器涉及到成本控制的問題，需要部署多少臺服務，每臺服務需要的配置，會不會涉及到中介軟體伺服器等等；

從上級的角度考慮，他們肯定覺得花費越少的成本越好，服務資源越少越好，但是最終決定還得是甲方；

比如需要一個專項檔案互動的FTP伺服器，這時候不僅僅得有系統服務，還得額外加上中介軟體伺服器；

大多數情況下，我們作為一名開發，只需要擰好我們的螺絲，別的，也確實跟我們無關；

但是，經歷過跟三方的對接，你會開啟新世界的大門，特別是這次對接需求全權由你作為主導的時候；

你會發現，開發僅僅只是佔用了你一小部分時間，更多時間都用來溝通和協調去了；

曾經接到過一個緊急的對接任務，要求三天對接結束，一週內上線；上線後我發現，除去測試兩天，剩餘五天只有一天實打實坐在位置上開發，其他時間不是在跟對面會議群聊，就是在跟產品經理鬥智鬥勇，還有一天時間在運維那邊配合他部署服務，並且連通與對方的網路；

### 05
**【開發排期】**
這是每次承接到需求都不得不去做的一份表格，為的是合理安排時間，做好開發計劃；

但是也有一部分特例，好多流程都可以忽略，甚至不用測試；想必都猜到了，那就是傳說中的**緊急需求**；如果需求中涉及到與三方的對接，在緊急也沒用，上線時間全憑對方的配合度；

言歸正傳，其實開發排期是門技術活，它不僅需要你合理的安排好每個開發的時間，並且還要為測試預留好充足的時間，最後，還需要考慮到跟三方的溝通時間，聯調時間等等；

如果排期評估的時間過長，上級臉色難免會不太好看，可是評估的時間過短，需要讓每個成員做好加班的準備，這種極限拉扯，舉棋不定，不得不說，難啊；

換做是我，我會將自己團隊需要開發的部分按成員的能力分配，時間按難易程度調整，整體把控不超過上級預設的時間，最後加上附加情況，“由於涉及到三方部分，不能把控具體時間”；意思直接將這個鍋甩到領導身上，他又不得不接，他會去主動協調三方資源；

### 06
**【對接開發】**
上文提到過，其實開發是整個對接流程中佔用時間最少的，但卻是最重要的環節，畢竟說的再多，最終還得程式碼邏輯和執行沒問題；

在我承接的對接需求中，我通常會先確定好其中的介面、需求、排期等等沒有異議了，再去做開發，因為只要熟知了其中的套路，開發起來並不難；

如果承接需求是一整個團隊，而在整個對接的環節中，一不小心只被分配到了開發的活，那麼就中獎了，這次任務你最輕鬆；

不過，大多數情況下，參與的人就那麼兩三個，那麼得身兼數職，溝通、協調、對接等等都得你來，等你心力憔悴的時候，還需要穿插寫點這次對接相關的介面；

今年體會過一個人承擔整個流程，為何？人都被最佳化沒了，只能獨自抗下所有；

好好享受僅作為開發的時刻，回想起來，那會是你職業生涯中最開心的一段時光；

### 07
**【流程提測】**
費盡“九牛二虎”之力，完成對接聯調，一切流程都感覺沒問題，那就可以進入下個環節，提測；

在提交測試之前，還需要做一步操作：與測試一起過一遍要測試的範圍，以及各自對需求的理解；

雙方達成一致的共識，對業務需求保持統一的理解，**這是非常有必要的**，當然最終的解釋權在於產品經理；

若是三方對接的測試需求，還需要額外提供一份模擬資料，以供測試同學能夠模擬走完整個流程；

涉及到雙方都參與的流程，無非是雙方的介面聯調，當測試走到這塊流程的時候，更多情況下，是需要用到模擬資料的；

怎麼準備模擬資料，分兩種情況：我方請求三方，三方請求我方；

- 當三方將資料傳輸過來，可以讓對方提供一份方便測試的未加密的請求報文，如果對方不提供，可以在平時的對接過程中，對三方解密後的報文進行入庫儲存，在提測時提供給測試同學即可；

- 當需要我方將資料傳輸三方的時候，一般我方測試會透過走流程的方式，去調對方的介面，可以不需要模擬的資料；但是以防萬一，也可以將請求報文提供，特殊情況下，可以跳過流程，直接測對方介面；

在這個階段，也會涉及到溝通，但更多的是測試同學和三方開發之間的溝通；但是當他們在溝透過程中，涉及技術方面的問題，也是需要我們開發去介入；

當按照雙方約定的資料、報文格式等走完測試流程，是該到了釋出的時刻，只需要雙方溝通好，統一時間釋出即可；

### 08
說了這麼多，溝通才是三方對接的主旋律，保持高效的溝通，就是成功的第一步；

**那麼，問題來了**；

遇上難以溝通的甲方，你會如何處理？

```
Git-「butte-java-note」倉庫

https://gitee.com/cicadasmile/butte-java-note
```

三方對接「心得」與「體會」

相關文章