標籤：

前端開發與後台開發如何協作？

12-22

如何減少空檔期。團隊不在同一層樓。

首先， @learnshare給出的兩種開發模式基本上就是我們所有的選擇了，後端提供api，完全前端渲染的開發模式如果可行的話，angular或者react都是不錯的選擇。但如果網站業務決定了必須seo友好而必須進行服務端渲染的話，如同@learnshare所述，現有的開發模式下，前端和後端人員的協作是很困難的。下面我來談談我對這個困境的看法以及我們正在實踐的一個非常棒的模型（最近我在好幾個問題下面都回答了類似的內容，會不會被當成spam。。。）。

首先，服務端渲染的前後端分離之所以困難，根本的原因不在於模板技術的複雜性上，而在於MVC模式本身是有問題的。本質上講，MVC是面向業務過程的，對於企業應用開發，MVC模式的確是無上利器，可以清晰的分離業務邏輯層次，讓程序員將精力集中在業務邏輯的整合上（其實，我覺得即使對於這一點，傳統的MVC模式也沒有做得足夠好，這裡重點不討論MVC，就不展開了，有興趣的可以看看這個：Asta4D Framework User Guide，算是我對傳統MVC模式的一些思考），但是，MVC模式本身的重點在於M和C，而V只是一個附屬品，一個用來展現業務流程的可視化界面而已，因此，通常對前端工作的要求是很低的，能夠展示數據，能夠將業務流程向前推進，這就足夠了。

回過頭來，對於重點是展示內容並幫助用戶獲得有效信息為主的互聯網網站來說，MVC本身就是不合時宜的，常見的例子就是，比如淘寶的首頁，model是什麼？再進一步的，淘寶的寶貝頁面，也許可以把當前寶貝作為model，問題是，邊欄之類的周邊信息怎麼整合到這個model中去？當然，不是做不到，但就此帶來的複雜性，實際上已經宣告了MVC的軟弱。

我上知乎的時間不太長，很奇怪在知乎沒有看到過任何討論view first模式的帖子，這個模式是由lift(Lift :: Home)最先提出並實踐的，可以說，view first模式從根本上解決了內容展示型的網站的MVC困境，可以極大的提高開發效率。

（說到這裡，還沒有說到前後端如何分離。。。我都有點著急了。。。）

view first的基本理念來說，就是視圖，view，才是整個系統的第一優先對象，所有的代碼結構，所有的邏輯，都要圍繞view來展開，傳統的MVC模型，一個url，要先映射到一個controller，然後controller構建model，最後導向一個view，但在view first下，一個url，就對應一個view，服務端接受到request，view就開始渲染了，在渲染過程中，不斷的取得需要的數據，並完成整個頁面，這個過程中不需要controller來控制，也就更不需要model來溝通controller和view，一切都是以視圖為基礎進行的。說到這裡，其實很多人應該已經明白過來了，這不就是傳統的PHP開發模式嘛，先寫html，然後把php的動態代碼嵌進去，OK，搞定啦，是快呀，可這代碼沒法維護呀，前後端也沒法分離呀。。。別急，快了。。。

可以說，view first這個模型，其實就是傳統的php開發模式，lift的貢獻在於，首先明確並命名了這樣一個開發模式，從理論上解決了開發效率的問題並且將開發人員從MVC的迷思中解放出來，然後，lift更重要的貢獻是，從實踐上解決了view first模式下代碼不可維護與前後端分離的問題，提供了一個前後端完全分離的模板模型。這裡多說兩句，lift本身是基於scala的，我們公司在用了兩年lift之後鑒於對scala的種種不爽，決定還是退回到java上，雖然lift本身也支持用java進行開發，但我們覺得一個pure java的方案會更舒服，而且lift本身也有一些細節我們覺得是有改進必要的，因此我們開發了自己的框架Asta4D（astamuse/asta4d · GitHub），雖然我們提供了很多不同於lift的功能，但單就view first和前後端分離的模板來說，基本上是一個95%拷貝加5%改良的lift，下面我就用我們自己的框架來舉例，相信java代碼大家看起來也會更舒服一點。

首先，無論是lift，還是我們的山寨Asta4D，前端工程師面對的都是pure html的模板，如下：

& &
&
&

name:&dummy name&& &

age:&0&& & &

前端工程師可以自由的填入stub數據來調試他們想要的效果或者交互邏輯，在他們完成工作後，這個模板交給後端工程師的時候，後端工程師會在模板中嵌入一點代碼：

& &
&

name:&dummy name&& &

age:&0&& & &

好吧，這個時候想像一下，前端工程師發現了一點bug需要進一步修正，我們可以相信的一點是，在99%的情況下，後端工程師加入的那一行「afd:render」的代碼應該不會給前端工程師造成干擾，因此，這個時候，我們的前端和後端就已經可以開始同時工作了，先把前端的工作放在一邊，看看後端怎麼填入真實數據：

public Renderer showProfile() {
Renderer render = Renderer.create();
render.add("p#name span", "asta4d");
render.add("p#age span", 20);
return render;
}

後端用css selector來標定數據錨點並將真實數據填入，因此，在最簡單的情況下，只要數據錨點不變，無論前端工程師如何重構模板代碼，都不再需要後端工程師的介入了。當然，這裡有一個顯而易見的問題，前端工程的重構並不能保證數據錨點不變，因此，我們在實踐中，引入了一個所謂的「X約定」，簡單的講，我們的後端工程師會在模板中再多加一點東西：

& &
&
&

name:&dummy name&& &

age:&0&& & &

大家可以注意到，後端工程師在數據錨點上加入了以x開頭的偽類，這樣，後端的渲染代碼就變成下面這個樣子：

public Renderer showProfile() {
Renderer render = Renderer.create();
render.add(".x-name", "asta4d");
render.add(".x-age", 20);
return render;
}

仍然是用css selector，只不過不再用tag而是用class來錨定數據，我們可以看到，class中加入的「x-」一方面不會對前端工程師的工作造成任何干擾，另一方面也起到hint的作用，前端工程師只要能夠將「x-」標記的數據錨點保持不變就可以放心大膽的重構代碼而不需要後端工程師的介入。

在我們的實踐中，一般的開發流程是前端先完成頁面，然後後端接手填入數據，這個中間通常不會進行交流，因為我們的前端和後端甚至是分開在兩個部門的，大家的交互就是redmine的ticket的轉交而已。當然，在某些時候，後端工程師無法理解前端的模板不知道應該將數據填在哪兒的時候，還是會有必要的交流，但這種交流真的很少發生，至少不需要他們非得坐在一起工作：）

更進一步的，某些時間很緊的開發任務，前後端甚至是同時開始工作的，後端會開一個debug頁面，在裡面只用div和x-來標記數據錨點並完成後端的渲染邏輯，而同時前端會完成正式的html頁面代碼，最後，由後端將渲染邏輯合併到正式頁面即可。當然，這種情況下，前後端的交流會多一些，我們的前端mm擺脫後端猥瑣大叔們糾纏的辦法就是儘可能快的先完成基本的html骨架push上去，然後告訴他們，你們自己玩去吧，別來煩我了^_^

更為具體的一個我們的實踐的例子是，一個耗費前端兩個人月的頁面大規模重新設計和重構，在前端完成工作後30分鐘，我們的後端就完成了所有必要的修改並將代碼合併到主幹準備進入release流程了。嗯，因為我們能做到這個，所以我們的前端和後端就一直是兩個部門沒人提合併的事情。

最後，題外話，最近react.js突然吸引了很多人的目光，對於客戶端渲染真的是非常不錯的東西，而我們的框架Asta4D，同樣的提供了服務端渲染下的虛擬DOM組件模型。哦，這裡就不贅述了，有興趣的可以自己去看我們的user guide。

大家看幾個我們的頁面吧

Detailed information of toushiba corp.

Publication number 225663） a nonvolatile memory device

Technology and business trends of Glass melting and manufacturing

我們的網站其實是日文的，這個英文網站是做給華爾街的大爺們看的一個簡裝版，相對內容要簡單些，但大家仍然可以看到，我們在前後端完全分離的模式下可以做得很漂亮。


============感謝 @賀師俊的評論，評論回復裡面沒法回答太多，我把回復貼到這裡=====

賀師俊
你的 showProfile 其實就是變相的 model，x-name 和 x-age 就是 model 的屬性。

這取決於你如何定義model。

從簡單的ORMAP的角度來說，我們必然有一個entity，對我們的這個架構來說，這個entity是一定存在的，從這個角度上說，這裡的確有一個model，就是ormap中的entity。

但是從MVC模式的model來說，MVC的model並不是簡單的entity，而是一個包含了所有前端必須數據的container，從這個意義上講，我們沒有model。

最後，我上面的回答跟你指出的事實，其實有點不搭界，你的意思是，render的方法本身就是一個邏輯上的model，而x-就是model的屬性，老實說，這個觀點真的很有趣。

你指出的事實讓我陷入了長考，這裡究竟有沒有model，從邏輯上講，你是對的，我思考了很長時間，這種邏輯上的model跟MVC的model的區別是什麼？

我的理解是，首先，我們不需要在代碼中構建一個大雜燴的數據容器，而是在一個極小的範圍類定義了一個局部適用的小數據結構，從這一點說，跟傳統MVC比起來，我們做到了更細粒度的解耦。其次，從實現的角度講，我們鼓勵開發人員儘可能簡單的取得數據，我們近乎變態的儘可能的執行以一行為單位的無join查詢（性能依靠緩存保證， http://astamuse.github.io/asta4d/userguide/index.html#perform-queries-simple），這絕對比傳統的MVC模式的開發效率和可維護性都高得多。進一步的，我在原文中已經強調過了，這裡的「x-」約定，只是一個hint，對前端沒有任何強制的約束能力，前端不會因為破壞了這個約定而導致頁面崩潰出錯，反過來，前端在有必要的時候可以完全無視這個約定，數據的整合是由後端完成的，但頁面的邏輯，是前端主導的，開玩笑的說，「x-」約定是我們後端人員對前端大爺的哀求：「大爺啊，不要亂搞我好嗎。。。」。

所以，我們對前後端分離的開發模式的理解是，最重要的一點是，前端具有主導權，由前端決定開發的走向而不是後端，後端的職責是滿足並提供前端需要的數據，反過來，前端沒有義務和必要為了後端的各種技術上的理由而去學習或者說導入各種跟前端無關的技術（有任何前端開發人員會喜歡velocity之流的模板的嗎？），前端需要最大限度的自由度去完成創造性的工作，後端的職責是配合他們。進一步的，後端的技術意義在於，以更合理的後台架構，更方便，快捷的提供前端需要的數據，在這個層次上，我們需要緩存的設計，需要合理的api設計，需要後台存儲架構的各種變化，但是，在最終向前端提供數據這一個邏輯層次上，後端可以比前端開發人員寫出更有效率的利用現有API取得必要數據的邏輯，但後端不可能比前端知道如何更有效率的將數據展現給用戶，因此，我們對view這一層的分工的理解就是，前端負責數據如何展現，後端負責取得數據並提供給前端。

最後，無論那種模式，最終總有一個標記數據位置的參數，或者是MVC中model的屬性，或者是我們這裡的css selector hint，或者是一個嵌入的變數名，從這個意義上講， 任何模式都有個model，都有個屬性，所以，即便我很同意你說的邏輯上showProfile就是個model，但我仍然認為，我們從本質上是anti-MVC的。

首先建議要前後端分離開來做，這樣在後期維護更新的時候能節約很多時間，很多框架思想或者組件什麼的都是基於分離思想上提出來的。

然後考慮具體採用哪種分離方式，目前比較流行的有兩種，一種是傳統MVC模式，一種是純介面類似於SPA模式。

其實MVC雖然做到了view層的部分分離，也就是前端負責模板，後端填充模板的方式雖然做到了工作上的分離，但實際上前端和後端的代碼還是交織在一起的，同時整個頁面模板的控制權在後端手裡，這樣有時候也容易暴露出弊端：

  1. BUG誰負責？MVC模式的站點運營一段時間後出現BUG，想要分清楚是業務邏輯上的問題還是前端模板的問題並不是那麼簡單的，有時候還需要反覆的進行定位，如果經驗不豐富常常要在BUG的定位上浪費很多時間。
  2. 維護成本。如果頁面加以改動和BUG修復，前端修改頁面時必須要建立後端的環境，除非你把HTML抽出來改，當然很少有人會做這種吃力不討好的事。同時這些改動是前後端一起進行的，有時候可能還會返工到前端再改，在反覆的維護中也帶來了一定的溝通成本。
  3. 頁面邏輯體現不完美。只要接觸過前端或者後端的人都能很清楚的意識到整個頁面的邏輯或者是方向大多數時候是掌握在前端手裡的，當一個頁面足夠複雜時後端要理解前端的頁面設計邏輯和控制頁面是非常浪費時間的一件事。而前端拿不到頁面控制權也很容易使頁面邏輯脫離自己的方向。
  4. 開發力度不均等。前端如果只是切圖+效果就完成工作，剩下的一切交給後端，會讓整個項目的後端工作繁重。

在這些問題的基礎上，有人開始使用類似於SPA模式的純介面開發模式，簡單的說就是後端只提供介面，具體的頁面實現和邏輯都交給前端，相比之下這解決了不少MVC模式帶來的問題：

  1. 均衡開發力度。前端掌握view層的控制權之後工作當然也會更多一點，後端則可以更加專註業務邏輯工作，整體平衡了項目的前後端工作重量。
  2. 易於管理和維護。相比之下代碼的清晰度，邏輯的清晰度更高，不管是後期維護還是更新都有不少的幫助。

當然啦，雖然看起來很美，但是SPA模式很難解決SEO問題，通過介面拿來的數據必然是填寫在空白的html模板中的，而蜘蛛訪問時不會考慮js，在蜘蛛頻繁的抓取的空頁面時會認為這是一個垃圾頁面，從而影響網站PR等評分。當然你也可以識別蜘蛛來引導一個假頁面欺騙，但是實際效果很差而且浪費工作量。
除此之外SPA模式前端傳值的安全性也是備受考驗的一點。

後來淘寶UED提出了一個nodejs的中間層辦法，但是搜索一下會發現實際真的這樣做的人並不多，可能是部署相對複雜而且可供參考的資料較少，還不夠成熟。原理是提供一個nodejs中間層來獲得前端控制器的權利，也就是前端更方便的操作路由，當然最重要的是渲染模式多變，解決SEO問題的同時還保證了頁面的即時交互性。

除此之外也有一些MVVM的做法，和SPA模式最大的區別在於vm不操控html代碼，只對值進行修改。

我的經驗是如果傳統的PC頁面還是建議用MVC模式來搞定最好，如果涉及移動端或者複雜且高度的交互時，可以考慮純介面模式，如果公司希望能夠探索更多的方式則可以試試新方法。
其實這些模式並沒有說哪種最好，只是提供了一個目前WEB開發模式的解決方案，以後隨著技術的成熟肯定會有越來越多的開發方式引進，前後端的協作也會變得更直白一些。

前端通常作為模板，後端負責數據。

前後端合作的主要目的，就是把後端產生的數據丟到前端的模板中。通常這一步有兩種方式：
1. 前端的模板交給後端處理，直接寫到後端邏輯中，或者通過 MVC 框架整合成後端的相對獨立的部分；
2. 後端的數據通過 API 的方式交給前端處理，通過 Ajax 等方式傳輸數據。
（當然，也有兩種方式混合處理的）

如果採用了後端處理模板的方式，那前端開發完靜態模板後，需要交給後端開發人員進行模板的整合。這一步要求前端代碼整潔易讀，而且後端必須熟悉各種前端知識和調試技術。最後需要前端對後端處理過的頁面進行檢驗和調試。（這種方式對溝通要求很高，如果兩個人不坐在一起，那合作起來非常麻煩。出現問題或者需要升級時，往往很難定位誰的錯，誰去改。所以最好兩個人坐在一起開發，甚至一個人負責前後端）
如果採用前端處理數據，Ajax 等方式通信的話，前後端只要商量好所需的 API，然後持續交付一個個 API 就好了。前後端完全不需要了解，技術沒有限制，也不需要知道彼此的代碼和實現。

兩種方式如何選擇？
1. 如果前端頁面主要做內容展示，需要後端處理的內容比較多，而前端邏輯簡單時，建議採用後端 MVC。如博客、新聞類的網站；
2. 如果前端頁面的交互和數據處理較多，可以將邏輯放在前端，而後端只負責數據存取。比如各類管理後台。

----------正式開始答題----------
首先，需要問題主目前採用了上面的哪種方式。然後朋友們再幫你分析一下。

提升前後端協作效率的方法無非以下三種方法：

1. 明確約定界限，前後端分離。Restful api、單頁應用、nodejs 前後端分離都是可行的方案。
2. 開發前端框架，減少上手難度（就像 bootstrap），讓開發人員直接寫前端，你就做框架和組件。
3. 你去學開發的東西，把一部分基礎的東西直接搞定。

反對最高票 @小豬 的回答
首先，就MVC的理解與 @小豬 存在分歧

MVC本身就是不合時宜的，常見的例子就是，比如淘寶的首頁，model是什麼？再進一步的，淘寶的寶貝頁面，也許可以把當前寶貝作為model，問題是，邊欄之類的周邊信息怎麼整合到這個model中去

傳統MVC中的Model實際上是一個非常大的概念，Java項目中常見的Service, DAO都屬於Model層。以最為傳統的MVC為例，邊欄信息應該是由Action調用不同Service（例如UserInfoService，FavorateService）組合併返回的。
而 @小豬 說的Model是單純指代的視圖層模型，就展現豐富的頁面而言，視圖層模型沒有明確的可復用的「關注點」，對象拼裝在Action（屬於MVC中的C）中進行，沒Model什麼事兒。

當然討論MVC有點跑題，回到前後端配合上， @小豬 提到的約定公共鉤子，後端套模板的方案，我認為仍然有不能解決或 @小豬 沒有回答到的問題：

  1. 後端工程師在嵌模板時需要閱讀並修改前端代碼，修改後需要再回過頭來雙方共同驗證。後端依然無法專註於業務
  2. 非同步更新怎麼處理。以你例中的showProfile渲染部分為例，如果該部分需要非同步更新，要怎麼處理？提供一個訪問Profile資源的Ajax API，然後前端保存一份JS模板去局部渲染？那麼同一處UI就有前後兩套不同語法的模板，每次修改都要同步。對於後端還有提供介面的成本，今天需要A資源的Ajax API，明天又需要B資源的，其實真正的業務邏輯可能完全沒變，卻天天被展現層牽著鼻子走寫新API，似乎多少有點浪費效率。

對於無SEO需求的項目目前看法比較一致：RESTFUL + 瀏覽器端渲染。
而對於有SEO需求的項目，確實辦法不多，鉤子約定法可以在很大程度上減輕模板這一臟地帶的維護風險，但個人認為治本的趨勢依然是前後端同構，前端必須跨過瀏覽器這道物理屏障，完全接管視圖層。

我們公司PM、UI、前端、後端、QA分別在幾個不同城市，溝通全靠wiki、QQ

實行的敏捷開發流程

跟前後端協作有關的，就是從方案設計、對介面開始

前後端相關人員一起，對照原型，根據模塊及頁面大概定義出介面， 一個頁面中有幾個介面，每個介面入參與出參是什麼，當然大部分是後端定的，少數介面需要跟前端一起溝通

之後在wiki上生成標準的介面文檔，包含以下內容：

  1. 約定：如rest風格，code約定，數據格式等等
  2. 通用欄位：很多介面都會重複使用的約定欄位，例如 1 上架 2下架等等
  3. 根據模塊具體定義每個介面：url、入參、出參，一些特定的約定會寫在備註裡面
  4. 項目比較複雜，涉及到人員比較多的時候，會在每個介面上寫上各端負責人名字

前後端方案評審通過之後，按照優先順序拆好禪道task，之後就開始各自開發了

前端搭建好項目框架，先寫好route、service、ajaxAddress等，記得UI出圖之前千萬不要寫頁面，ctrl中除了數據處理部分，其他能寫的都先寫著

後端搭建好環境之後，第一件事不是直接寫代碼，而是提供好假數據，ctrl裡面不需要寫任何業務邏輯，包括入參校驗，直接在返回的jsp中按照wiki之前約定的格式寫死數據，讓前端先用假數據渲染頁面，之後再慢慢具體寫每個介面的邏輯，一定不要讓前端把能做的事情都做完之後，還坐等後端的假數據，雖然實在到了那種地步，前端自己也可以mock假數據，但是其實這樣的時間消耗是沒有意義的

後端每完成一個介面，自測無誤後，都需要及時部署到dev，並告知前端，前端調試介面出現的問題，除非是特別緊急的情況，需要馬上確認，否則就先登記到wiki，寫清楚誰的問題、具體哪個介面、入參是什麼、實際結果是什麼、期望結果是什麼，按照重要程度排序，並且在群里@一下後端，後端空餘時間會根據wiki上優先順序來一一處理，處理好之後同樣在群里@一聲，複雜問題前後端可約定一個具體的時間，每天集中調試。

每天早晨晨會一起在dev演示昨天完成的內容，相當於miniDemo，明確今日計劃，看看禪道task是不是點了，燃盡圖有沒有問題，有沒有延期風險，發現問題主動提出，溝通解決，解決不了的及時上報

開發完成之後，前後端一起在dev反覆、充分自測，然後codeReview、UI自檢、性能測試，通過之後就demo，demo後發測試，再一起改bug，改完之後發布上線~

然後以為可以放鬆一下，開開心心吃雞的時候，

下一個項目又開始了~

現在遠程協作方便多了啊。
我們公司研發團隊分布在六個城市，每天都是遠程協作，效率還好～肯定沒坐一起舒服，但是還可以。

前後端協作的重點有三個。

第一個是介面文檔。
第二個是假數據和自測。
第三個是持續集成。


介面文檔必須先行，項目中公告約定提前商議好。
假數據全部提供，自測必須完成。
本地必須搭環境，開發環境每日集成。

嗯。哪天單獨在專欄里說。

通過 HTTP 合作，所以要求雙方要對 HTTP 特別熟悉。
比較好的實踐就是 RESTful API 了

好吧，菜鳥答一下吧，我們這沒上面的答案說的那麼規範，那我們是怎麼乾的呢？
很簡單，我一般把html做完之後，我把必要的步驟寫到js的注釋里，後端做java的程序員他們自己去看。如果我覺得注釋還說不清楚，那簡單了，我直接過去找他丫的談論哲學（邏輯）。

前後端分離，簡直不要太爽。
一是前後端開發互相不干涉，進度也互相不影響
二是增加需求的話，後端只需要新增介面，前段改動起來也會比較容易
三是如果後期有做APP的需求，後端基本上完全不需要做任何事情
四是出了問題問責很容易，哪個頁面出了問題，看一下數據對不對，數據對就找前段，數據錯就找後端

首先，前後端分離，在這種模式下，前端和後端開發者解耦複雜的業務邏輯，按照介面約定好的數據各司其職。

目前一般採用RESTful風格定義介面，後台定義介面文檔，按照文檔開始各自的開發任務，直至開發完成。

如何減少空檔期？

1.介面文檔要清晰，減去不必要的溝通成本。

2.前端可以使用mock.js模擬後台返回數據，前後端就可以並行開發，不存在線性等待的問題

項目大了之後，管理API就很重要，API管理平台試用過swagger、postman（其實不太算）、eoLinker之後，最後選擇了eoLinker。

一是有協作管理，後台一更新文檔我就能看到（實時性）

二是後台人員填寫完介面後，我直接使用它生成的mock在線鏈接，不用自己搭建本地伺服器。

根據項目特點，搭建框架（前後端框架）、制定規範，形成默契。
根據需求，拆分功能模塊、制定開發順序
每個功能模塊：

  1. 寫API文檔、模板標籤，預先在API介面上簡單寫模擬值方便前端測試（根據項目和人員不同這部分可能會略去，這樣就得前端自己模擬）
  2. 後端根據功能單獨開發，配合REST Client進行單獨調試
  3. 前端根據API文檔和模擬值進行開發調試
  4. 前後端完成之後正式聯調，修復錯誤BUG

理論上前後端之間是不碰對方代碼的，特別是「模板插程序」是必須由前端來做的，只要這樣才能保證頁面顯示效果準確減少溝通成本降低BUG，所以需要前期良好的API文檔規範和後端給予前端的便利調試環境，比如URL加個參數?debug=true，輸出所有標籤，便於前端開發。

開發過程中，無論大小項目，最重要的一件事就是寫完善的API和相關技術文檔，並且最好能配合code review，例如使用phabractor在arc diff 的時候最好前後端之間也相互抄送通知一下，有時候粗粗掃幾眼，也能發現API定義理解上的差異問題，這也是為什麼招前端工程師需要至少懂一門後端語言這個要求的原因。

後端所提供的介面之數據格式應該和前端有一個約定，要有介面文檔和規範。
前端提供給後端使用的view層模版（html結構）應該也和就算約定，有一套基礎固定的dom結構文檔規範。這是最起碼的。

淘寶這篇前後端協同開發很不錯
前後端分離的思考與實踐（一）

當然是ins omnia啦～
https://insomnia.rest/
可以保存，分享做好的介面，並直接測試，基於rest

前端與後端的界限要分明，後端處理數據，前端負責渲染數據和頁面重構，前端可以用postman等工具與後端互相約定介面和其他命名規則

這個問題，我們團隊一直在實踐。首先我們採用的是前後端分離的模式，然後前後端如何協作呢？試過，API文檔，試過swagger，也自己團隊開發過mock server，也本地試過mock file。最高效的方式：討論介面的時候，後端直接定義controller，模擬返回數據，文檔就是swagger。。之前開發mock server，有點太理想了，因為某些介面很複雜，在mock server中定義 不如就直接寫偽controller。
其實，上面說的最有效的方式還是會有效率的損耗。首先一點，執行得要到位。不然前端的邏輯還是不好寫。

Thymeleaf: java XML/XHTML/HTML5 template engine ，主要是支持 Spring Boot，

不破壞原有的HTML和Javascript代碼，靜態頁中的mock數據和伺服器端生成的東西可以完美地互不影響，設計和開發可以分別進行。

其實我一直也在糾結這個問題，這幾天剛完成了一個項目的開發，只是一個學校的實訓小項目。我們前端完全只用html，然後通過Ajax進行和後端通訊，後端所有數據完全封裝成json數據，傳輸到前段，用js進行數據解析及展示。但是我覺得將所有數據傳輸給前端有前段進行控制顯示，這樣會很不安全。後端將數據封裝，前段又將數據解析，似乎重複了工作！

按照幾年的開發經驗來講，前後端協作需要一個好的工具軟體，前後端協作重要是要溝通！可以不通過語言來溝通，但是必須要有簡潔的備註，不需要語言就能理解明白。工具的話只用過eolinker，不過真的很好用~推薦一下~~

推薦閱讀：

※程序員們分享一下你們寫的情書？
※熱炒的前端什麼時候能冷靜下來？
※若想學 HTML，應從何入手？
※如何幫助前端新人入門和提高？
※前端工程師和 UI 設計師該如何選擇？

TAG:前端開發 | 團隊協作 | 前端工程師 | 網站後台 | 後台開發 |