對于如何完成同一項任務(wù)，擺在我們面前的方案選項似乎無窮無盡，特別是在開發(fā)一套能夠運作在現(xiàn)代網(wǎng)絡(luò)環(huán)境之下的網(wǎng)站時。Web開發(fā)人員首先需要挑選一套Web托管平臺及底層數(shù)據(jù)存儲機制，并利用由提供的工具編寫HTML、CSS以及JavaScript代碼，考慮如何實現(xiàn)設(shè)計效果以及哪些潛在JavaScript庫/框架可能會被包含于其中。

一旦選擇被細(xì)化到這一層面，我們就能在網(wǎng)絡(luò)上找到大量相關(guān)文章、論壇以及示例，并借此了解如何打造出更為出色的Web使用體驗。然而無論有多少條道路可供選擇，開發(fā)人員都有可能在自己的選項當(dāng)中迷失方向。雖然其中有些錯誤與特定方案相關(guān)，但也有一些共同的挑戰(zhàn)橫亙在每一位Web開發(fā)人員面前。

Web開發(fā)人員最易犯下的十種常見錯誤

因此通過一系列研究、經(jīng)驗與近期觀察，我整理出了下面這份十大常見錯誤清單——目前確實有很多Web開發(fā)人員還在飽受其困擾，而我也給出了自己的解決意見。

以下這份清單不分先后順序。

1. 編寫陳舊的HTML代碼

錯誤: 互聯(lián)網(wǎng)在發(fā)展早期只提供有限的幾種標(biāo)記選項，而如今這類選項已經(jīng)變得相當(dāng)豐富。然而某些陳舊的陋習(xí)當(dāng)下仍然存在，而且很多從業(yè)者在編寫HTML代碼時好像仍然活在上個世紀(jì)。具體實例包括使用<table>元素進(jìn)行布局、在更適合使用其它語義標(biāo)簽時繼續(xù)使用<span>或者<div>元素，還有使用諸如<center>或者<font>等不支持當(dāng)前HTML標(biāo)準(zhǔn)的標(biāo)簽，甚至利用大量&nbsp;將條目排布在頁面當(dāng)中。

影響: 編寫上述帶有濃郁上世紀(jì)風(fēng)格的HTML代碼可能導(dǎo)致標(biāo)記復(fù)雜程度過高，進(jìn)而在不同瀏覽器中出現(xiàn)彼此相異的運行效果。此外，我們也沒有任何理由在微軟Edge甚至是IE新版本（包括IE 9、10與11）當(dāng)中使用此類復(fù)雜的標(biāo)記方式。

如何避免: 不要再使用<table>元素處理內(nèi)容布局了，另外嚴(yán)格限制其在顯示表格數(shù)據(jù)時的使用頻率。充分了解當(dāng)前有哪些標(biāo)記選項可供使用，具體可以點擊此處查看whatwg.org中的匯總。使用HTML代碼來描述頁面內(nèi)容，而非定義內(nèi)容的顯示方式。要正確顯示設(shè)計內(nèi)容，請優(yōu)先使用CSS。

2. “在我的瀏覽器中明明沒有問題……”

錯誤: 開發(fā)人員可能會偏愛某款特定瀏覽器或者極度鄙視另一款瀏覽器，而且會將這種帶有偏見的觀點帶入網(wǎng)頁測試工作當(dāng)中。在某些情況下，我們甚至有可能將來自網(wǎng)絡(luò)的示例代碼直接納入到項目當(dāng)中，而并沒有測試其能夠在其它瀏覽器中正確得以渲染。再有，某些瀏覽器會在樣式方面擁有不同的默認(rèn)值設(shè)定。

影響: 編寫一個只適用于特定瀏覽器的站點很可能會給使用其它瀏覽器的用戶帶來非常糟糕的訪問體驗。

如何避免: 在開發(fā)過程中針對每一款瀏覽器及其版本進(jìn)行網(wǎng)頁測試顯然是不現(xiàn)實的。不過我們可以每隔特定一段時間就利用多種瀏覽器來檢查自己的網(wǎng)站是否能夠正常運作，這算是種比較理想的折衷辦法。目前無論大家使用哪種首選開發(fā)平臺，都有大量免費工具可以幫助各位實現(xiàn)測試工作，具體包括免費虛擬機或者站點掃描工具。Browsershots或者BrowserStack等網(wǎng)站還能夠提供快照，幫助我們了解特定頁面在不同瀏覽器/版本/平臺上擁有怎樣的渲染效果。而Visual Studio等工具也能夠利用不同瀏覽器顯示我們目前正在開發(fā)的單一頁面。當(dāng)利用CSS進(jìn)行設(shè)計時，請記得對所有默認(rèn)值進(jìn)行“重新設(shè)定”。

如果大家的站點使用了任何面向單一瀏覽器所創(chuàng)建的特殊CSS功能，那么請留心處理各類提供程序前綴，包括-webkit-、moz-或者-ms-。作為行業(yè)趨勢指南，我建議大家認(rèn)真查閱下面提供的各參考站點（皆為英文原文）：

?    微軟Edge開發(fā)博客: A break from the past, part 2: Saying goodbye to ActiveX, VBScript, attachEvent…

?    QuirksMode.org: CSS vendor prefixes considered harmful

?    Bruce Lawson: On Internet Explorer supporting -webkit- vendor prefixes

雖然以上參考資料已經(jīng)解釋了我們該如何避免提供程序前綴及其相關(guān)理由，但大家也可以點擊此處通過具體建議了解更多解決辦法（英文原文）。

3. 注意調(diào)整格式

錯誤: 通過提示的方式向用戶索取信息（特別是以輸入文本字段的方式），并單純假設(shè)該數(shù)據(jù)能夠如預(yù)期般從用戶處獲得。

影響: 在默認(rèn)信任用戶輸入信息時，我們有可能面臨大量意料之外的麻煩。如果所要求的數(shù)據(jù)未能被正確獲得，或者所獲得的數(shù)據(jù)與底層數(shù)據(jù)格式不兼容，那么頁面很可能發(fā)生錯誤。更為嚴(yán)重的是，某些針對網(wǎng)站數(shù)據(jù)庫的故意違反行為甚至足以構(gòu)成注入式攻擊。

如何避免:第一條建議就是要確保用戶能夠清晰地了解到網(wǎng)站要求其輸入哪種數(shù)據(jù)類型。就目前而言，單純給出“請輸入地址”的提示可能代表著用戶需要輸入公司地址、家庭住址甚至是電子郵箱地址！除了作出針對性說明之外，我們還應(yīng)當(dāng)充分發(fā)揮現(xiàn)代HTML當(dāng)中所提供的數(shù)據(jù)有效性驗證技術(shù)。無論數(shù)據(jù)在瀏覽器端是否被視為有效，我們務(wù)必要在服務(wù)器端同樣對其進(jìn)行驗證。永遠(yuǎn)不要在未確認(rèn)字段內(nèi)容符合數(shù)據(jù)類型要求的情況下，允許用戶所輸入的多行索引T-SQL語句使用站點數(shù)據(jù)。

4. 反應(yīng)速度太過緩慢

錯誤: 對于包含有大量高品質(zhì)圖像以及/或者圖片的頁面，我們應(yīng)當(dāng)利用<img>元素對其高度及寬度屬性進(jìn)行調(diào)整。而來自頁面中的CSS以及JavaScript等文件鏈接往往也體積龐大。另外，源HTML標(biāo)記的存在經(jīng)常會帶來不必要的復(fù)雜性與加載負(fù)擔(dān)。

影響: 如何某個頁面的完全渲染時間過長，那么一部分用戶可能會放棄訪問甚至不耐煩地重新加載整個頁面。在某些情況下，如果頁面的處理時耗太長，甚至可能引發(fā)其它未知錯誤。

如何避免: 不要以為互聯(lián)網(wǎng)的傳輸速度越來越快就可以毫無顧忌地設(shè)計出臃腫的頁面成果。相反，將往返于瀏覽器與站點之間的每一點流量都視為運營成本。圖片可以說是頁面臃腫問題的罪魁禍?zhǔn)?，因此為了最大限度降低圖片給頁面帶來的加載成本，請從以下三個角度進(jìn)行考量：

問問自己：“頁面中所包含的所有圖片都是必要的嗎？”如果答案是否定的，那么去掉那些不必要的圖像。大家也可以點擊此處對自己的網(wǎng)站進(jìn)行掃描，從而獲取建議以了解哪些圖片可以進(jìn)行壓縮。

利用Shrink O’Matic或者RIOT這類工具來將自己的圖片尺寸控制在最低水平。

采取圖片預(yù)加載方案。這雖然不會降低初始下載的具體成本，但卻能夠讓站點上其它使用相關(guān)圖片的頁面擁有更出色的載入速度。

另一種降低成本的方式則是壓縮CSS與JavaScript鏈接文件的體積。目前我們可以選擇大量工具來幫助自己完成這項評估工作，其中包括Minify CSS以及Minify JS。

在結(jié)束第四點錯誤之前，我們還得提一句，請在HTML當(dāng)中使用<style>或者<script>標(biāo)簽之前做出準(zhǔn)確的判斷（同第一點）。

5. 編寫出“應(yīng)該能夠起效”的代碼

錯誤: 無論是JavaScript還是運行在服務(wù)器端的代碼，作為開發(fā)人員我們都應(yīng)當(dāng)通過測試來驗證其實際運行效果，從而保證其一定能夠在部署之后發(fā)揮預(yù)期作用。大家的代碼在執(zhí)行時不應(yīng)引發(fā)任何錯誤，因為在此之前我們已經(jīng)對其進(jìn)行了充分測試。

影響: 包含未經(jīng)測試代碼的站點很可能以極其糟糕的方式在供最終用戶使用時產(chǎn)生各類錯誤。這不僅會嚴(yán)重影響到用戶的實際感受，同時錯誤信息內(nèi)容的具體類型也可能會向打算入侵站點的黑客透露那些本該受到嚴(yán)格保護(hù)的細(xì)節(jié)線索。

如何避免: 人是不可避免會犯錯的，因此我們應(yīng)當(dāng)將這種哲學(xué)思維帶入編程工作。在JavaScript當(dāng)中，我們應(yīng)當(dāng)確保利用一切最佳技術(shù)手段來避免錯誤的發(fā)生，并在其實際出現(xiàn)后及時捕捉。另外一種有助于提高代碼質(zhì)量的辦法就是針對未來可能出現(xiàn)的變更對代碼進(jìn)行單元測試。

服務(wù)器端的代碼錯誤必須要在用戶尚未察覺時即被發(fā)現(xiàn)并加以修復(fù)。只向用戶顯示必要的錯誤提示，而且請大家再用點心，把自己的HTTP 404錯誤頁面設(shè)計得漂亮一點。

6. 編寫fork代碼

錯誤:出于支持所有瀏覽器及其各個版本的崇高理念，某些開發(fā)人員會創(chuàng)建不同的代碼來對應(yīng)每一種可能的運行場景。這些代碼以if語句循環(huán)為基礎(chǔ)，并針對各類實際方向提供對應(yīng)的fork版本。

影響: 隨著瀏覽器版本的不斷更新，對fork代碼文件的管理將變得非常復(fù)雜甚至無法實現(xiàn)。另外正如第一點中所言，這樣做其實完全沒有必要。

如何避免: 在代碼內(nèi)部進(jìn)行功能檢測，而非針對瀏覽器/版本著手。功能檢測技術(shù)方案的出現(xiàn)顯著降低了代碼數(shù)量，而且也保證了代碼更易于閱讀并管理。大家可以考慮利用Modernizr等庫來幫助自己在實現(xiàn)功能檢測的同時，以自動化方式為那些已經(jīng)無法適應(yīng)HTML 5或者CSS 3的陳舊瀏覽器提供后備支持。

7. 采用非響應(yīng)式設(shè)計

錯誤: 在進(jìn)行站點開發(fā)工作時，假設(shè)用戶擁有與開發(fā)人員/設(shè)計師相等同的顯示器尺寸。

影響: 當(dāng)在移動設(shè)備或者某些超大型屏幕上查看站點時，用戶體驗也會因此受到影響——例如無法查看到頁面中的某些重要方面，甚至無法導(dǎo)航至其它頁面。

如何避免: 將響應(yīng)式設(shè)計納入開發(fā)考量。在站點當(dāng)中使用響應(yīng)式設(shè)計，甚至以同樣的方式進(jìn)行圖片尺寸調(diào)節(jié)，在這方面Bootstrap這款高人氣庫絕對能夠幫上各位大忙。

8. 構(gòu)建毫無意義的頁面

錯誤: 在面向公眾的頁面當(dāng)中包含有實用性內(nèi)容及信息，但不提供任何與搜索引擎相關(guān)的關(guān)鍵字、標(biāo)簽及提示。不提供無障礙訪問功能。

影響: 在這種情況下，用戶將很難通過搜索引擎找到我們的頁面，這將導(dǎo)致其難以甚至根本無法獲得理想的訪問量。另外頁面內(nèi)容需要經(jīng)過精心設(shè)計，以保證不會在用戶查看過程中操作其視力。

如何避免: 使用SEO（即搜索引擎優(yōu)化）機制并支持HTML訪問性。在SEO方面，請確保添加標(biāo)簽以提供包含關(guān)鍵字及相關(guān)描述的有意義頁面內(nèi)容。要實現(xiàn)更出色的可訪問體驗，大家可以檢查每一條<img>或者<area>標(biāo)簽之下的alt="your image description"屬性。當(dāng)然，單純做到這些還遠(yuǎn)遠(yuǎn)不夠，大家可以點擊此處訪問了解頁面是否與Section 508相兼容。

9. 開發(fā)出的頁面中包含太多刷新操作

錯誤: 創(chuàng)建的站點在每項操作當(dāng)中包含太多頁面刷新步驟。

影響: 與臃腫頁面類似（見第四點），頁面加載時間這一重要性能指標(biāo)也會因此受到影響。如果刷新過多，用戶體驗將缺乏流暢性，而每次內(nèi)容更新都可能造成頁面的短時（或者長時）重置。

如何避免: 解決這一問題的便捷方式之一在于檢查各項操作是否真有必要與服務(wù)器端取得聯(lián)系。舉例來說，如果無需依賴服務(wù)器端資源進(jìn)行處理，那么我們可以利用客戶端自身的腳本提供即時性結(jié)果。當(dāng)然，大家也可以使用AJAX技術(shù)或者更進(jìn)一步，選擇單頁面應(yīng)用SPA方案。目前各類高人氣JavaScript庫/框架都提供眾多能夠簡化這方面難題的辦法，例如JQuery、KnockoutJS以及AngularJS。

10. 工作強度太大

錯誤: 開發(fā)人員可能會投入太多時間來創(chuàng)建Web內(nèi)容。這些時間可能被用于進(jìn)行重復(fù)勞動，或者簡單地輸入大量文本內(nèi)容。

影響: 在網(wǎng)站剛剛上線或者進(jìn)行后續(xù)更新時，開發(fā)人員投入其中的時間往往太過夸張。而當(dāng)有其他開發(fā)者能夠用更短時間及更少精力實現(xiàn)同樣的效果時，我們投入的時間成本將得不到理想的回報。這種簡單重復(fù)的體力勞動會導(dǎo)致錯誤的出現(xiàn)，而診斷錯誤往往比開發(fā)項目更耗費時間。

如何避免: 自行尋找解決辦法。我們可以考慮使用新型工具或者新的工作流程技術(shù)來搞定開發(fā)中的每個階段。舉例來說，大家當(dāng)前正在使用的代碼編輯器與Sublime Text或者Visual Studio相比孰優(yōu)孰劣？無論大家所使用的是哪一款代碼編輯器，您有沒有深入挖掘過其中的功能設(shè)定？也許只需要花點零散時間認(rèn)真閱讀說明文檔，我們就能找到足以在未來幫自己節(jié)約下數(shù)小時甚至更長時間的新用法。

另外不要錯過互聯(lián)網(wǎng)上任何可能幫得上忙的現(xiàn)成工具！舉例來說，在dev.modern.ie網(wǎng)站上搜索那些能夠簡化測試（涵蓋多種平臺及設(shè)備）及故障排查工作的工具。

大家也可以通過自動化流程降低時間要求與出錯機率。例如，我們可以使用Grunt等工具來自動完成文件體積壓縮等任務(wù)。另外，Bower則可以幫助大家更為高效地管理庫與框架。

那么Web服務(wù)器本身又存不存在優(yōu)化空間？我們可以選擇微軟Azure Web Apps，并借此快速創(chuàng)建出一個幾乎適用于任何開發(fā)場景的站點，這對于擴(kuò)展業(yè)務(wù)絕對可算理想方案！

總結(jié)陳詞

通過列舉以上常見錯誤，Web開發(fā)人員能夠消除很多曾經(jīng)坑害過無數(shù)前輩們的陷阱。除了意識到這些陷阱的存在，我們還了解了這些錯誤的影響以及解決辦法，并據(jù)此設(shè)計出一套開發(fā)流程，從而在適合自身習(xí)慣的同時培養(yǎng)工作信心。