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

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

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

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

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

1. 編寫陳舊的HTML代碼

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

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

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

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

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

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

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

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

?    微軟Edge開發博客: 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

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

3. 注意調整格式

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

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

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

4. 反應速度太過緩慢

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

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

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

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

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

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

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

在結束第四點錯誤之前，我們還得提一句，請在HTML當中使用<style>或者<script>標簽之前做出準確的判斷（同第一點）。

5. 編寫出“應該能夠起效”的代碼

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

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

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

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

6. 編寫fork代碼

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

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

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

7. 采用非響應式設計

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

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

如何避免: 將響應式設計納入開發考量。在站點當中使用響應式設計，甚至以同樣的方式進行圖片尺寸調節，在這方面Bootstrap這款高人氣庫絕對能夠幫上各位大忙。

8. 構建毫無意義的頁面

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

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

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

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

錯誤: 創建的站點在每項操作當中包含太多頁面刷新步驟。

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

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

10. 工作強度太大

錯誤: 開發人員可能會投入太多時間來創建Web內容。這些時間可能被用于進行重復勞動，或者簡單地輸入大量文本內容。

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

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

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

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

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

總結陳詞

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