重構構建的平凡之路

歡迎你們前往騰訊雲社區，獲取更多騰訊海量技術實踐乾貨哦~

做者：李旦

導語

剛開始作前端的時候，一直覺得切好頁面是重構的所有職責，在切好頁面的前提，增長頁面交互，這樣已經能到重構的頂峯。直到進入公司後發現參與的項目都有兩個特色，項目複雜和參與人數的多，發現傳統的方法已經不適用。主要介紹本身重構構建經歷，若有問題歡迎指教！ 乀(ˉεˉ乀)

以往存在的問題

這裏介紹本身以往傳統重構的方法容易暴露的缺點。

1. 編寫風格不統一，致使代碼可讀性差，增長後期維護成本與溝通成本；
2. HTML和CSS代碼冗餘，增長了重構開發成本和頁面打開速度；
3. 項目開發週期長，缺乏公共與私有框架的規劃，一樣會增長後期維護成本與開發成本，可複用性差；
4. 項目文件部署雜亂，致使項目後期維護困難；
5. 重構開發方法有優化提高空間；

重構構建的初步發展

在項目開始的時候，因爲項目過大，支持重構的人愈來愈多了，這個時候你們討論出的一些方法有：定義統一的代碼規範、項目文件的合理部署、重構的方法優化、開發的自動化和重構架構的統一

實現方式：

1. 重構文件的統一部署，區分開發環境和正式環境；
2. 統一HTML和CSS代碼的命名方式，增長代碼的可讀性，減小溝通成本；
3. 使用SASS抽離公共組件樣式的模塊，使得CSS的開發變得簡單可維護，使頁面可組合；
4. 使用Compass，自動生成雪碧圖而且CSS同時生成背景座標，提高重構效率；
5. 編寫SASS公共方法，減小重複CSS代碼，提高重構效率（包括compass自帶方法函數）；
6. 結合gulp構建工具，對雪碧圖自動合併，sass生成，文件部署快速部署，項目的分類進行統一管理；

重構構建的深度擴展

主要是以項目2.0版本爲基礎進行構建優化

第一個版本引出的問題：

1. 因項目龐大，前期考慮不足，缺乏顏色的配置方案，致使後期須要換膚功能沒法支持，沒法統一調整；
2. 文件未作合併壓縮，增長了頁面的請求；
3. 命名的統一雖然能解決代碼的可讀性，可是當代碼過多時，查看起來仍然使人眼花繚亂，同開發之間的對接也變得困難；
4. 上傳不方便，強行增長聯調和測試的門檻；

主要圍繞在不提高web架構的複雜度，結合構建工具使頁面模塊化和組件化，優化重構的工做流程，同時節省重構與前端或者開發之間的對接時間，搭建屬於重構的管理系統加強重構對項目的管理能力

頁面皮膚配置

在項目2.0初期時候，提早與設計進行頁面換膚的顏色探討，重構的時候根據少數顏色結合sass的顏色函數，達到頁面總體的顏色配置。

後續有擴展空間，能夠將配置放入管理端中，經過管理端傳入顏色的配置再進行編譯生成CSS文件。

LiveReload實現瀏覽器自動刷新

對頁面進行樣式更改以後，每每會屢次刷新頁面查看效果，對頁面進行聯調的時候更能體現出自動刷新的重要性，每每一個細節會花不少時間

使用條件：

1. 谷歌安裝LiveReload工具；
2. 用http-server配置靜態服務器，打開網頁
3. 執行配置好的gulp，而且打開谷歌LiveReload工具

優化：

由於LiveReload並非特別好使用，因此用 Browsersync 來替代LiveReload，Browsersync的功能更全更方便。這裏好處我不一一列舉，能夠查看 Browsersync官方文檔，有更詳細的介紹。

其中也遇到了一些問題，由於是HTML和CSS都是編譯生成，得須要去動態監聽生成文件的改變，進行自動刷新。

靜態頁面的模塊化、組件化

爲何重構也要模塊化、組件化：

1. 模塊強調分離，對重構而言，咱們不能每次只寫本身的HTML作好本身的事，重構是提供整張頁面給前端或者後端，在龐大且複雜的項目中後續在開發頁面時，每增長一個模塊都須要和對接人員溝通清楚，可能還得指出具體位置；
2. 組件強調複用，在重構新的頁面時，對公共組件部分還得進行再重構，增長了重構的開發時間；

實現方式：

• HTML：Gulp-content-includer

將靜態HTML進行模塊化開發，當開發人員拿到重構頁面時候看到include模塊， 清晰的知 道頁面中引用了那些新模塊，直接去進行快速開發，同時會生成完整的靜態html便於查看效果。同時也避免了重構對公共組件的再重構，節省了重構製做靜態頁面的時間。利用gulp實現include雙向綁定，更改include同時會更新完整靜態html，而且瀏覽器會檢測更改自動刷新

• CSS：SASS

CSS模塊經過SASS進行組件化區分，避免引用多餘的組件樣式

搭建CSS和圖片管理系統

由於管理系統是本身獨自處理，因此還有不少待改進的地方，在可以完成基礎功能的前提，後續繼續慢慢跟進。

爲何要搭建管理後臺？

剛開始在項目初期的時候，咱們在每次聯調或者重構完頁面時，都須要經過前端或者開發進行協助將CSS及圖片上傳到對應環境中，最後由於實在太麻煩，重構也開始使用跳板機進行環境的上傳。而後發現每次頁面在後期聯調維護的時候，由於上傳環境複雜，須要花不少不必的時間在跳板機上傳上，增長了工做量。

管理後臺有哪些功能？

• 文件上傳
  整個管理後臺是以圖片和CSS的上傳與管理爲基礎圍繞展開。

• 文件壓縮
  包括CSS文件的壓縮，圖片的上傳進行自動壓縮，而且會將顏色配置的CSS和全局公共的CSS合併在同一個文件中，壓縮後文件命名以 項目名+min.css 組成，線上保證有一份源CSS同時還會有一個壓縮後CSS

爲何不將CSS合併與壓縮功能作在gulp中，卻作到管理端上？

若是作到gulp中，會不方便後期的改版維護，在發佈時，由於都是壓縮過的CSS代碼，不便和線上進行對比。雖然有SVN，可是爲了保證一切以線上爲主的基礎，仍是會對線上的代碼進行對比。

• 文件打印

用於打印CSS文件代碼，更方便的進行對比操做

最後

以上只是列舉了我我的在項目中重構構建歷程，主要是爲了減輕重複勞動，提升效率。咱們能夠選擇更加適合本身的方案，而不是在追尋技術的路上迷失了方向。

最後的最後

各位大佬求輕吐！！！

相關閱讀

代碼自動生成在重構中的一次探索

重構代碼的Tricks

CSS 路徑動畫工具的誕生

此文已由做者受權騰訊雲技術社區發佈，轉載請註明原文出處