前後端分離，後台返回的數據前端沒法寫，怎麼辦？

01-05

後台phper太菜了，總是返回一些key和value都是變數的object給我，或者是缺胳膊少腿的數據，還有就是英文和功能對不上的介面，首頁不是index而是first？getNav就getNav，寫一些百度都查不出來的非單詞英文，比如gation…navigation是取後半段作為介面名字的嗎？經常反過來的數據導致前端無法準確便利和獲取數據，或者說要寫大量填坑代碼…有時候看到數據都無從下手，跟他說又不聽，一直說數據沒問題，你前端不會處理數據什麼什麼的巴拉巴拉。到底是我太菜了還是什麼……
不是json格式問題，
問題是一般都是[{name:god,id:1},{name:dog,id:2}]，他寫了個[{god:1},{dog:2}]我怎麼去遍歷…………

瀉藥。

首先普及一下前後端正常交互的流程。

1、評審階段：產品召集前後端進行需求評審，前後端各自捋清楚自己的業務量以及聯調之間工作量，從而進行開發時間評估。

2、開發準備階段：前後端一起商量需求中需要聯調的部分，進行介面的口頭協議交流。

3、介面定義階段：前後端中的一方根據之前的口頭協議擬定出一份詳細的介面，並書寫API文檔，完成後由另一方確認。有疑問的地方重新商量直至雙方都沒有問題。

注意：第一份確認並書寫好API的介面基本不會大改。

4、開發階段：雙方根據協商出來的介面為基礎進行開發，如在開發過程中發現需要新增或刪除一些欄位，重複步驟3。

注意：前端在開發過程中記得跟進介面，mock數據進行本地測試。

5、聯調階段：雙方獨自的工作完成，開始前後端聯調，如在聯調過程發現有疑問，重複步驟3，直至聯調完成。

6、產品體驗階段：將完成的需求交給產品，讓其體驗，直至產品這邊沒有問題

7、提測階段：將完成的需求提給測試人員，讓其對該需求進行測試，如發現問題，及時通知開發並讓其修改，直至需求沒有bug。

8、評審單發布階段：前後端中的一人進行評審單的擬定，發送給對應的領導，表明需求發布的程序，包括影響到的頁面及業務，發布的流程，發布的回滾方案等。

9、發布階段：前後端雙方在保證步驟1-8都沒有問題了，進行各自的代碼發布，完成後由測試人員在線上進行相應的測試，如果有bug，重複步驟7和9，直至需求成功上線。

----------------------分割線--------------------

這裡給你提供一個正常介面文檔的書寫格式（欄位名協商擬定）

最後，老規矩，收藏不點贊的都是流氓（~逃）

溝通問題，如果後端自己不知道怎麼正確的返回規範的數據，你需要自己把問題都列出來，那你認為規範的寫法給他們列出來，這樣才能推動雙方的磨合，切勿一味抱怨，出了問題不只是後端的問題，你只是抱怨但是沒有去推動解決問題也是有責任的。

看到大家吊打後端，我來歪個樓。

首先，對於題主描述的 PHPer 吊打無疑，但並不是所有介面都可以隨心所欲按照前端的要求來做，目前主要遇到幾類介面：

1. 代理其他系統介面過來的（沒法改底層，要轉換需要自己轉）。

2. 帶有歷史負債並且比較底層各個業務方都有依賴的介面（沒法改源頭，只能新開介面）。

面對以上兩類介面，前端轉還是後端轉就需要整體考慮下：

1. 開發成本。前端 JS 對於數據轉換有一些天然優勢，特別是對 JSON 的處理，成本小。後端 Java 等很明顯成本要高的多。如果時間緊急，還是要前端填坑。

2. 穩定性和可維護性。對底層業務代碼的修改，代碼爛的話，可能會對穩定性產生影響。可維護性一般是比較容易扯皮的地方，按照前端要求輸出，後端可能要多做一些事情，按照後端輸出前端就要多做一些事情。因為開發的思路和習慣真的有差異（前端：我不管業務邏輯，數組給我循環、循環、循環。後端：我不管你怎麼用，直接把資料庫原始模型存進去的數據給你撈出來不就好了。）這也是為什麼好的架構師是前後端都會的原因，只有前後端都開發過比較熟悉，才能結合兩個領域的開發習慣和思路，設計出開發效率更高的系統架構（按照數組存儲，模型、數據貼合 UI 但保留業務擴展性）。

===

對於樓主這個問題，我一般都是提前溝通下，後端新做介面的話，我提前出一套結構和約定，後端用老介面，我會讓他先拉一份 Mock 數據看一下，然後進行一些調整，沒問題了發郵件出來。到了後期聯調的時候，如果是後端結構不符合欄位、結構等要求，除非是底層硬傷實在無能為力之外，不管修改他成本大小（雖然我只是改個名字）一律按照最初約定的郵件來改。

本來介面就應該是前後端交流共同確定的

後端不願交流的話，那就讓後端寫文檔明確說明每個欄位的含義，取值範圍，數據結構

然後前端你也不要管性能優化了，把功能做出來多請求幾次也不管，等到用戶量大的時候，後端崩了，就是他該哭的時候了

這種時候我一般是自己寫後端了，效率還更高點。。。

不過公司能養一個後端能力趕不上一個前端的，我會更迫切地想著怎麼跳槽。

到了後期才溝通返回格式，我覺得是流程問題。先定義，再開發。把所有介面整理出需求、規範並形成文檔，然後可以各自開發，只要最終結果都遵守約定，剩下的無非就是細節溝通。

這問題我們也遇到過，而且遇到的還更慘，除了題主的問題，還有TXT格式、XML格式，啥都有，此外，還是跨部門合作。

如果是本部門內的，相對還好解決，忍無可忍時就把問題升級。跨部門就扯皮拉筋得多，最後也是兩種結果：

1. 能忍的就用繞來繞去的臨時方案替代解決；

2. 不能忍的就是兩手一攤明確告知對方不行，你得改！

總之，臨時方案是相對脆弱和混亂的，後續需求、介面稍加變化都可能出錯，等出錯了看看對方改不改、這個責任誰來背，反正出來混總是要還的，除非他離職否則他也得深陷其中。

再說說介面雙方的主體問題，一般而言，前端是業務數據入口及出口，請求響應的格式（介面）都應以前端考量點為主導，所以介面的制定上，要麼由架構師角色從使用者角度設計，要麼由前端為主設計，此時後端為輔。

所以，有時候像老時代一樣也挺好的，就是按業務功能縱向分工，一人領走幾個功能模塊，前後端自己從頭擼到到尾，雖然模塊間、功能間也有橫向交互，但扯皮已經少很多了……

此外，這後台開發算不算是有辱PHP啊？（逃

誰規定數據介面只能後端定的？

題主你應該找他好好談談，強勢要求你來制定介面規範，你把mock的格式丟給他，讓他按照你的定義給你返回數據。

工作，講的就是配合，要麼你配合他要麼他配合你，雖然無論他返回什麼你都能提取出來，但是不合規範的東西以後別人看這代碼也是懵逼。

就事論事,就算是 [{"god":1},{"dog":2}] 也一樣能遍歷,以jQuery的each函數為例:

PHP: foreach(["god" =&> 1, "dog" =&> 2] as $k =&> $v) { echo $k . " =&> " . $v . " "; }


jQuery:

$.each([{"god":1},{"dog":2}], function(k, v){

	$.each(v, function(k, v){

		console.log(k + " =&> " + v);

	});

});
輸出:

god =&> 1

dog =&> 2
PHP:

foreach([["name" =&> "god", "id" =&> 1], ["name" =&> "dog", "id" =&> 2]] as $v) {

	echo $v["name"] . " =&> " . $v["id"] . "

";

}
jQuery:

$.each([{"name":"god","id":1},{"name":"dog","id":2}], function(k, v){

	console.log(v.name + " =&> " + v.id);

});

輸出: god =&> 1 dog =&> 2

你獲得了一個鍛煉遊說能力的好機會。

去遊說你的領導，或者領導的領導，讓他相信目前的狀況極大限制了開發效率，已經成了公司業務發展的瓶頸（不要只談技術），並且拋出一個完整解決方案，拍胸脯說把這件事交給你，一定出成果。

要讓你的方案落地，領導只是一方面，後端買你的帳也是必須的。所以，拋出方案之前，去遊說後端，讓他相信你的方案能減少他的工作量，壓縮聯調時間（很多時候加班不是因為自己有活，而是為了配合聯調），並且不需要他做什麼改變（至少初期是這樣）。

這事兒成了，你就可以開專欄，吹什麼「企業級web應用介面設計與開發流程」了。

如果不成呢？不成也可以吹啊。

幾個月前去一個小團隊工作了一段時間，只有一個後端也是寫php的，就過去考我各種問題，我倆就總是交流不通，完全不明白對方在說什麼，我就納悶了到底是誰的問題。

後來問的我的問題感覺有點弱智，他說要看看我寫過的東西，重點來了，我打開了github,他當時就來了一句，別說了，我根本不信這個網站是你寫的

我說你沒聽過github嗎？

還有問我varchar和char的區別，我都答出來了，他說你這不對，讓我百度，我就問他答案，他就說我讓你百度呢，你問我？

還有一個問題是，我說我喜歡用linux寫代碼了，能不能安裝linux,他來了一句，linux還能寫代碼呢？

第二天我就沒來了。

以前就聽說啥也不會的培訓一段時間就直接工作了，我覺得就是這個人的水平？但是也覺得不對啊，至少應該聽過github吧，我一直想不通這人到底是啥水平？

我覺得你這個情況協商個屁啊，返回的數據至少得用規範的格式吧，更何況不是自己寫全部代碼，是和別人一同開發，這種情況去自定義數據格式，還有什麼說的？

你們可能需要一個mock server來約定和管理數據格式，也方便你調試介面

要麼他滾，要麼你走

打死他狗日的

這特么就是個文檔的問題啊，你們廠子的流程式控制制有問題，前後端開發人員沒有約定文檔的習慣，感覺要出問題了，開始甩鍋大法，就這麼個事兒。

這也能歸到PHP的話題[黑人問號.jpg]

如果項目leader不對命名規範進行規定的話，那變數名只要是一個符合「約定」的標識符而已，怎麼命名都沒關係，只要介面文檔上面能對應起來就可以了。

但是，一般為了降低公司技術團隊溝通成本，增強代碼的可讀性，一般會對變數命名規則做一些限制和約定。

而且，介面文檔一般都是前後端一起約定的，針對介面文檔，前端要做驗收，如果驗證不通過的話，可以要求服務端修改。如果，實在講不同的話，找老大。

開發流程不科學，沒有文檔。首先產品定義好需求，然後設計設計出原型圖，然後前端寫靜態頁面，需要調用別人的介面的，要讓別人寫好介面文檔，接著自己開寫，這樣才不會扯皮！

發現少帶個id欄位就讓他帶上，沒什麼好糾結的，缺胳膊少腿到底少了哪些，列出來跟他說一下，說完把事情幹完就成，長期相處，大家都耐心一點。

先問他你們之前是不是這樣的工作，要不坐下來聊一下。分離就要配合嘛。

如果瞎幾把來還拒絕溝通的，直接上去揍他一頓然後跑路就行了

聽起來你可能上了個假班…