剛開始做前端的時候，一直以為切好頁面是重構的全部職責，在切好頁面的前提，增加頁面互動，這樣已經能到重構的頂峰。直到進入公司後發現參與的專案都有兩個特點，專案複雜和參與人數的多，發現傳統的方法已經不適用。主要介紹自己重構構建經歷，如有問題歡迎指教！ 乀(ˉεˉ乀)
這裡介紹自己以往傳統重構的方法容易暴露的缺點。
編寫風格不統一，導致**可讀性差，增加後期維護成本與溝通成本；
html和css**冗餘，增加了重構開發成本和頁面開啟速度；
專案開發周期長，缺少公共與私有框架的規劃，同樣會增加後期維護成本與開發成本，可復用性差；
專案檔案部署雜亂，導致專案後期維護困難；
重構開發方法有優化提公升空間；
在專案開始的時候，由於專案過大，支援重構的人越來越多了，這個時候大家討論出的一些方法有：定義統一的**規範、專案檔案的合理部署、重構的方法優化、開發的自動化和重構架構的統一
實現方式：
重構檔案的統一部署，區分開發環境和正式環境；
統一html和css**的命名方式，增加**的可讀性，減少溝通成本；
使用sass抽離公共元件樣式的模組，使得css的開發變得簡單可維護，使頁面可組合；
使用compass，自動生成雪碧圖並且css同時生成背景座標，提公升重構效率；
編寫sass公共方法，減少重複css**，提公升重構效率（包括compass自帶方法函式）；
結合gulp構建工具，對雪碧圖自動合併，sass生成，檔案部署快速部署，專案的分類進行統一管理；
主要是以專案2.0版本為基礎進行構建優化
第乙個版本引出的問題：
因專案龐大，前期考慮不足，缺少顏色的配置方案，導致後期需要換膚功能無法支援，無法統一調整；
檔案未做合併壓縮，增加了頁面的請求；
命名的統一雖然能解決**的可讀性，但是當**過多時，檢視起來仍然令人眼花繚亂，同開發之間的對接也變得困難；
上傳不方便，強行增加聯調和測試的門檻；
主要圍繞在不提公升web架構的複雜度，結合構建工具使頁面模組化和元件化，優化重構的工作流程，同時節省重構與前端或者開發之間的對接時間，搭建屬於重構的管理系統增強重構對專案的管理能力
在專案2.0初期時候，提前與設計進行頁面換膚的顏色**，重構的時候根據少數顏色結合sass的顏色函式，達到頁面整體的顏色配置。
後續有擴充套件空間，可以將配置放入管理端中，通過管理端傳入顏色的配置再進行編譯生成css檔案。
對頁面進行樣式更改之後，往往會多次重新整理頁面檢視效果，對頁面進行聯調的時候更能體現出自動重新整理的重要性，往往乙個細節會花很多時間
使用條件：
谷歌安裝livereload工具；
用http-server配置靜態伺服器，開啟網頁
執行配置好的gulp，並且開啟谷歌livereload工具
因為livereload並不是特別好使用，所以用 browsersync 來替代livereload，browsersync的功能更全更方便。這裡好處我不一一枚舉，可以檢視 browsersync官方文件，有更詳細的介紹。
其中也遇到了一些問題，因為是html和css都是編譯生成，得需要去動態監聽生成檔案的改變，進行自動重新整理。
為什麼重構也要模組化、元件化：
模組強調分離，對重構而言，我們不能每次只寫自己的html做好自己的事，重構是提供整張頁面給前端或者後端，在龐大且複雜的專案中後續在開發頁面時，每增加乙個模組都需要和對接人員溝通清楚，可能還得指出具體位置；
元件強調復用，在重構新的頁面時，對公共元件部分還得進行再重構，增加了重構的開發時間；
實現方式：
將靜態html進行模組化開發，當開發人員拿到重構頁面時候看到include模組， 清晰的知 道頁面中引用了那些新模組，直接去進行快速開發，同時會生成完整的靜態html便於檢視效果。同時也避免了重構對公共元件的再重構，節省了重構製作靜態頁面的時間。利用gulp實現include雙向繫結，更改include同時會更新完整靜態html，並且瀏覽器會檢測更改自動重新整理
css模組通過sass進行元件化區分，避免引用多餘的元件樣式
因為管理系統是自己獨自處理，所以還有很多待改進的地方，在能夠完成基礎功能的前提，後續繼續慢慢跟進。
為什麼要搭建管理後台？
剛開始在專案初期的時候，我們在每次聯調或者重構完頁面時，都需要通過前端或者開發進行協助將css及上傳到對應環境中，最後因為實在太麻煩，重構也開始使用跳板機進行環境的上傳。然後發現每次頁面在後期聯調維護的時候，因為上傳環境複雜，需要花很多沒必要的時間在跳板機上傳上，增加了工作量。
管理後台有哪些功能？
為什麼不將css合併與壓縮功能做在gulp中，卻做到管理端上？
如果做到gulp中，會不方便後期的改版維護，在發布時，因為都是壓縮過的css**，不便和線上進行對比。雖然有svn，但是為了保證一切以線上為主的基礎，還是會對線上的**進行對比。
用於列印css檔案**，更方便的進行對比操作
以上只是列舉了我個人在專案中重構構建歷程，主要是為了減輕重複勞動，提高效率。我們可以選擇更加適合自己的方案，而不是在追尋技術的路上迷失了方向。
重構構建的平凡之路
剛開始做前端的時候，一直以為切好頁面是重構的全部職責，在切好頁面的前提，增加頁面互動，這樣已經能到重構的頂峰。直到進入公司後發現參與的專案都有兩個特點，專案複雜和參與人數的多，發現傳統的方法已經不適用。主要介紹自己重構構建經歷，如有問題歡迎指教！乀 乀 這裡介紹自己以往傳統重構的方法容易暴露的缺點。...
不平凡之路
反覆 糾結這麼久，終於開通了部落格。說機緣巧合也好 說天時地利人和也罷。總之有一顆信念的種子開始埋在了我的心裡 出路。人生的出路。所謂人生，絕不只是一場體驗 一場旅行，我更願意視之為一場修行。或住或行，無不是增加生命的分量。在稍稍可以領略到諸前輩大師們心血的澆築與智慧型的光芒那一刻，我真的似乎看到人...
2015，平凡之路
2015年過去了，躺在床上拖著略微疲憊的身體，點開了qq空間，突然發覺每年都會寫點什麼，不過去年是寫在自己的技術部落格上，今年還是老樣子，寫在qq空間裡面，順便記錄一下自己的點滴 2015年，感覺自己當初毅然決然的花時間搞技術，搞it是對的，在今年越花時間在技術上，收穫越多，甚至有點稍微打亂了原先的...