疑問
前端開發不可避免會遇到一個問題：PC與移動端開發是共用一套代碼？還是兩套獨立開發？
這個問題到目前都沒有一個明確的結論，或者說它本來就不會有唯一的答案，畢竟所屬需求不同。
對於一些簡單的系統：一套代碼就能搞定，那何須花費兩倍的時間來做雙份。
對於複雜性的或是UI展示差異較大的系統：若是一套代碼的話，光是樣式調整就足以耗費掉開發者所有的熱情，那還不如分開做來得更方便。
但是很多時候，對於這種情況，我們還是會不自覺的會提出疑問，難道就必須要花費雙倍的時間嗎？？？不能等於1，還不能小於2？？？
方案
這個方案分兩方面來討論說明：數據及UI。看看能不能對PC與移動各端前端開發進行復用與融合，從而進一步來釋放人力。
當然，如果大家之前已經做了足夠的方案測試，並且已經確認不想融合的，那看到此就可以了。畢竟有句話已經說的很直白了：
強扭的瓜不甜。
奈何臣妾不死心吶！！！
數據上的融合
目的：一步式的同步各端數據。
包含模塊：後端數據+靜態數據
後端數據的統一
對於接口的問題：不管是接口變更，還是多個接口的合併等，前後端真的已經相愛相殺了太久，但永遠都無法完全避免。畢竟對於接口的變更有時候連前端人員都贊成更改；對於接口是否合併，各方也有充足的理由。
但這並不意味着前端人員樂意重複更改，所以我們要提效->做統一->做中間件。
靜態數據的統一
在這裏靜態數據，指的是那些在前端頁面中寫死的數據或文案值等。
包括屬性值、操作項等等，一般輸出JSON數據，用JS文件、JSON文件等存儲；當然如果熟悉數據庫表的話，完全也可以把這些數據整理成表的形式來存儲。
屬性值：如一些自定義列數據集合等；
篩選項：如下拉菜單篩選項集合等（比方說列表查詢會有很多篩選項，可以把這些數據進行整合，適配各端）。
中間件層架構![在這裏插入圖片描述]()
UI上的融合
UI上的融合，可以先看下各自對應的PC和移動端系統，估算下到底有多少差異及差異度等。
UI上的複用，可以從兩方面來處理：
以數據爲驅導的UI獨立
如數據融合內提到的篩選項部分。篩選項的展示JSON數據共用，UI分開。
如下拉菜單，PC用PC端組件Select下拉框的模板，移動用移動端組件的單選模板等等。
以獨立功能爲單元的UI共用
如果細緻來看的話，並非所有的功能或是UI不可複用，那麼可以把這部分單獨提業務組件，以業務組件微服務的模式共用。
就先到了，不想多說了，詳細的說明也就不畫了。留一分鐘我要用來思考下人生。