咱們前端跟後端是怎麼合做的

摘要: 文章背景，來自於羣內週五晚上的一次頭腦風暴式的思惟碰撞交流活動。

咱們的流程是這樣的，後臺提供數據接口，或接口文檔。 
而後咱們前臺進行razor模板的數據邏輯嵌套或html,css,js整個流程的開發。 
缺點是：工做量是滿大的，優勢是，全部前端view層的東西都是可控的。 
坑是比較多的， 
好比數據出現問題時，沒有一個經驗豐富的前端或後端進行聯調， 
有問題短期內是解決不了的。

 

通常跟後臺合做分爲這幾種模式：
1. 只產出html頁面，而後交給後端來處理數據。
這種的好處是工做量比較少，公司沒有專門的前端崗位時能夠實行這種辦法。
但這種的缺點也是顯而易見的，後端人員工做量偏大，若是有ajax或數據添加後出現樣式問題，
進行聯調，花費更長的時間。

2. 產出靜態的php,jsp頁面，而後交給後端來處理數據。
這種的好處是由於提交的是php,jsp頁面，若是數據添加以後界面出現問題，能夠很快的去調整，
方便各類聯調，可是最根本的問題是後端的工做量仍是稍大，並無徹底的減輕後端人員的壓力。
打包發佈仍是須要依賴後端，並且在開發中依賴後端的情形偏重。

3. 產出動態有數據的php,jsp頁面，前端與後端的打包發佈徹底獨立。
這種的好處是前端層的表現，數據徹底由前端把控，
有什麼問題能夠由前端獨立解決，並單獨打包發佈。
缺點是因爲前端的工做量加大，對前端的技術存儲要求偏高，人力招聘有必定的難度。

因爲這種界限的劃分有時候很難肯定，這時候羣內朋友給出的建議是：
1. 公司上級肯定，這個活該誰來幹 
2. 看公司實際狀況，若是FE人少，那麼就交給RD 
3. 根據不一樣的語言來區分對待。

還有其它人的合做方式是：
一、提出需求，講明白前端要的接口效果。看後臺人員是否能知足這樣需求，若是有現成的接口，直接調用就是。若是沒有，那麼就跟後臺人員協商是否能夠再次開發。評估工做量和完成日期。 
2，有時候後端設計出來的接口不必定能知足全部的需求，也許在某個方法中有個雷，直到本身去調用才知道。就好比批量插入數據，前臺可能會循環調用保存，而不是後臺批量插入。前臺依次來調用是能夠完成操做，可是效率是個問題，須要很好的去權衡。

在與後端合做當中，後端沒有提供數據接口，如何處理？有如下幾種辦法：
1. 本身製做模擬數據
這種辦法的缺點時，有時候可能會形成api變動時沒有及時更新，好處也是顯而易見，可以快速的完成前端任務。
2. 使用http://mockjs.com/，模擬數據生成器

其它有坑的地方：
數據的換算時的謹防精度丟失，接口的返回數據不許確，還有配置文件的頻繁修改形成的數據不對等。
咱們是前端本身模擬全部的數據接口，後端配合咱們作接口，反過來了。 
前端只需提供一些配置給後端，好比數據請求地址等等，後端配上就ok

接口通訊，文檔配合交流 
http://www.cnblogs.com/hustskyking/p/interface-in-development.html

先後端分工 還不錯。

根據上面的探討得出如下的結論：
1. 前端了解一門後端語言有助於工做效率的提升，是未來的一個大趨勢。
2. 前端的邏輯數據徹底能夠徹底分離，也就是能夠與後端不一樣的語言種類。

 

---

前端開發qq羣：348090425 ，禁止閒聊，非喜勿進~！