前端過程中快速制作可通用的HTML頁面發布者：本站 時間：2020-05-16 08:05:40
速高效的制作通用的html'頁面。什么才是高效，是一個很難定出標準的事情，在今天這個浮躁的HTML行業里，很難被客觀的定義。多數時候，只要制作人員能在項目規定的時間內完成制作需求，并交付程序開發相關的程序應用，這個HTML前端工程師就算是一個合格的工作人員。而所謂高效，通過此環節所能看到的客觀指標就是，提前多少時間量完成任務。
然而，事實又是哪般呢？任務的細節開始變化了，客戶要求增加，設計不斷地挑戰人類（其實是前端工程師）的思維極限，整件事情就完全被打亂了。工程師會開始埋怨，客戶怎么那么多要求，設計怎么不按規范做沒得選擇，客戶確認了。加班開始了，不斷的增加Hack，不斷的對既有樣式進行大量的覆蓋、增加權重控制。任務恍恍惚惚的貌似進行下去了。
現實是殘酷，新的考驗又開始。樣式細節和設計偏離很大，以前做的頁面完全錯位了，腳本錯誤不斷，亂碼，為什么頁面竟然有個空白的行（BOM頭）。這些都不是最挑戰人類可承受能力的極限的，最最刺激的就是什么？修復這個問題你竟然要那么長的時間？這不是一個顯然易見的問題嗎？你們是不是在用CSS？
重構
最近公司的一個項目，其實已經完成了任務的70%吧，這個70%是表面上做出來的頁面的完成度。但是我發現在某一天以后，這個任務居然進度極端異常的緩慢。我感到詫異，因為已經允許不套入Wordpress制作皮膚，而直接制作一個只包含豐富JS特效的靜態站點。
進一步深入了解，發現兩個前端工程師，竟然在SVN上分了兩個目錄在進行這個項目，而且被告知最正式的版本，是測試服務器上的。
然后我嘗試了解，他們是如何進行分工合作的，雖然兩人沒有明確彼此進行指責，但是，彼此推諉有時候是比指責更嚴厲的態度。從他們對彼此的推諉，我發現，他們將各自擅長的領域（一個擅長制作頁面，一個擅長整理JS）作為他們彼此對立的一個矛盾點。具體的表現如，頁面的CSS制作出來以后，JS為了寫特效，又把頁面推翻了，制作自己引入了一些js，可是又沒有和大家做一個介紹和說明。我意識到，他們之間缺乏必要的溝通，也缺乏基本的信任，也許對于中國人（看國足和乒乓球的差異）對于團隊之間的信任，總是做的十分保守、有限。
我獲取了代碼，審視了他們的工作成果，我才真正的發現，問題已經遠不止于缺乏溝通和信任的問題了，而是浮躁。大家都急于將這個任務盡快的完成，于是采用的做法就是CSS和HTML，又一個頁面做一個頁面的樣式，JS有一個特效做一個特效。正如前言所言，誠然，這就是一個很顯然的高效做法。可是這里帶來了很多問題：
1、一個頁面一套CSS（一套相應的id和class命名），這種做法將來的維護成本會很高，因為他忽略了整個網站可被重用，代表這個網站的通用性特征，如果要對某個特征進行修改，可能需要對同一個位置的樣式進行多次重復的修改。
2、問題1往往會引伸出該問題，就是，在檢查制作結果的時候，往往那些在一個頁面制作達到要求的地方，為什么在第二個相似的設計結構的頁面會有差異？而且甚至存在這種差異第三種、第四種版本。這個問題，如果站在設計的角度，會是一個十分嚴重的問題。
3、每個頁面即興的寫一堆腳本，東一塊西一塊的，也許今天我為了項目的進度，可以認為這個特效是完成了的。但是他日真的套入到程序中，可能會讓程序員碰個一鼻子灰，因為程序員也許有耐心看你的代碼，但我多數時候愿意認為，他們不懂，就算他們懂，也沒有義務去幫你做些什么。結果往往是，比如A君負責寫JS，為此工作了3天，完成了，可是在程序開發的時候，發現不對勁，又要求A君來進行配合工作，開發進行了5天，A君陪了5天。為什么A君要在之后的5天內還要繼續參與呢？那么就是他前面的3天工作沒有完成了。當然，現實中，我們多數不會這樣去看待這個問題，而是盡量讓A君還是在后面的5天去參與進去，也不會有人去追究他前面3天究竟都做了哪些不合理的事情。而后由于后面5天人員參與數量增加，我們會希望壓縮項目的開發時間云云。
重構，即時重構，就以現在既有的這些代碼，其實我已經很早就放下心中的目標：一個完美代碼構成的網站，我需要他們每個人都明白，怎么樣能讓自己更加高效準確的工作。
抽象
對于前端制作，提抽象，可能有些過分，然而我這么多年來的經驗告訴自己，只有剝離了表面現象，才能洞察需求的實際。
我就不談那些有的沒有的空把式了，對于頁面制作和特效定制，一個最行之有效的抽象方式就是：不要急于動手實現，而是多看設計圖，找出：
1、排除設計元素差異（顏色、icon），找出頁面結構之間的共同特性，其中需要著重注意以下幾個特點：
*PSD是怎么做輔助線的，PSD輔助線是幫助你理解設計意圖的最佳切入點，有些設計會認真的做柵格輔助線，這種PSD基本上一上手，HTML要怎么寫，已經很明確。
*實際內容外寬度<->內部常見布局分布（左右比例，布局模式是左中右，還是上下通欄）
*正文內容默認字體，h1-h6的字體
*全局a標簽默認樣式，字體，顏色，hover style等
*form元素的樣式風格
2、排除設計細節的差異（文字大小、margin、padding、height、line-height等），找出可被重用的模塊（Box）模型，而這種模型，往往是以一個如下基礎模型為基礎的：
這種模型從功能上區分，往往有以下幾種：
*列表塊，列表頭為標題塊，列表為內容塊
*正文塊，正文標題為標題塊，正文為內容塊
*列表塊還可以細分，列表內容中每一個：內容標題為標題塊，描述內容為內容塊（摘要等）
這種模型，可以通過以下的特征來做出區分：
*所在的頁面，比如用于首頁每個欄目的最新內容的列表，還是某個欄目首頁的內容列表等
*出現在頁面的位置，比如Ajax彈出層，DropDown Menu，側邊欄，正文欄等
*用于什么用途、表現側重點是什么，比如博客列表頁，會提供內容摘要，便于用戶選擇閱讀，而門戶型網站內容列表，會僅僅顯示標題，因為信息量大，相冊的列表頁，總是會做得更加sexy，便于能吸引用戶的眼球等。
*和頁面其他部位的關聯，這個需要因應各個的設計的不同，就不具體舉例了。
3、排除實現的復雜度，找出特效展現的共同特性，并盡可能的想象其實現的一些細節。這部分工作是尤其重要的，因為他決定了一個頁面的工作重點所在，通過對這部分重點的細節想象，你會發現如下問題：
*現在有什么，還缺什么？
*合理程度，這是用戶體驗基礎，不合理的體驗，是不會被認可使用的
*用戶如何操作的，頁面的元素如何變化，既能做到驚嘆，而又在用戶的可理解可被認知范圍內，而后最大程度的緩沖系統與用戶之間的驚詫點
*合理性，合理性，合理性
當你確信，在找到上述3個問題的答案后，并且做出足夠的思考與預估后，我們可以開始動手制作了。
什么優先？什么其次？
優先要做的，永遠都是通用性、共用性方面的東西，他會伴隨在你整個制作過程中。當然，大多數公司，這種通用性存在共識，基礎的CSS、基礎的JS Framework。然而，對于項目和任務本身來說，你需要做更多這個項目自身的共用性的工作。其實說白了，就是上面的三個問題。
1、問題一所對應的
*body字體，顏色，背景色，背景圖，a標簽的通用樣式
*頁面布局模式，常用寬度定義等
*h1-h6的樣式控制
*input、select樣式
2、問題二所對應的
*制作多個和設計元素、設計細節無關的通用性的box模型（甚至不包括寬度的細節），僅僅描述一個模型的骨架性特征。
3、問題三對應的
*為需要實現特效的部位做足夠的兼容性準備。
問題1，往往不存在太多的問題，可是大家看看自己寫過的CSS，有多少句在頁面里定義了字體、字體大小、顏色的，這些部分的代碼也都是可以被再次抽象，而再減少對設計細節進行描述的。
問題2，是從根本上提高CSS編碼質量的一條解決之道。初步了解CSS特性的人，往往會患上重度描述的癥狀，他們寄望于通過編寫大量、甚至是成癮性的定義樣式特性，為求實現設計。確實，這種Hash結構讓我們了解到了描述的快感。然而，正式因為這種重度描述，令CSS文件的修改，成為一個令人頭疼的所在，密密麻麻的樣式聲明，不斷重復又重復的特性描述，整個樣式被定義的面目全非。
局部特征描述法，是一個很好的治療的模式，通過對僅有的若干個特征進行描述，而后進行組合使用，能讓我們的HTML和CSS獲得解放（代碼量），同時帶來更多的靈活性（我不再需要對權重過度緊張等）。
比如，一個box，相關的box_title，box_content，僅僅描述其結構（如內部關聯程度，如padding，margin等），寬度使用相關的樣式，如具體的w500（width:500px），或其使用用途的特征描述，如news_box（定義了具體的某幾個樣式）。于是我們會得到這樣的HTML結構：
01<div class="box news_box w500fl">02<div class="box_title">03<a href="#">新聞Box</a>04</div>05<div class="box_content">06<ul class="news_list">07<li><a href="#">新聞標題1</a></li>08<li><a href="#">新聞標題2</a></li>09<li><a href="#">新聞標題3</a></li>10</ul>11</div>12</div>很顯然，對于一個news_box，我們會有很具體的要求：
1.news_box.box_title{font-size:16px;font-weight:bold;}2.news_box.box_content{padding:5px;}3.news_list li{height:20px;line-height:20px;}4.news_list a{padding-left:10px;background:url(....)no-repeat top left;}這種定義方式，不會破壞box、box_title、box_content相關的結構性樣式特質，而通過基于news_box再次寫入到box_title和box_content的樣式，可以基于原來的樣式的基礎上，進行重用，對于專屬news_box的樣式，我們可以在這里重寫。
而后，也許我們還有pic_box，還有blog_box，還有很多很多，我們都不需要再對box的結構進行調整，而僅僅只要對每個box的本身的特征進行局部描述。
這已經有點類型面向對象開發的方式，但是我不同意把一個標簽的多個class認為是一次多重繼承，他頂多只能算是一種混入（Mix in），比如Scala中的trait。
局部描述還有更多實際使用中的案例，并且，他的技巧和好處遠不止于此，這里就不再累贅的進行描述了。
問題3，其實要強調的重點，是為開發JS特效預留更加寬松和自由的切入接口。JS特效的問題，會在另外的一篇日志去講，這里就不再做過多的描述了。
現狀
重構并不是要搞他個刀光劍影、暗無天日，而在于重新樹立一些正確的觀念苗頭。我并不預想著，事實上你也不可能期待，這樣一次重構，就能把每件事情做的真的和想象中那樣完美無缺。
預料之外的，是人對于工作的激情和熱誠。這些是無法從言談中獲取得到的，而對于寫代碼的人來說，也許代碼最能說明問題。
選擇我們，優質服務，不容錯過
1. 優秀的網絡資源，強大的網站優化技術，穩定的網站和速度保證
2. 15年上海網站建設經驗，優秀的技術和設計水平，更放心
3. 全程省心服務，不必擔心自己不懂網絡，更省心。
------------------------------------------------------------
24小時聯系電話：021-58370032