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

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

　　一旦選擇被細化到這一層面，我們就能在網路上找到大量相關文章、論壇以及示例，並藉此瞭解如何打造出更為出色的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標記的存在經常會帶來不必要的複雜性與載入負擔。

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

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

1. 問問自己：“頁面中所包含的所有圖片都是必要的嗎？”如果答案是否定的，那麼去掉那些不必要的影象。大家也可以點選此處對自己的網站進行掃描，從而獲取建議以瞭解哪些圖片可以進行壓縮。
2. 利用Shrink O’Matic或者RIOT這類工具來將自己的圖片尺寸控制在最低水平。
3. 採取圖片預載入方案。這雖然不會降低初始下載的具體成本，但卻能夠讓站點上其它使用相關圖片的頁面擁有更出色的載入速度。

　　另一種降低成本的方式則是壓縮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開發人員能夠消除很多曾經坑害過無數前輩們的陷阱。除了意識到這些陷阱的存在，我們還了解了這些錯誤的影響以及解決辦法，並據此設計出一套開發流程，從而在適合自身習慣的同時培養工作信心。同志們，加油！

　　原文標題：10 Common Web Developer Mistakes