style文件分級體系

0 評論 2246 瀏覽 0 收藏 7 分鐘

前段時間出了好幾起因為css改動影響其他應用的故障。想想也是,網站已經10年,從table時代一路走來,style目錄上的文件早已混亂不堪。不看內容,光是目錄結構和文件的命名就已經讓人犯暈。于是準備在Q1對style文件進行整理規劃,大致有兩個想法。

第一點、style文件(包含css和javascript)應該是分層級的。試想下如果誰都可以改動全站的框架js那會有多大的風險!這里我們把style分為三級:

第1級:全站性。 這一類文件是全站通用的,主要是框架fdevlib。文件的修改權在前端架構組這邊,任何的應用都不應該修改這一級別的文件。架構組負責對該類文件的更新和維護。ps:這個做法對我們網站還有一個隱問題。因為widget組件很多都是來自各產品線的一線開發而不是架構組專人來開發維護,所以我們還需要一套完備的入庫審核機制。

第2級:產品線級。根據前端代碼的依賴關系把網站劃分成近10條產品線,每條產品線的代碼相對對立,并為每條產品線指定owner。owener負責整理本產品線的style文件,規劃出1到3個左右本產品線公用的樣式和腳本。這些文件的維護權在owener手里,一般的應用應該在這些文件的基礎上進行擴展。毫無疑問,在第二級的樣式文件里可以做更多的東西。比如嵌入產品線獨特的展示方式、皮膚、業務邏輯等等……

第3級:應用級。這些文件的權限應該是開放的。因為網站的產品互相穿插膠著,一個前端可能需要涉及多個產品線,為了避免沖突,應該在1、2及框架的約束下進行擴展開發、重載。沒有特殊的情況絕對不能修改1、2級的文件。確保多人開發的情況下不會互相影響。

層級關系示例圖如下:

第二點、頁面style文件的引用規劃:

按照網站目前的做法,比較重要的頁面都是采用服務器端merge的方式將調用的css或是js合并在1個文件中。比如目前?中文站首頁 底部的”http://style.china.alibaba.com/js/homepage/index1001/merge/index-bottom.js”這個腳本。在發布之前它的實際內容是import了多個js:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/*merge start*/
(function(){
	ImportJavscript = {
		url:function(url){
			document.write("<script src=\""+url+"\"></scr"+"ipt>");
		}
	}
})();
/*merge end*/
ImportJavscript.url("http://style.china.alibaba.com/****/fdev-min.js");
ImportJavscript.url("http://style.china.alibaba.com/****/get-min.js");
ImportJavscript.url("http://style.china.alibaba.com/****/animation-min.js");
ImportJavscript.url("http://style.china.alibaba.com****/fdev-tab-min.js");
ImportJavscript.url("http://style.china.alibaba.com/****/fdev-marquee-min.js");
ImportJavscript.url("http://style.china.alibaba.com/****/fdev-alitalk-v3.js");
ImportJavscript.url("http://style.china.alibaba.com/****/done-min.js");

好處顯而易見,可以減少http請求數。但是實際維護起來的成本卻比較大。一方面每次新增需要merge的腳本時都要修改這個文件;另一方面很多公用的腳本比如框架性質的fdev.js都沒有被緩存。

怎么改進?拿js來說,基于上面規劃的style文件分級體系。我們首先將1級的框架類腳本merge起來,生成一個 http://style.china.alibaba.com/cache/aliframe.js 作為全站統一的緩存資源。其次需要對每條產品線建立一個merge的js,比如http://style.china.alibaba.com/cache/frame-list.js,它里面import了aliframe.js和list所屬的2級公用js。 最后對這些腳本目錄設置一個相對較長的緩存時間。這樣一來,對于簡單的非產品線屬頁面,只要引aiframe.js文件后再引入頁面特有的腳本即可。而對于產品線屬頁面也只需要引入相應的js(比如frame-list.js)后再添加應用級的腳本。一般情況下的改動只需要修改第3級的應用類腳本,不需要動到已緩存的頁面。這樣既降低了維護成本,新增腳本時不需要再改動已經merge的腳本文件,又通過緩存提高了頁面的加載速度。所增加了一個http請求還是值得的。

說完,最后感慨一下:前端的發展速度的確是快。07年底中文站一共才6個前端開發,而到09年底的時候這個數字包含外包已經達到22個了。07年前絕大多數需求還是上傳圖片、切割頁面之類的小任務而現在前端已經深入到業務的核心模塊。在快速擴張的同時如何發揮出團隊的整體作戰力達到1+1>2的效果,大家可以一起來探討下。

來源:http://f2e.me/archives/188

給作者打賞,鼓勵TA抓緊創作!
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!