和三方的關系要處好；
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.uj5u.com/houduan/548553.html
標籤：Java
上一篇：【Visual Leak Detector】配置項 SkipHeapFreeLeaks
下一篇：有了HTTP，為啥還要用RPC