重構構建的平凡之路

2021-09-11 11:05:30 字數 2432 閱讀 1043

剛開始做前端的時候,一直以為切好頁面是重構的全部職責,在切好頁面的前提,增加頁面互動,這樣已經能到重構的頂峰。直到進入公司後發現參與的專案都有兩個特點,專案複雜和參與人數的多,發現傳統的方法已經不適用。主要介紹自己重構構建經歷,如有問題歡迎指教! 乀(ˉεˉ乀)

這裡介紹自己以往傳統重構的方法容易暴露的缺點。

編寫風格不統一,導致**可讀性差,增加後期維護成本與溝通成本;

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檔案**,更方便的進行對比操作

以上只是列舉了我個人在專案中重構構建歷程,主要是為了減輕重複勞動,提高效率。我們可以選擇更加適合自己的方案,而不是在追尋技術的路上迷失了方向。

最後的最後

各位大佬求輕吐!!!

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

重構**的tricks

css 路徑動畫工具的誕生

重構構建的平凡之路

剛開始做前端的時候,一直以為切好頁面是重構的全部職責,在切好頁面的前提,增加頁面互動,這樣已經能到重構的頂峰。直到進入公司後發現參與的專案都有兩個特點,專案複雜和參與人數的多,發現傳統的方法已經不適用。主要介紹自己重構構建經歷,如有問題歡迎指教!乀 乀 這裡介紹自己以往傳統重構的方法容易暴露的缺點。...

不平凡之路

反覆 糾結這麼久,終於開通了部落格。說機緣巧合也好 說天時地利人和也罷。總之有一顆信念的種子開始埋在了我的心裡 出路。人生的出路。所謂人生,絕不只是一場體驗 一場旅行,我更願意視之為一場修行。或住或行,無不是增加生命的分量。在稍稍可以領略到諸前輩大師們心血的澆築與智慧型的光芒那一刻,我真的似乎看到人...

2015,平凡之路

2015年過去了,躺在床上拖著略微疲憊的身體,點開了qq空間,突然發覺每年都會寫點什麼,不過去年是寫在自己的技術部落格上,今年還是老樣子,寫在qq空間裡面,順便記錄一下自己的點滴 2015年,感覺自己當初毅然決然的花時間搞技術,搞it是對的,在今年越花時間在技術上,收穫越多,甚至有點稍微打亂了原先的...