網頁制作Poluoluo文章簡介：前後端分離的開發模式，原本覺得沒什麼稀奇的玩藝，在最近參與的一個大型項目中，讓我有了更深的理解。
前後端分離的開發模式，原本覺得沒什麼稀奇的玩藝，在最近參與的一個大型項目中，讓我有了更深的理解。
前後端分離的開發模式：系統分析階段，系分和前端開發人員約定好頁面上所需的邏輯變量，進入功能開發階段，前端開發人員進行前台頁面結構，樣式，行為層的代碼編寫，並根據約定好的變量，邏輯規則，完成不同情況展示不同的表現。而後端開發人員，只需要按照約定，賦予這些變量含義，並提供前後端交互所需要的數據即可。
以前自己在php上玩過mvc開發框架，但是沒有在這麼大型的項目中實踐過，所以過程中暴露出一些問題，也說明現實和理想還是存在一定差距的。
對項目中遇見的問題做了如下紀錄：
A.對交互白板的理解不足，如：對ajax實現大批量數據交互的實現，沒有及時給出改進的建議
B.系分階段產出的約定變的非常脆弱，開發過程中不時有新的東西和變更的東西出現，這就導致後面的前後端協作開發有些糾結
C.項目過程中，由於前期與需求方，設計師，系分的溝通力度不夠，導致開發過程中發現很多考慮的不夠周全的地方
D.項目開發過程中前後端開發資源的配比上較為懸殊，在後期頻繁需求變更中，前端一直處於：勉強應付狀態
可見，上面提到的這些，多是溝通和協作上的問題，以下是對這次初體驗的小結，希望對前端開發工程師有所借鑒：
溝通：項目開發之前，盡可能主動的和系統分析師和交互設計師多溝通，確定頁面中交互與服務器端交換數據的接口、方式、格式等，讓前後端約定更豐滿一些。因為她越豐滿，後面的糾結就越少。
A.向前設計，參與到前期的交互設計的討論中去，去理解設計，向後開發，去了解後端開發工程師關心的是什麼，不想要關心的是什麼，擔心的是什麼，學會站在對方的角度上去看問題
B.必須確認交互白板中各類出錯場景以及出錯提示文案是否完整，要求後台開發人員補充交互設計師無法知曉的後端異常出錯的場景，並要求交互設計師給出相應的提示文案
C.明確交互效果中，哪些是需要通過ajax實現的，並與開發人員約定好數據接口，方式，格式等，並確認數據交互失敗的情況下是否有文案提示，如無，主動找交互設計師補充該類場景的文案提示
協作：功能開發過程中，需要建立一個共同調試的環境，方便前後端同學協同開發。
A.有些數據接口api以及數據格式也許會到開發中才能夠確認下來。可以有個接口文檔。如果大家都知道彼此對業務規則都熟悉，可以在開發中逐個確認。無論如何，接口文檔是必須的。它記錄著在系統層面對業務的抽象。接口細節可以在開發中逐漸完善。
B.總有那麼一些文件，是前後端開發人員都會修改的。這些敏感文件，修改前以及修改完畢都要知會後端開發人員。而且要養成edit前update的習慣。如果出現沖突，沖突最好能夠一起解決，或者及時告知。避免再次沖突。
C,項目中前後端資源配比應該適當，1：10的資源配比想推起前後端分離的開發模式還是比較困難的，個人認為1：3是比較適中的配比。
出於前後端資源配比，系統分析階段還不夠詳細等原因，在一些大型的項目中，對分離開發模式進行了一些調整，說實在的有些不得以，但是這應該是目前最符合現狀的前後端分離的開發模式，抱著發展的眼光向前看，前端不斷壯大之後，應該會有讓人滿意的答卷的！
在功能開發階段，由於項目比較大，一般會分解功能，這樣的話就很難提供出一個功能相對穩定的前後端共同調試環境，再加上資源配比太過懸殊，所以建議在功能開發還不穩定這個階段，前端開發資源以協助開發的角色進入，由後端開發人員參照系分階段約定好的數據類型和接口提供數據和嵌套頁面邏輯，當功能開發相對穩定以後，前端開發人員對嵌套後的前台內容進行驗收，此時，前後端開發的DEBUG工作就可以並行操作了。