調接口到底在調什麼，工作量在哪？

做為一個不懂技術的IT從業者，常聽人講，今天在調接口，然後調通幾個接口就要好久，感覺好大工作量的樣子。我想問，調接口到底在調什麼？工作量在哪裡？希望科技大神可以深入淺出的給我科普一下。萬分感謝！ （如果不能深入淺出，深入一點也好，我慢慢查百科，哈哈。再次感謝！）

回覆內容：

調接口調的是你跟你同事對同一份需求的不同的理解，這種東西是無法估量的，誰讓你們不從第一天開始就密切合作。這就是為什麼我反對server和client用兩個人來寫。 IT都已經這麼多年了，把人當CPU超流水線不就好了嗎，你先做server，等你做完了去做client。就算因為臨時原因被迫server和client一起寫，也應該每次都同時啟動真實的server和client，出了事不要擔心block了別人，兩個人合作一起搞定。

雖然前期感覺時間好像被浪費掉了，但是眼光放長遠，總的來說效率要提高好幾倍。

理想情況。

server：我ok了你呼叫吧！

client：我測試呼叫ok，準備提測！

實際（國內）情況。

server：我ok了你呼叫吧！

client：500了

server：我看看，好像某段舊程式碼異常。 。

（半小時後）

server：我ok了你呼叫吧！

client：還是500

server：算了我重構下舊程式碼。

（兩人小時後）

server：我ok了你呼叫吧！

client：還是500。 。你吖的把參數改了？

server：重構了嘛，按新的參數來調

client：這個介面ok了，那個又掛了

server：我都改了一遍參數，你也該改

client：搞個文檔吧

server：有線故障我要緊急處理下

client：ok（然後泡個茶刷刷知乎）

（一小時後）

client組長：聯調ok沒？我們客戶端要趕緊出新版，我怎麼看你好像很閒

client：在等server給新文檔

client組長：等個p啊趕緊給我搞完，不然績效給你-1s

client ：server快過來我們快速搞定介面啦，要死人

server：媽蛋故障還沒處理完呢，我就幫你十分鐘哈

server組長：故障排除了麼？我們得服務要確保品質啊

server：在跟client聯調稍後過來

server組長：聯個p啊，趕緊給我搞定故障，不然績效給你-1s

client&server：我真是日了狗了

調接口的精髓在於“等” 工作量就在調上啊。軟體生產這東西為什麼叫開發不叫製造，就是因為要不斷試。 與某關聯係統聯調接口，
0約定聯調的那一天，他們告訴我，剛開始開發，過兩天再聯調。
1介面文件他們可以改三版，每版的出參名字都不一樣。
2說好的五個出參可以突然變成兩個，告知有缺陷以後，回退修復花了半天，又在臨上線前兩天，又只有兩個出參了。
3AB兩個介面呼叫順序，國慶加班的時候已經告知，十天以後發現順序還是錯的
4上線驗證的時候發現調用C接口的時候多調用了D，昨晚我就沒睡踏實
大家都是做IT的，哼╭(╯^╰)╮ 不會是我老闆問的吧 標準專案流程是這樣的。

PM出專案需求文件和MRD -> PM聯繫相關人員進行MRD評審-> 設計師基於MRD做設計圖-> 後端工程師根據專案需求和MRD、設計圖出服務端介面文件-> 前端工程師進行介面文件審核-> 前後端工程師並行開發與獨立自測-> 前後端開發完畢後進行介面聯調-> 測試人員進行測試-> 測試完畢發佈上線-> 線上服務功能回歸

如果完全按照這個流程開發，每一步都進行的很好，自然是ok的。但由於後端工程師對自己的自信，經常沒有進行充分自測(甚至壓根不測)，導致前後端進行聯調的時候，前端發現後端不可用，然後後端去修復問題，一來二去時間自然就沒了(前端出問題，後端也不知道)，專案就delay了。同樣的，如果介面文檔寫的不清楚，導致前後端對參數的理解不一樣，也會導致介面的修改或前端實現的修改，次數多了，專案也就delay了。

由於這種事情太常見了，所以一般聯調的時間都包含了自測的時間，所以這個測試時間一加進去，聯調時間自然就長了。

我不認為輪子哥的方法是好方法，術業有專攻，人的精力是有限的。即使一個人是全端工程師，那他也是有更擅長的一項，再者，不同語言，不同端的開發都有自己的開發規範，經常輪換的話，會浪費大量的精力，而且切換語言開發也降低開發效率。再說了，一個大的專案不可能完全由一個人開發，只要是多人協作，就會出現這種問題，如果是修改同一個模組的程式碼，更容易出現問題，即使不是在聯調階段，在開發階段出問題就不降低效率麼？流程上的問題，就應該透過規範流程解決，而不是拆東牆補西牆的方式。 首先，假設你說的是調（二聲）接口，而不是調（四聲）接口。因為後者不存在什麼工作量的問題。

之前有個問題答案說的是護照過期重辦時遇到的問題，和調接口的問題一致。

假設小明（我方）現在要出國，需要辦護照（業務需求）。

小明到公安局網站（介面提供者）上查詢辦證指南（介面文件），上面說辦護照需要：

• 一張照片
  
• 身分證
  

這些資料（參數）。小明可以在網路上預約（介面 1），能拿到一個預約號碼（介面 1 呼叫結果），然後可以到戶口所在地的公安局辦理。或可以直接去公安局（接口 2），但是不一定當天能約上。

小明決定試試網路預約，結果網站顯示「預約成功」（介面與文件不一致）。然後你想，好，成功了（我方疏忽）。

小明拿著照片和身分證去了公安局，結果公安局小妹手一攤：號兒呢？

啥號？

預約號碼啊？

沒有啊？

沒有不算，要不然你上網再約，拿到預約號，要不然你就現場約。 （結果與預想不同，重來）

小明那一想，我就現場約吧。正要預約時，聽到另一個工作人員跟小妹兒說最近系統在升級，可能還有些問題，還多人都預約了沒拿到號（提供方在升級、重構）。小妹兒一看小明這可憐吧唧請一天假要被領導屌爆的樣子，就算了，讓小明今天就辦（雙方協商處理方案）。

小明開心了，拿出了照片和身分證，準備辦證（呼叫介面 2）。

小妹一看，說：你這是什麼？

照片…啊？

不行，你這不合規矩，護照照片必須標準化，A 像館是我們專門合作方，你去找他們照相，數據直接傳我們這來，帶身份證來就行（第 2 個提供方）。

小明無語了。你們為什麼在網站上不說清楚啊？

小妹說原來你去看網站，我們網站那是前年做的了，政策早就變了（文件沒跟上）。

小明只好去 A 像館。

A 像館一聽，哦，知道，你來照吧。然後照了，說，可以了，我給你上傳到他們系統，你直接去就好。

小明又回公安局。

小妹：等下啊，今天網有點慢，照片一直沒傳過來（提供方之間的介面呼叫問題）。

等啊等，等到快下班了，終於傳過來了。

小妹：好了，終於下載下來了，可以開始了。

小明長舒一口氣。

小妹：等等，不行，我們系統提交通道關閉了。

小明：？ ？ ？

小妹：是這樣，我們老闆很愛我們，所以在設計辦公室系統的時候，要求還有半小時下班的時候就關閉業務通道，這樣我們就可以整理下桌子，然後聊聊晚上去哪兒吃飯。

小明：？ ？ ？

小妹：不好意思啊，明天趕早吧。

小明只好隔天又去公安局。

小妹：真是不好意思，昨晚英鎊暴跌，突然來了兩千多人要辦護照去英國掃貨。

小明：？ ？ ？

小妹：我們這個系統有點老，只要排隊的人超過 255 個人就會死機（意外情況）。

小明：？ ？ ？

小妹：我們負責體制的人今天二婚，明天就回來。

小明：？ ？ ？

小妹：啥時候能修好，不知道啊。你明天或後天打電話問下來吧。

小明口吐鮮血。

============

調介面就是這樣一個過程。

工作量和麻煩不外乎：

• 供應方對於業務的描述不完整。其緣由可能是：1、沒想清楚；2、懶或沒動力；3、升級或業務改變之後沒跟上；4、故意製造麻煩。所以，需要不停地溝通，去反覆確認，或是呼叫介面來看看結果是否符合預期。
• 我方與各供應方，以及供應方與其他供應方之間出了合作問題，一個步驟的問題影響全局。這是常發生的事——我過單行道也會左右看，因為即便你能保證你自己做好，也沒辦法保證別人能同樣做好。其道理一致。所以，需要等，或是從中調和，或是想別的辦法解決。

除了這些之外，介面在某些意外情況下會出現意外的問題（例如高並發之類），這也是需要調試的。

知道了這些之後，就會對秦始皇統一度量衡的壯舉狂豎大拇指，因為他避免了不同標準和介面之間的溝通。全天下用同一個接口，溝通成本大大降低。

所以，調接口這件事，你是大爺，你就是調教接口，你是小弟，你就調整自己心態。

老大去包子鋪問，你們這有沒有漢堡？老闆分分鐘跑到對面麥當勞買漢堡回來然後把餡料換成鮮肉的笑嘻嘻地雙手捧上來。這就沒什麼工作量，對方可以來適應你。

反之，你就只能自己去麥當勞買個漢堡，自己買個鮮肉包子把餡料拆出來，忍受別人的白眼，默默把漢堡吃掉。

這工作量自然就大了。 就跟你去銀行辦卡一樣 還好我們團隊是js跑通前後端的，一個需求可以從migration檔案寫到前端效果。而設計師給的設計交付物是點一下圖形就能取到相關css資訊的展示頁面，所以並沒有扯皮的機會。