前後端分離的開發模式：系統分析階段，係分和前端開發人員約定好頁面上所需的邏輯變數，進入功能開發階段，前端開發人員進行前台頁面結構，樣式，行為層的**編寫，並根據約定好的變數，邏輯規則，完成不同情況展示不同的表現。而後端開發人員，只需要按照約定，賦予這些變數含義，並提供前後端互動所需要的資料即可。
以前自己在php上玩過mvc開發框架，但是沒有在這麼大型的專案中實踐過，所以過程中暴露出一些問題，也說明現實和理想還是存在一定差距的。
對專案中遇見的問題做了如下紀錄：
a.對互動白板的理解不足，如：對ajax實現大批量資料互動的實現，沒有及時給出改進的建議
b.系分階段產出的約定變的非常脆弱，開發過程中不時有新的東西和變更的東西出現，這就導致後面的前後端協作開發有些糾結
c.專案過程中，由於前期與需求方，設計師，係分的溝通力度不夠，導致開發過程中發現很多考慮的不夠周全的地方
d.專案開發過程中前後端開發資源的配比上較為懸殊，在後期頻繁需求變更中，前端一直處於：勉強應付狀態
可見，上面提到的這些，多是溝通和協作上的問題，以下是對這次初體驗的小結，希望對前端開發工程師有所借鑑：
溝通：專案開發之前，盡可能主動的和系統分析師和互動設計師多溝通，確定頁面中互動與伺服器端交換資料的介面、方式、格式等，讓前後端約定更豐滿一些。因為她越豐滿，後面的糾結就越少。
a.向前設計，參與到前期的互動設計的討論中去，去理解設計，向後開發，去了解後端開發工程師關心的是什麼，不想要關心的是什麼，擔心的是什麼，學會站在對方的角度上去看問題
b.必須確認互動白板中各類出錯場景以及出錯提示文案是否完整，要求後台開發人員補充互動設計師無法知曉的後端異常出錯的場景，並要求互動設計師給出相應的提示文案
c.明確互動效果中，哪些是需要通過ajax實現的，並與開發人員約定好資料介面，方式，格式等，並確認資料互動失敗的情況下是否有文案提示，如無，主動找互動設計師補充該類場景的文案提示
協作：功能開發過程中，需要建立乙個共同除錯的環境，方便前後端同學協同開發。
a.有些資料介面api以及資料格式也許會到開發中才能夠確認下來。可以有個介面文件。如果大家都知道彼此對業務規則都熟悉，可以在開發中逐個確認。無論如何，介面文件是必須的。它記錄著在系統層面對業務的抽象。介面細節可以在開發中逐漸完善。
b.總有那麼一些檔案，是前後端開發人員都會修改的。這些敏感檔案，修改前以及修改完畢都要知會後端開發人員。而且要養成edit前update的習慣。如果出現衝突，衝突最好能夠一起解決，或者及時告知。避免再次衝突。
c,專案中前後端資源配比應該適當，1：10的資源配比想推起前後端分離的開發模式還是比較困難的，個人認為1：3是比較適中的配比。
出於前後端資源配比，系統分析階段還不夠詳細等原因，在一些大型的專案中，對分離開發模式進行了一些調整，說實在的有些不得以，但是這應該是目前最符合現狀的前後端分離的開發模式，抱著發展的眼光向前看，前端不斷壯大之後，應該會有讓人滿意的答卷的！
在功能開發階段，由於專案比較大，一般會分解功能，這樣的話就很難提供出乙個功能相對穩定的前後端共同除錯環境，再加上資源配比太過懸殊，所以建議在功能開發還不穩定這個階段，前端開發資源以協助開發的角色進入，由後端開發人員參照系分階段約定好的資料型別和介面提供資料和巢狀頁面邏輯，當功能開發相對穩定以後，前端開發人員對巢狀後的前台內容進行驗收，此時，前後端開發的debug工作就可以並行操作了。
前後端分離開發的利與弊
事物總是多面性的，開發也不例外。現在開發流行前後端分離，分離的好處當然很多 1 後端專注業務及邏輯，前端專注於展示和互動，前後端分離的好處就是專業分工和前端展示可以多樣化。耦合度的降低增加了靈活性 2 前後端分離還是比較適合目前的應用方式 saas化 的。但前後端分離也有很多不利的地方 1 增加靈活...
基於RAP Mock 實現前後端分離開發
rigel api platform 在前後端分離的開發模式下，我們通常需要定義乙份介面文件來規範介面的具體資訊。如乙個請求的位址 有幾個引數 引數名稱及型別含義等等。rap首先方便團隊錄入 檢視和管理這些介面文件，並通過分析結構化的文件資料，重複利用並生成自測資料 提供自測控制台等等.大幅度提公升...
前後端分離趨勢談
最近已經不止乙個人和我提起過vue了，在我的前端印象中，我還停留在smarty渲染模版，jquery做js處理。學了一晚上，對現在這種工程化webpack打包生成html，js，css的生產方式越來越有興趣了。工作年限擺在這裡的好處就是經歷了不少技術的變革，能從縱向思考下技術的變革和趨勢的路子。想想...