今天天氣晴朗，大雄有個朋友火氣正旺，瘋狂給我吐槽公司後端，為了方便閱讀，前端朋友稱作前端，後端朋友稱作後端，事情大概是這樣：

後端說要聯調接口，前端說你的數據儘量按我的要求來，後端不服氣，說你這個沒用。前端就講道理呀，傳統的前後端分離返回的格式要儘量規範，這樣才好處理。

後端同意了，很快啊，啪的一下，前端這邊請求剛發出去，立馬就返回了。

誰知大意了沒有閃，一個Code碼，一個字符串，一個數組，全部接受轉換成了模型，再正常處理業務邏輯和頁面展示，前端笑了笑提交測試，很快啊，一上正式環境程序就崩潰了啊。

原是字符串沒有判空，前端說後端你不講碼德，後端說對不起，是我不懂規矩，我是亂打的代碼。好傢夥，一個訓練有素的練家子會亂打？這明明是來糊弄咱老前端，不講碼德！

朋友只能勸他耗子尾汁，好好反思，以後不要再耍這種小聰明，畢竟程式設計師要以和為貴，搞窩裡鬥是萬萬不可的，求求不要再把空值異常拋給前端了！

其實在開發過程中，前後端還會存在其他分歧，比如前端希望根據 UI 來劃分接口，這樣用戶體驗好，前端實現也容易。後端則更希望根據業務模塊劃分接口，這樣有利於服務下沉和解耦。

於是前後端之間可能會出現如下對話:

--後端: 你多調幾個接口不就行了麼~
--前端: 多好幾個 HTTP 請求呢。包成一個接口有這麼難麼？

前端和後端各有各的道理，還都不肯退讓，互相扯皮，互相看不順眼，所以結合大雄的見解，今天來分析分析為什麼前後端總是爭吵不斷？

原因一：沒有文檔或文檔不全

例如新的前端人員到了一個新的公司，使用接口時，問這個這個不知道，問那個那個不知道，要文檔沒文檔，這絕對是前端人員最抓狂的事，心裡肯定是一千隻草泥馬奔騰而過。

那為什麼需要文檔？

首先文檔是當前開發者甚至後面的接盤俠（後面開發者）能夠清晰往下做的第一步指引。

而且，從辦公效率方向考慮，即便是簡單的東西，但如果不寫文檔，以後口口相傳消耗的工作量會比寫文檔更多。

再其次就是最簡單的理由，好記性不如爛筆頭，一段時間後，可能連開發者都忘記接口的用途，可不就尷尬了。

總之，文檔是極其關鍵的，無論是在線文檔還是本地文檔。雖然寫文檔是麻煩的事，但對後端人員來說，是利人利己。

但在工作中時常也會出現這種狀況，雖有文檔，但徒有其表，文檔里對接口的描述不全，可能缺每個參數詳盡描述（取值範圍、類型）、請求方式（GET、POST、PUT、DELETE）、返回數據的所有狀態等等，這裡面可能最缺就是返回數據的狀態！

既然寫了文檔，就把文檔寫好，寫明朗。

原因二：接口參數沒校驗，問題不斷

這個前端人員倒不是很關注，因為本身調接口之前一般都會先做校驗，後端做參數校驗只是雙重保證。不過還是提醒後端人員，做好參數校驗是第一步，不要偷懶了。

但有時也不免出現以下情況：

--前端：我吊你，怎麼你分享的接口這麼多錯誤？

--後端：我吊你，你用之前不會測一測接口正不正常？

--前端：我為什麼要測？你開發的接口，你自己不測好？

--後端：我怎麼知道你要用什麼樣的數據！你要是稍微測一下接口，能有這麼多事？

……

雖然前端開發人員調接口時候，可能會存在各自各樣的問題，這是很正常的，有問題可以理解，程序哪會沒有bug，但希望不要太離譜。

原因三：沒保證接口原子性

一個原子事務要麼完整執行，要麼乾脆不執行。這意味著，工作單元中的每項任務都必須正確執行。

如果有任一任務執行失敗，則整個工作單元或事務就會被終止。即此前對數據所做的任何修改都將被撤銷；如果所有任務都被成功執行，事務就會被提交，即對數據所作的修改將會是永久性的。

所以接口的原子性是很重要的，有時一個接口可能會幹幾件事，但不一定都能正常完成，這就導致可能存在原子性問題，接口不能準確被調用。

最後給現在的或者未來的前後端大師提一嘴。

要知道，前後端是網際網路公司關係最緊密的兩個崗位，二者相互配合好，才能給使用者更好的體驗，所以還是希望雙方都能多多體諒，換位思考。

在問題出現之前就儘量規避，在出現問題時，先檢查自身，妥善處理。大家都是搬磚人，打工人何苦為難打工人呢。

>END<