到底是前端根據後端來寫還是後端根據前端來寫呢？

12-31

我知道現在一般都是前後端分離啥的，後台傳遞數據過來，前端js直接調用就行了，但是會不會出現這種情況，比如一個列表你前端如果是固定了的，裡面有一列是要調用後台數據獲取用戶名，如果這個用戶名當時設置的很長或者別的什麼，會不會在前端造成界面顯示問題，文字超出或者顯示不全啥的？所以到底是前端根據後端來寫頁面呢，還是後端根據前端來寫業務邏輯和數據呢

謝邀。

定好前後端 API 文檔，根據文檔來寫。

前後端之間傳的是數據（Model），後端並不用關心前端顯示的問題。

假裝謝邀~

看題主經歷應該只做過測試，沒有接觸到前端開發和其他工種的協同。

題主所想的流程大概是：

但是實際上的流程大概是：

其實前後端基於原型圖（或者產品文檔）確定介面，同時設計師按照原型圖進行設計，之後後端基於介面文檔開發數據介面，前端基於設計稿和介面文檔做出頁面。

題主提到的文字太長，或者列表沒有信息的時候，或者用戶沒有頭像之類的情況，首先應該在產品文檔中提到，是不是需要特殊處理，比如用戶名不能過長，每個用戶需要默認頭像。

如果產品忘記做了，那麼這個問題一般會在測試的時候作為BUG打回來。這時候產品經理提出新的需求和排期，安排設計來做新的樣式，再由前端實現。

根據文檔來寫

前後端先統一方案，統一定下API和文檔，同步進行，兩個互相只有數據的交流，數據也是在開發之前定好的。

分享一點自己的實踐經驗。

我一般和後端協作按照需求文檔來定API，API盡量做到語義化，可以參考RESTful風格，但倒也不必完全遵循，這個度可以自己去摸索。

前端不需要根據後端來寫頁面，後端也不用根據前端來寫業務邏輯和數據，大家應該按照需求文檔來定API，儘可能的做到API的復用，避免客戶端還要再維護一套API。如果遇到一些edge cases，可以大家協商好找出一個大家都能接受又能方便開發和維護的方案。

那麼在遇到像題主所說的這樣的問題，其實可以理解為API的安全驗證了。一般在有用戶輸入的地方都會有限制（例如長度），可以明確的告訴用戶限制是多少（限制長度多少字），並在前後端都做一次驗證來保證可靠（超出部分截斷）。很多場景下一個稍有經驗的用戶藉助瀏覽器調試工具稍加修改頁面就可以繞過驗證，所以這其中後端的驗證和異常處理尤為重要。

至於API的測試，定好了之後大家各寫各的，各測各的，保證自己沒有問題，都開發完就可以對接調試了。

一個人把前後端一塊寫了。

根據需求來寫，前後端平行

Consumer Driving...

前後端是並行的並不是誰根據誰而是根據需求需求為王

後端負責根據請求給你數據前端拿到數據並處理數據展示出來

嫌太短？？？好不嫌啰嗦看下面。。。

先說下一個需求下來人員咋協調吧（僅限於前端＋後端分別配置全棧的就自己折騰去吧）

例如說產品說我們要新增個列表頁把原型圖給設計前後端都看了需求講清楚了比如我們拿到了設計圖前後端就開始並行開發了（其實沒拿到設計圖也可以開始大框啊什麼的而且後端不怎麼受設計影響）拿最關鍵的列表為例前端：寫列表的樣式啊可以先把數據寫死樣式大差不差了這時候後端的介面也寫好了發送請求調用介面拿到了一個對象裡面有很多東西例如說有個name屬性值是』五月天上海演唱會』，到這時候前後端就算成功聯繫上了數據也能拿到前端：好我能取到name的值了好開心『額這名字有點長我這行展示不了啊』那這時候你能告訴後端說『名字太長了你最多給我多少字元的name值么』，』當！然！不！能！』後端搭好了資料庫封裝好了寫好了介面你直接調用就好了人家的工作已經完成了你拿到了數據怎麼展示是你和設計的事兒！！！太長那就跟設計商量說這名字可能有很長了你要怎麼顯示啊處理數據就是你的事兒了

後端只管數據，前端負責如何展示。

兩者的職責必須清晰。

推薦後端先寫API文檔，然後前端再過一遍之後再開發。

同時前後端必須有針對API文檔的自動化契約測試保證質量。

可以根據後台定的API來寫、前提是後台定了API。

數據結構肯定要在動工之前，根據雙方約定，寫成API文檔，盡量選擇通用，高效的結構，要是像題主描述的這樣，等開始寫了你找我，我找你，那效率何必前後分離。

就算萬一需求有變，通常也是由前端來改，因為首先後端的API介面，可能web前端，ios，安卓都在用，後端一變，大家都要跟著變，再者js執行性能通常都不是制約前端性能的主要因素，而後端性能通常更為重要，一些數據前端多處理下，並不會有什麼問題，當然這也是要雙方權衡協調的，可能後端改一行代碼，前端可以少N個地方的調整。

像題主這種情況肯定是前端來解決，文字過多，只要不是涉及到隱私需要後端來截斷。用css來調整或者用js來截取字元都是很簡單的事，連這種事情都不做，那還要前端幹嘛。

我在不少知名外企和上市公司呆過，開發的時候就沒見過需求以外的文檔，一些要求多的企業，文檔也都是後補的。

通常來講，如果前後端分離開發的話，先定義一個雙方可識別的通用結構，如json、xml等，然後根據需求定製雙方通信的數據結構，這塊前後端誰來定義都可以，通常經驗豐富的人來負責。

定義完結構後，雙方就可以獨立開發了，通常也可以獨立測試數據，等雙方開發差不多的時候，開始聯調。

而樓主說的字數過長、顯示不全等問題，不是程序的事，這塊需要問產品。

嚴格來說，在產品開發的過程中，程序不需要對產品的體驗有想法或者提議，程序的任務是實現產品的功能，設計不合理或者出現衝突的地方，找產品確定（一般或多或少都會有一些）。

我是寫後台的，我覺得應該以後台介面為標準。

為什麼？

1.前端有安卓，web，ios，微信。如果前端來定義標準，4套標準完全不可能的。

2.後台理解需求根據原型圖可以明確的知道頁面上需要什麼數據，然後響應對應的欄位。

而寫介面也就有了介面文檔，我們公司用的這個。

小幺雞，簡單好用的介面文檔管理工具

作為一個前端實習僧，我現在拿到視覺稿的第一件事就是找後端確認數據範圍，找PM和UI問邊界情況如何處理。一定要第一時間問，因為他們可能會討論很久……

前端少年負責把數據合理的展示，不好看的地方找交互視覺少年合計個辦法，後端大爺才不管這個呢