大規模互連網產品的網頁製作經驗分享

文章描述：聊聊互連網產品的網頁製作。

想說下怎麼做好比如新浪部落格這樣一個規模較大的互連網產品的網頁製作，這個事情看起來很簡單，開發leader會說，作為builder，快速提供優質的靜態頁就好了，可怎麼做才能把這事做的漂亮，方便開發又易於後面需求變更和維護，我們先從檔案夾部署開始說。

檔案夾部署這事可小可大，一般builder都會劃分為css、images等幾個不同的檔案夾，或者把樣式圖片放到一個檔案夾裡，每個人都有自己的習慣，先給大夥看看我們定的

 

四個檔案，樣式，圖片，皮膚，預覽頁面都獨立放置，當然裡面的子檔案夾有規定，這個下面會提到，為什麼這麼做，先列四個好處，更多的優點，這篇文章裡會穿插提到

• css和images檔案獨立，方便一些特定情況下css和images包分別部署
• css和images檔案相互聯絡，可以打成一個style包部署
• 本地相對路徑跟線上保持一致（避免開發調試過程中需要反覆上線修改絕對位址）
• html靜態檔案預覽清晰
• 方便開發和上線svn

前面幾個好處跟開發過程中的代碼控制都有關係，重點說一下svn吧，我們知道：在一些項目裡面涉及的前前後後的開發工程師比較多，必須用svn等版本控制工具進行代碼管理，也方便配合上線部署。

而作為頁面工程師來說，預覽不需要環境（不管是本地配置的localhost還是伺服器環境），我們修改一個css屬性，都可以直接用瀏覽器重新整理一下，相信大家在學校，或者在做一些規模不大項目，比如小型企業站的時候，一般採取的方式是：在本地開發完畢，然後找到伺服器在哪，ftp傳上去就是了。這個時候的流程就是

本地開發>>>>>伺服器
這個事情如果把svn引入進來，就有點麻煩，因為大家再開發中，svn不光是代碼控制的工作更是控制部署的重要手段。

本地>>>>>svn上傳>>>>>部署到前端伺服器
有些工程師會有自我保護心理，他感覺直接在svn檔案夾裡寫代碼會跟別人有影響，不安全，會在本地還分了開發，和svn檢出兩個檔案夾，那這個流程就複雜成了
本地開發>>>>>（複製到）本地svn檔案夾>>>>>svn上傳>>>>>線上部署

這時候熟悉svn的同學會想到很多問題（這兒就說其中兩點）
我們知道，在一個典型的svn結構裡面分……三部分trunk tags branch，頁面工程師寫的東西因為有預覽靜態頁面這個線上上用不到的東西，所以不能直接扔到svn的這些檔案夾裡，這樣的話對我們如果把css image skin放到trunk，html預覽檔案放在外面，遇到一個問題，就是我們的檔案相對結構亂套了！！換句話說，我們不能在寫到頁面裡的img路徑裡面加上../../trunk這樣的東西。
而且實際工作起來，流程也會出問題，一般情況下，開發的部署可能會滯後，我們在看到設計稿雛形的時候就要準備靜態頁的結構和css架構，但這時候開發工程師要做的是資料庫等更深層次的部署，我們不能等他們把開發過程中檔案的部署上線流程都定好再開工，這顯然是不合適的。所以實際過程中會有兩個svn（我們的靜態頁svn和真正的控制打包上線的svn）

說到這，肯定有人會問，我們把頁面放到項目的svn下不行嗎？先不說是不是合適做不同產品間的代碼管理，即便放到項目下，為了避免影響，開發leader會指定一個比如“html”的檔案夾供builder用，這其實還是跟控制打包上線的svn是兩回事
第二個問題，我們在本地開發，只把css和images真正需要的東西傳svn不行嗎？這個問題……那我們的靜態頁不需要做版本控制了嗎？

所以，我們不得已，在svn有個放html、css、images這些檔案的地方，為了不同項目間的代碼管理，放在了一個單獨的svn庫下，我們稱之為builder svn，這樣，剛才的流程就又加了一步
 
一段代碼，一個檔案，從開始寫到最終上線（也可以指測試機或開發機……），到要複製四次，太恐怖了，在反覆測試的時候不出錯才怪。所以我們要做些事情：

1. 本地開發和builder svn的檢出檔案夾放到一塊
2. 自動關聯buildersvn和svn上線庫
3. 讓工程師幫忙，把部署這個事情簡單化，至少在往測試機或開發機部署的時候簡單的只需要做一個f5
那事情就簡化了

 
前面提到的第二點，可以用svn的映射來實現，如圖

 

 

而且有兩個方案，一個是從buildersvn往上線svn庫映射

 

但這樣有個問題，因為在上線庫裡存的只是一個連結，在打包上線的時候都取不到版本號碼，不利於上線後的復原等事情，我們只好反過來做

 

這樣雖然還存在一些使用權限設定麻煩等問題，不過好在解決了上線的根本問題

部署方面還有更複雜的情況，比如在一和大項目下，不同的模組是不同的開發小組，甚至不同的上線庫！！
這就涉及到我們剛才二級檔案夾的部署，在這個層面，我們要做幾個事情：

1.css和images檔案夾下明確common下的東西
2.css和images檔案夾的子檔案夾，同名的檔案夾聯絡緊密，不同的檔案夾之間相互獨立（見下圖，css和圖片的引入不能有超越紅線的交叉）
3.skin雖然下面也有子檔案，但部署的時候一般是打包一塊做的，做好映射即可

 

把前面這些事情定好，作為builder工作效率可以高很多了，不至於在後面的開發中為這些事情撓頭

部署做完，我們就可以做具體的事情了，先說說html檔案，這個預覽檔案做出來無非下面的三個用處

1.我們自己開發
2.產品或設計師看效果
3.工程師開發時作為參考

先說檔案本身，因為這個不會上線，我們開發只是在本地，跟伺服器環境沒關係，為了方便後面兩個需求，建議所有的檔案名稱寫成漢語，檔案名稱跟設計稿或ue原型圖裡面每個頁面保持一致就可以了。另外，html的子檔案夾也跟css等檔案夾下的子檔案保持一致。具體代碼裡面除了注意 DOCTYPE和編碼（我們一般是用utf8）比較重要的一點就是css的引入了：

1.前面說到，檔案夾部署裡面有個common，這個是公用檔案，首先引入
2.其次是引入自己頁面或模組相關的css，就是第一部分裡面提到某個檔案夾它應該跟其他是相對獨立的
3.如果後面有皮膚的話，引入skin檔案

 

這個順序是我們整體架構的一部分，必須嚴格執行。前面提到，html中要先引入common這個公用檔案
這這個css裡面分幾個方面：

1. 清零

這次主要說部署和開發流程的事，所以清零這部分的技術細節不在贅述，但有個策略需要周知，就是（所有產品儘可能保持一致，升級或者打補丁要謹慎，多人協作的話要提出來讓大夥周知）
2. 通用的class類,包括下面幾個方面

大家都會用到，或有必要在全域裡指定，屬性單一
比如：chear float wordwrap
文字色，連結色（類別化，不要語義化）
其他，由架構師和項目組共同確定
不建議的東西
比如f14，f12，fsun，p10，pt20，m10等屬性
這些有個共同點：具體屬性很具體的某個值，或者跟其他重複，是語義化的定義方式
不建議的原因：會造成下面模組化不徹底，不同人之間的維護費勁

說到這，會有人問，不是要推薦語義化嗎？語義化當然要推薦，但不是在這，舉個例子，如果我們在全域定義了.red作為文字色，那到下一個模板裡，這個顏色成了藍色，不就囧大了？
3. 公用元素

結構性樣式各個部分都可能會用到的公用樣式，比如分頁，列表，
需要統一管理的樣式：按鈕，icon，實線虛線等
注意幾點：
結構架構，不要定義內邊距
公用樣式，要寫死細節，但不要定義整體位置
按鈕靈活
icon用透明圖配合樣式，注意按照大小分類，同類下寬高一致
實線虛線等給出標準圖，css中採用 只提供背景 和 平鋪好的一像素div 兩種方式提供公用樣式
4. 皮膚基礎

如果要換膚的話，把細節從2.3裡抽出來放在這即可，再針對標準皮膚稿做些補充
這可以看得出:即便沒有換膚要求，也非常有必要按照這個思想去做，統一常用的class類，一方面已經實現了可換膚機制，另一方面，對我們後面的開發也大有好處。另外，怎麼換膚，哪些地方可不可以換膚，也需要我們從這裡整理出來跟設計師溝通

皮膚這塊補充一下，有幾個點（12.29補充）

1. 文字顏色一定要按照類別分類，比如預設文字色，預設連結色，次級文字色，次級連結色，如果有結構樣式的區別（比如左右色調完全不一樣）再分左右，形成畫筆的概念。總而言之，在這裡把畫筆準備好，後面就可以自由的發揮，畫筆也不宜太多，一般三到五種就可以了，html裡的寫法如下：

在這行代碼裡，後面兩個都是皮膚屬性，txtc是三級文字色，dot是小圓點……

2. 邊框、背景之類的細節，即便是在具體模組裡是用背景圖來實現的，也要在皮膚裡定義樣式，比如邊框，定義一個border-color: #cecfcf;就可以了，方便擴充。

3. 另外，皮膚不要用模組繼承的方式，這兒不是說不寫繼承，而是說不要把某個列表等具體的東西寫到skin檔案裡。具體可以直接參照一下這篇部落格的皮膚

http://simg.sinajs.cn/blog7tpl/13/13_19/t.css

這樣也有利於商業化或外公司協作開發

5.模組中樣式重疊的部分

整個common部分要注意下面幾個方面，所有在common裡引入的都應該在公用樣式預覽頁面中有所體現，方便同項目下的其他工程師參照。

 

整個產品或項目下，css的公用類，除第二點外，最好訂一個統一首碼

 

對於css引入的第二行

一方面不要太碎，另外根據模組的不同，結合設計稿之間的共性來定。這會有個矛盾，功能模組跟設計稿的共性不會完全貼切，比如一個細節可能出現在搜尋模組下，也可能出現在首頁模組下，這建議主要按照功能走，允許出現小範圍的冗餘，因為前面已經定下了，不同模組之間css是相對獨立的。至於重複較多的屬性，比如列表，就拿到common裡去，就是提到的第五點

最後引入的是皮膚

skin下一般定位一個css和一個images檔案夾，整體作為一個皮膚包，一定要有個皮膚包的概念，不要css檔案在css的skin下，圖片在images下的skin下

 

另外同產品下的不同皮膚之間，代碼要保證一致（除屬性具體定義值）防止個別皮膚單獨打補丁的情況，如果有新需求，一定要想這個有沒有可能以後存在類似的功能。比如春節模板下掛了一個鞭炮動畫，我們要想在全域裡做一個懸浮效果補丁加到皮膚裡，並形成規範約定，倒不是說要升級所有皮膚，意思是說兩個月後又一套商業皮膚掛一個氣球效果的時候，我們有據可循。

另外就是儘可能的拼合圖片
至於圖片檔案夾
首先檔案夾結構跟css要完全貼切，其次common中涉及到的圖片，建議按照公用元素，icon，皮膚基礎，和剛才說的第5點分類，最後另外考慮到緩衝機制，可能增加新圖片的時候要改名。壓縮拼合等技術細節問題就不在這說了

前面這些思想統一之後，作為builder，再遇到一個項目，就可以按照下面的步驟去做：

1.接到項目，溝通確定開發人員和方式，儘可能早的拿到設計雛形
2.根據項目的具體要求，按照上面提到的幾個原則做檔案夾部署，包括svn映射等類似的事情，跟開發組隨時溝通
3.拿到其中一個設計稿或設計標準後，做結構、公用、等細節，換句話說，要儘可能早的做完common裡面的前四項工作，明確css和images下的各個子檔案夾的規劃，並整理出一份完整的公用元素預覽頁面
4.根據不同的部分或模組做具體的頁面，儘可能的不同的人做不同的部分，牽頭人協調好common第五項的工作
如果不同的人做其中一部分的話，主css採用import的方式引入其他css
如果一個人做的話，做好自律
5.開發完畢後，配合工程師開發，這部分主要做培訓講解，讓後台工程師明晰我們的架構。並抽空整理開發文檔，特別是皮膚說明文檔，隨時供其他團隊或其他合作公司查看，如果對文檔的需求緊迫，這一步提前到第四步做。

關於皮膚說明文檔，有一點，就是儘可能的把所有換膚的元素整理到一個頁面裡，把其他無關樣式和模組刪除，打一個皮膚測試包提供給合作公司
6.配合上線，要做的事情，合并之前做的import css，控製版本，確定版本號碼等工作

最後總結到一張圖裡面

 

嗯，這樣做的話，事情就會明晰很多，不至於在開發中被前前後後的人呼來喚去。覺得有道理的話，下次按照這些辦法試試？