解決先後端工程師協同工做的問題

       先後端工程師工做協同工做主要環節在於數據交互與業務流程控制。

       在數據交互方面遇到這種狀況，先後端工程師一開始沒有溝通好數據交互格式，由於後端作得快，已經寫完接口，出了接口文檔，而前端工程師在開發的時候使用了一些框架或者是一些插件，而框架的接口數據有規定，可是後端出的接口數據與前端開發所須要的接口數據不同，這時候前端工程師就處於被動狀態，臨時解決問題方法只有三個：

        1、把後端傳過來的數據在前端再轉化一次，轉成框架須要的接口數據。

              缺點：加大了前端開發時間，影響前端頁面性能。

        2、前端從新本身寫一套前端組件，根據後端接口讀取數據。

              缺點：加大了前端開發時間。

        3、讓後端工程師根據前端框架的接口數據從新寫接口。

              缺點：加大了後端開發時間，影響後端數據處理。

      想一想都知道，後端工程師確定不肯意重寫接口，後端工程師就說會影響不少代碼，苦逼的仍是前端工程師。前端工程師只能一步一步從新改造前端頁面。

      在業務流程控制方面遇到這種狀況，先後端工程師一開沒有明確的分工，前端工程師一直負責view方面，後端工程師一直負責model方面，中間的control方面沒有處理，結果到先後端項目合併就出現了問題。中間一個業務控制層沒有了。項目某些地方業務沒法處理，後果可想而知。臨時解決問題方法只有兩個：

        1、前端進行業務流程控制。

              缺點：加大了前端開發時間。純靜態技術實現會致使部分頁面數據不安全，容易丟失數據，不能爲用戶提供動態數據。（胖客戶端-瘦服務器）

        2、後端進行業務流程控制。

              缺點：加大了後端開發時間。（瘦客戶端-胖服務器）

      想一想都知道，後端工程師確定不肯意重寫業務控制層，後端工程師就說會先後端分離，減輕服務端壓力。苦逼的仍是前端工程師。前端工程師只能一步一步從新添加control層代碼。

      綜合上述，這個坑永遠仍是前端工程師填。那麼如何解決以上兩類問題呢？答案其實很簡單，這兩類問題產生的主要緣由是缺少溝通。所以，在項目開始的時候必定要溝通。前端工程師必定主動要向後端工程師說明使用框架所須要的數據接口格式。而且必定要分工明確，搞清楚前端負責哪些部分，後端負責哪些部分，業務流程控制須要先後端如何配合。這樣才能避免以上兩類問題，從而影響工做進度。（說白了就是爲何要加班）