2014-10-30 藍藍設計的小編
但凡從事互聯(lián)網(wǎng)的人基本都會寫幾行 html，用過 Word 的人用 Dreamweaver 也能做出規(guī)整的頁面，所以大部分人會很自然地認為“頁面的開發(fā)沒什么技術(shù)含量，很簡單”。不僅有這種普遍的認知，對從業(yè)者來說也有很多疑惑：做頁面前端實現(xiàn)，沒問題；兼容性，小 case；圖片集成，一直都在用……還能有什么問題？瓶頸啊、天花板啊、轉(zhuǎn)型啊、出路啊就在從業(yè)者中廣泛討論。是不是真的沒什么問題了呢？網(wǎng)易郵箱前端技術(shù)中心也設立好幾年了，似乎有著討論不完的話題，也經(jīng)常會有一些新的想法讓大家為之一振。那么頁面開發(fā)還有哪些要求，還要做些什么，這里面的水有多深，讓我們舀舀看。
在不同的時期對頁面前端的看法似乎是多變的。在互聯(lián)網(wǎng)早期的時候，小車還是比房子貴的，燒餅和粉絲還只是用來吃的，菊花還只是用來泡茶的。那時的頁面設計風格相對單一，對應的頁面需求比較簡單，并且當時的瀏覽器也基本是 IE6 的天下，javascript 也只是網(wǎng)頁的代名詞，HTML 頁面本身沒有引起太多人的關(guān)注，似乎只要能用 div 甚至 table 加 css 輔助把圖片定好位，把頁面內(nèi)容預留好就 OK 了，并且這種觀念存在了很長一段時間。隨著頁面內(nèi)容的豐富，設計風格的發(fā)展，交互復雜性的增加，AJAX 的應用，瀏覽器的更新?lián)Q代，又讓大家重新對最基本的頁面本身重視起來。然后熱議的就是瀏覽器的兼容性，碰到問題最熱衷的就是滿網(wǎng)絡搜索 hack，順便再罵罵 IE6、7……當這些都做一遍后，似乎又遇到了瓶頸，又開始尋找出路。我們就從這個階段開始說起。
把視覺稿通過頁面代碼的方式表現(xiàn)出來包含了兩個基本訴求：1.能夠真實反映視覺稿；2.能夠通過瀏覽器的兼容。這兩個訴求的達成需要我們有追求細節(jié)的態(tài)度和一定的頁面功底，能完成這兩個內(nèi)容就可以初步進入頁面前端的從業(yè)者行列了，但這就代表著我們可以勝任頁面開發(fā)的工作了？不，才剛剛開始！
溝通很重要。先拋出幾個問題：我們有沒有和設計師探討過某些效果對低端瀏覽器渲染效率影響比較大？有沒有探討過部分效果可以用 CSS3 實現(xiàn)從而使得結(jié)構(gòu)更加簡潔清晰？有沒有在代碼和視覺中尋追求過平衡？頁面前端的開發(fā)向基本用戶，編寫的代碼也直接作用在瀏覽器上，我們有義務對頁面的穩(wěn)定性和渲染效率負責。我們也經(jīng)常碰到項目在總體進度壓力下導致的設計與頁面前端開發(fā)同步進行，這時更有必要盡量多地獲取項目信息，了解我們還要做些什么，這些可以幫助我們充分考慮重用和框架拓展。
頁面結(jié)構(gòu)的編寫好比蓋房的地基建設，其好壞會直接影響到 CSS 代碼的質(zhì)量、js 開發(fā)、后臺開發(fā)還會影響到以后的頁面拓展、迭代和頁面調(diào)整。拿到視覺稿后，不要忙著動手開始，多觀察思考。先分析布局，劃分框架，然后規(guī)劃結(jié)構(gòu)，編寫代碼。特別在大型項目中，合理使用模塊化的開發(fā)不論從整體進行還是拓展維護都有相當大的好處。
很多同學在頁面開發(fā)時上網(wǎng)搜索最多的就是 hack 了，是否我們完全要依賴 hack 來實現(xiàn)頁面兼容性，答案是否定的。大家經(jīng)常比喻 IE6 向我們?nèi)隽艘粋€謊，結(jié)果我們要再撒一百個謊來圓這個謊。不否認 IE6 經(jīng)常讓我們口吐鮮血，但不代表我們用更多的“謊言”來彌補就可以心安理得。大部分情況下可以通過變換思路調(diào)整 HTML 結(jié)構(gòu)，或使用一些雖然無法解釋但相對安全的 css 來干掉 hack。誰都無法預計使用 hack 什么時候會讓我們栽一個大跟頭。比如觸發(fā) layout 或 position:relative 就可以幫助解決很多 IE6 的問題。
現(xiàn)在很多 web 項目功能復雜，代碼規(guī)模也會變得很龐大，如何更好地進行協(xié)同開發(fā)和維護是我們面臨的一個問題。需要考慮完善統(tǒng)一的規(guī)劃，還有要養(yǎng)成良好的代碼開發(fā)習慣才會在面臨各種情況時游刃有余。翻閱頁面代碼，看到合理的標簽使用、良好的注釋、清晰的代碼結(jié)構(gòu)、用意準確的 css 不僅猶如欣賞一個藝術(shù)品，更為下游開發(fā)和協(xié)同開發(fā)降低了不小的溝通成本，我們有什么理由不去這么做呢？舉個反面例子：div 濫用是現(xiàn)在比較典型的一個問題。數(shù)數(shù)看自己使用的標簽有多少個呢？不同的語義都該使用對應的標簽代碼，特別是 HTML5 提供了更豐富的語義化標簽，它們都苦苦地在等待戰(zhàn)場上的沖鋒號，讓我們?nèi)ソ夥潘鼈儼桑?/p>
可訪問性與易用性是非常主觀且人性化的東西。普通人看上去上完美呈現(xiàn)的頁面在特殊群體中不一定顯得那么貼心。當盲人用讀屏軟件在頁面某個區(qū)域內(nèi)陷入循環(huán)時，我們應該感到內(nèi)疚。只能說目前國內(nèi)的網(wǎng)站對此的重視程度還遠遠不夠，這就需要我們共同努力，讓更多的人感受到我們的熱情。
作為項目開發(fā)中比較靠前的一環(huán)，頁面開發(fā)可能需要盡早完成為項目爭取時間，這就需要我們盡可能地提率。“工欲善其事，必先利其器”，除了實戰(zhàn)經(jīng)驗和代碼習慣的形成可以幫助我們提率外，想要提高對自己開發(fā)的進度掌控能力，還有很多輔助工具可以幫助我們進行頁面開發(fā)。比如使用 Less 或 Sass 可以幫助我們拓展和組織 CSS，大大提高 CSS 的編寫效率增加了可維護性。比如可以通過 zen coding 的自動自動完成和自定義代碼塊讓你可以劍指如飛。甚至還見過通過自定義輸入法的代碼塊關(guān)鍵字來提升開發(fā)速度的。多多發(fā)掘一定會找到最合適自己使用的工具。
頁面開發(fā)也需要了解服務器的優(yōu)化，盡量減小服務器負擔。比如 css sprite 就是一個典型減小服務器請求數(shù)的例子。在網(wǎng)易郵箱的頁面前端開發(fā)中大家不停地在做著各種優(yōu)化，比如一直在尋求文件大小與服務器請求數(shù)的平衡；為了盡可能提高緩存利用率采用了補丁升級；對 class 名進行了混淆壓縮避免命名過長的冗余；應用 base64 減少請求數(shù)量等等措施。這些都是綜合權(quán)衡的結(jié)果，需要考慮各個方面整體優(yōu)化。因為當頁面訪問量達到一定的數(shù)量級時，再小的一點優(yōu)化都會達到可觀的效果，再小的問題都可能會形成巨大的災難。
這是一個充滿機會的時代，HTML5時代的來臨伴隨著移動互聯(lián)網(wǎng)的興起創(chuàng)造了更大的機會，還有太多的東西值得我們?nèi)W習去發(fā)現(xiàn)。 HTML5 提供了豐富的 JS API 接口，需要我們?nèi)パ芯浚籆SS3的絢麗吸引了足夠多的眼球，需要我們?nèi)パ芯浚灰苿釉O備上如何開發(fā)更加適配的頁面，需要我們?nèi)パ芯俊?/p>
水是越舀越多了，卻發(fā)現(xiàn)原來下面還深不見底，上面的內(nèi)容越是深入研究就越會發(fā)現(xiàn)更多山川需要翻越。保持饑餓狀態(tài)，用眼睛去努力發(fā)現(xiàn)發(fā)掘，不斷豐富技能才能找到定位，突破瓶頸，正所謂“唯有高屋建瓴方可水到渠成”。形成本文是因為之前和同行討論到瓶頸的問題，想給自己，給頁面前端的同學一起找找定位，梳理一下思路。拿蘋果 CEO 在斯坦福演講的一句話“Stay Hungry， Stay Foolish”和大家共勉。