PC與移動端高效開發解決方案

前端開發不可避免會遇到一個問題：PC與移動端開發是共用一套代碼？仍是兩套獨立開發？前端

這個問題到目前都沒有一個明確的結論，或者說它原本就不會有惟一的答案，畢竟所屬需求不一樣。數據庫

對於一些簡單的系統：一套代碼就能搞定，那何必花費兩倍的時間來作雙份。後端

對於複雜性的或是UI展現差別較大的系統：如果一套代碼的話，光是樣式調整就足以耗費掉開發者全部的熱情，那還不如分開作來得更方便。markdown

可是不少時候，對於這種狀況，咱們仍是會不自覺的會提出疑問，難道就必需要花費雙倍的時間嗎？？？不能等於1，還不能小於2？？？架構

這個方案分兩方面來討論說明：數據及UI。看看能不能對PC與移動各端前端開發進行復用與融合，從而進一步來釋放人力。微服務

固然，若是你們以前已經作了足夠的方案測試，而且已經確認不想融合的，那看到此就能夠了。畢竟有句話已經說的很直白了：測試

強扭的瓜不甜。spa

奈何臣妾不死心吶！！！3d

目的：一步式的同步各端數據。code

包含模塊：後端數據+靜態數據

對於接口的問題：無論是接口變動，仍是多個接口的合併等，先後端真的已經相愛相殺了過久，但永遠都沒法徹底避免。畢竟對於接口的變動有時候連前端人員都同意更改；對於接口是否合併，各方也有充足的理由。

但這並不意味着前端人員樂意重複更改，因此咱們要提效->作統一->作中間件。

在這裏靜態數據，指的是那些在前端頁面中寫死的數據或文案值等，固然也能夠統稱爲配置項。

包括屬性值、操做項等等，通常輸出JSON數據，用JS文件、JSON文件等存儲；固然若是熟悉數據庫表的話，徹底也能夠把這些數據整理成表的形式來存儲。

屬性值：如一些自定義列數據集合等；

篩選項：以下拉菜單篩選項集合等（比方說列表查詢會有不少篩選項，能夠把這些數據進行整合，適配各端）。

UI上的融合，能夠先看下各自對應的PC和移動端系統，估算下到底有多少差別及差別度等。

UI上的複用，能夠從兩方面來處理：

如數據融合內提到的篩選項部分。篩選項的展現JSON數據共用，UI分開。以下拉菜單，PC用PC端組件Select下拉框的模板，移動用移動端組件的單選模板等等。

若是細緻來看的話，並不是全部的功能或是UI不可複用，那麼能夠把這部分單獨提業務組件，以業務組件微服務的模式共用。

總之，實踐出真理。

就先到這兒吧，不想多說了，詳細的說明也就不畫了。留一分鐘我要用來靜靜的思考下人生。