- 我們的專業(yè)品牌服務(wù)商：網(wǎng)站建設(shè)、品牌策劃設(shè)計、網(wǎng)站優(yōu)化、網(wǎng)站推廣等業(yè)務(wù)
首頁-新聞中心-我們的觀點
前后端分離的開發(fā)模式：系統(tǒng)分析階段，系分和前端開發(fā)人員約定好頁面上所需的邏輯變量，進入功能開發(fā)階段，前端開發(fā)人員進行前臺頁面結(jié)構(gòu)，樣式，行為層的代碼編寫，并根據(jù)約定好的變量，邏輯規(guī)則，完成不同情況展示不同的表現(xiàn)。而后端開發(fā)人員，只需要按照約定，賦予這些變量含義，并提供前后端交互所需要的數(shù)據(jù)即可。
以前自己在php上玩過mvc開發(fā)框架，但是沒有在這么大型的項目中實踐過，所以過程中暴露出一些問題，也說明現(xiàn)實和理想還是存在一定差距的。
對項目中遇見的問題做了如下紀錄：
A.對交互白板的理解不足，如：對ajax實現(xiàn)大批量數(shù)據(jù)交互的實現(xiàn)，沒有及時給出改進的建議
B.系分階段產(chǎn)出的約定變的非常脆弱，開發(fā)過程中不時有新的東西和變更的東西出現(xiàn)，這就導致后面的前后端協(xié)作開發(fā)有些糾結(jié)
C.項目過程中，由于前期與需求方，設(shè)計師，系分的溝通力度不夠，導致開發(fā)過程中發(fā)現(xiàn)很多考慮的不夠周全的地方
D.項目開發(fā)過程中前后端開發(fā)資源的配比上較為懸殊，在后期頻繁需求變更中，前端一直處于：勉強應(yīng)付狀態(tài)
可見，上面提到的這些，多是溝通和協(xié)作上的問題，以下是對這次初體驗的小結(jié)，希望對前端開發(fā)工程師有所借鑒：
溝通：項目開發(fā)之前，盡可能主動的和系統(tǒng)分析師和交互設(shè)計師多溝通，確定頁面中交互與服務(wù)器端交換數(shù)據(jù)的接口、方式、格式等，讓前后端約定更豐滿一些。因為她越豐滿，后面的糾結(jié)就越少。
A.向前設(shè)計，參與到前期的交互設(shè)計的討論中去，去理解設(shè)計，向后開發(fā)，去了解后端開發(fā)工程師關(guān)心的是什么，不想要關(guān)心的是什么，擔心的是什么，學會站在對方的角度上去看問題
B.必須確認交互白板中各類出錯場景以及出錯提示文案是否完整，要求后臺開發(fā)人員補充交互設(shè)計師無法知曉的后端異常出錯的場景，并要求交互設(shè)計師給出相應(yīng)的提示文案
C.明確交互效果中，哪些是需要通過ajax實現(xiàn)的，并與開發(fā)人員約定好數(shù)據(jù)接口，方式，格式等，并確認數(shù)據(jù)交互失敗的情況下是否有文案提示，如無，主動找交互設(shè)計師補充該類場景的文案提示
協(xié)作：功能開發(fā)過程中，需要建立一個共同調(diào)試的環(huán)境，方便前后端同學協(xié)同開發(fā)。
A.有些數(shù)據(jù)接口api以及數(shù)據(jù)格式也許會到開發(fā)中才能夠確認下來?？梢杂袀€接口文檔。如果大家都知道彼此對業(yè)務(wù)規(guī)則都熟悉，可以在開發(fā)中逐個確認。無論如何，接口文檔是必須的。它記錄著在系統(tǒng)層面對業(yè)務(wù)的抽象。接口細節(jié)可以在開發(fā)中逐漸完善。
B.總有那么一些文件，是前后端開發(fā)人員都會修改的。這些敏感文件，修改前以及修改完畢都要知會后端開發(fā)人員。而且要養(yǎng)成edit前update的習慣。如果出現(xiàn)沖突，沖突最好能夠一起解決，或者及時告知。避免再次沖突。
C,項目中前后端資源配比應(yīng)該適當，1：10的資源配比想推起前后端分離的開發(fā)模式還是比較困難的，個人認為1：3是比較適中的配比。
出于前后端資源配比，系統(tǒng)分析階段還不夠詳細等原因，在一些大型的項目中，對分離開發(fā)模式進行了一些調(diào)整，說實在的有些不得以，但是這應(yīng)該是目前最符合現(xiàn)狀的前后端分離的開發(fā)模式，抱著發(fā)展的眼光向前看，前端不斷壯大之后，應(yīng)該會有讓人滿意的答卷的！
