10 大常見的web開發錯誤

　　自從1990年有了www網際網路這個概念後，web應用程式經歷了從提供靜態HTML頁面到完全動態的複雜的業務應用的改變。

　　今天我們有各種各樣的電子資源或圖書來告訴我們如何開發各種各樣的應用程式。現在的開發環境也足夠智慧，可以幫我們發現並修復很多錯誤。甚至有很多不同的開發平臺提供方便的將靜態頁面轉換為高度可互動的應用的功能。

　　所有的這些開發模式、時間和平臺都有共同點，並且容易犯相似的錯誤因為web應用的本質。

　　本文意在揭示一些在Web開發過程的不同階段作出的常見錯誤，並幫你減少這些錯誤。我涉及了一些幾乎所有的web開發者都熟悉的話題，想驗證、安全、擴充套件性和SEO等。當然你不應該被我所描述的具體情況限制住，列出這些只是為了在你遇到潛在的問題的時候有一些啟發。

　常見錯誤 #1: 不完整的輸入驗證

　　客戶端和伺服器端的使用者輸入驗證是一個簡單但是必須要做的！。我們都知道“不要相信使用者的輸入”這句真理，但是源於驗證的錯誤還是頻繁發生。

　　驗證錯誤的最常發生的結果就是 SQL Injection ，這是OWASP Top 10 中的一個。

　　一定要記住大多數的前端開發框架提供的擠開即用的驗證規則都太簡單。而且，大多數的後端開發平臺都使用簡單的註解來確保提交的資料是規則期望的。實現驗證可能比較費時，但是這應該是你的編碼習慣的一部分，而不應該放在一邊不管。

　常見錯誤 #2: 認證沒有合適的授權

　　在我們繼續之前，請確保達成兩個概念的意志。這是 10 Most Common Web Security Vulnerabilities 所說的:

　　Authentication（認證）:校驗一個人（或至少看起來）是某個使用者，在他正確地提供哦你了他的安全證照後（密碼，安全問題，指紋掃描等）

　　Authorization（授權）:確認某個使用者是否有權獲取某個資源，或執行某個行為。

　　用另一種方式說，認證是知道這個人是誰，授權是知道這個人能做什麼。

　　讓我們用一個例子來闡述這個錯誤。

　　想想看，你的瀏覽器擁有一個已登入的使用者的資訊，大概是這樣的一個物件

{    username:'elvis',
    role:'singer',
    token:'123456789'}

　　當做一個更換密碼的操作時，你的應用接到post請求

POST /changepassword/:username/:newpassword

　　在你的/changepassword方法, 你檢驗到這個使用者已經登入了並且  token沒有過期. 然後用username引數找到這個使用者的資訊, 並改變使用者的密碼。

　　那麼，你驗證了這個使用者是已經登入的，然後你執行力他的請求也就是改變了他的密碼。看來進展正確，對嗎？不幸的是，並不是這樣的。

　　關鍵點是校驗改變執行這個操作的使用者和要改變的密碼的使用者同一個。瀏覽器上儲存的任何資訊都可以被篡改，並且任何一個高階點的使用者只適用瀏覽器自帶的工具都可以輕易地把username:'elveis'改成username:’Administrator'.Administrator'.

　　在這種情況下，我們僅僅關心了認證。我們甚至可以把/changepassword方法改成只有認證的使用者才能執行。但是，這還不能在很多惡毒的請求面前保護你的使用者們。

　　你需要在你的 /changepassword 方法裡驗證實際的請求者和請求的內容，並且實現使用者只能修改他自己的資料這樣的授權。

　　認證和授權是同一枚硬幣的兩面，永遠不要把他們分開對待。

　常見錯誤#3: 沒有準備好擴充套件

　　現在的世界主流是快速發展高速啟動的,並且偉大的想法迅速覆蓋全球, 將 MVP (最小可行產品)儘快推出到市場上是很多公司的共同目標

　　然而, 時間壓力導致開發團隊經常忽略了某些問題. 擴充套件性是團隊們理應考慮到的。 MVP的概念很偉大, 但是不久之後,你會遇到一系列的問題. 不幸的是, 選擇可擴充套件的資料庫和web伺服器並把不同的應用層放到獨立的可擴充套件的伺服器上還不夠. 你還有很多需要考慮的細節來避免在以後大改自己的應用。

　　例如，假設你選擇直接在web伺服器上儲存使用者的上傳照片。這是一個完美的可行的方案--應用可以快速的獲取到這些檔案，在每個開發平臺都有處理檔案的方法，並且你都可以把這些圖片以靜態內容的方式提供，這意味這著應用程式的最小負載。

　　但是當你的應用規模變大，你需要兩個或更多的負載均衡器的web伺服器的時候呢？即使你漂亮的擴充套件了你的資料庫儲存，session狀態伺服器和web伺服器，你的應用還是因為資料圖片這樣的小事擴充套件失敗了。這樣，你需要實現多種檔案同步服務（這樣會有延遲並且會造成短暫的404錯誤）或其他的解決方法來確保這些檔案能在你的web伺服器間蔓延。

　　為避免這樣的問題，你需要做的就是在一開始就使用共享的檔案儲存位置，資料庫或其他任何的遠端儲存解決方案。這些可能會花費一些額外的工作時間，但是和以後可能會遇到的麻煩比起來還是值得的

　常見錯誤 #4: 錯誤SEO的或沒有 SEO

　　web站點沒有或者錯誤的搜尋引擎優化的根本原因是"SEO專家"的誤導。許多web開發者認為自己足夠了解SEO並且認為它沒有那麼複雜，但事情並不是這樣的。 掌握SEO 需要大量的時間來尋找最佳實踐以及Google、Bing、雅虎等如何索引web的千變萬化的規則一 除非你不停的實驗並且準確地跟蹤+分析, 你都不是一位SEO專家, 你也不應該說自己是.

　　此外,SEO經常被推遲到最後才做。這需要很大的代價. SEO不僅僅是關於設定良好的內容、標籤、關鍵字、 meta-data,、影像的 alt 標籤,、site map等等. 它還包括消除重複的內容、擁有可抓取的網站架構、高效的載入時間、智慧的反向連結等等。

　　就像擴充套件性一樣，你應該在開始構建web應用程式的時候就考慮到SEO，不然你可能會發現完成SEO實現工程意味著重寫整個系統。

　常見錯誤 #5: 請求處理中的耗時動作

　　這個錯誤的最好的例子就是一個基礎使用者的動作傳送郵件。開發者們經常認為在使用者請求處理器上構造一個SMTP請求併傳送一條郵件訊息就可以了。

　　假設你建立了一個網上書店並且你期望每天要處理數百個訂單。 作為你的訂單處理的一部分, 每個使用者提交訂單post請求後你回去傳送一封確認郵件。 最開始的時候可能沒有問題，但是當你的系統級別變大，你突然收到數千個傳送確認郵件的請求呢？ 你就會遇到SMTP連線超時、郵件配額不足、 or your application response time 或者你的應用程式因為要處理郵件而不是使用者請求導致響應時間顯著提升。

　　任何費時的動作都應該用另外一個執行緒來處理，從而儘快地釋放掉http請求。這種情況下，你因該有一個外部的郵件服務來接收訂單併傳送通知。

　常見錯誤 #6: 沒有優化頻寬使用

　　大多數的開發和測試都是在本地網路環境下進行的。所以當你下載5個3MB大小的背景圖片的時候，以你的1Gbit的開發環境連線可能不會有問題。但是當你的使用者在他們的手機上用3G網開始載入你的15MB的首頁的時候, 你就應該為自己準備一個投訴郵件列表了。

　　優化網路頻寬使用可以帶來極大的效能提升，並且你可能是需要一些小技巧來實現這樣的提升。這有一些規範的團隊預設做的事情，包括:

1. 縮小所有的JavaScript

2. 縮小所有的CSS

3. 壓縮伺服器端的HTTP

4. 圖片尺寸和解析度的優化

　常見錯誤 #7: 沒有為不同大小的螢幕開發

　　自適應設計一直是近幾年的一個大話題。帶有不同大小的螢幕的智慧手機的急劇增多帶來了很多新的獲取網上內容的方式。通過只能手機和平板電腦訪問web的數量每天都在增加，並且這種趨勢還在加速。

　　為了確保無縫的導航和瀏覽，你必須使使用者能夠用各種各樣的裝置來訪問網站。

　　關於自適應web應用設計有很多模式和實踐。各種開發平臺都有自己的提示和技巧。但是也有一些開發框架是跨平臺的。其中最有名的可能是 Twitter Bootstrap. 它是一個開源的 HTML, CSS, 和JavaScript框架,並且已經被各種各樣的開發平臺接納。 在構造應用的時候只需要採用Bootstrap模式, 你就可以不費力的獲得自響應web應用程式。

　常見錯誤 #8: 跨瀏覽器不相容

　　大多數情況下，開發過程都是在巨大的時間壓力下進行的。每個應用都需要儘早地釋出，開發者常常關注於交付功能而不是設計。儘管大多數的開發者都安裝了 Chrome，Firefox 和 IE，但是他們90%的時間只使用其中的一個。一個常見的例子就是在一個瀏覽器下開發並且只在應用快完成的時候用其他的瀏覽器來測試。這樣十分有道理–假如你有很多時間來測試並修改這個階段出現的問題的話。

　　然而，當你的應用到達跨瀏覽器測試階段的時候還是有一些技巧來幫你顯著地節省時間的:

1. 在開發的時候不需要在所有的瀏覽器下測試，這很費時間並且低效. 但是這不是說你就可以不經常切換瀏覽器了.每隔幾天換一個瀏覽器, 在測試階段之前你至少可以發現最主要的那些錯誤。

2. 不要用統計資料來為不支援某個瀏覽器辯解。有很多組織採納新軟體或升級很慢。可能有大量在那工作的使用者要訪問你的網站，但是他們因為內部安全或商業策略不能安裝最新的免費瀏覽器。

3. 避免使用特定於瀏覽器的程式碼。在大多數情況下都有一個優雅的跨瀏覽器相容解決方案。

　常見錯誤 9: 沒有考慮可移植性

　　想當然是萬錯之源! 對於可移植性來說, 尤為如此.  你有見過幾個人, 把檔案路徑, 資料庫連線字串直接寫在程式碼中. 你又見過多少人事先假設伺服器上已經安裝這個庫那個庫的? 事先假設應用的最終執行環境, 跟你本地的開發環境一致, 本身就是個錯誤.

　　理想的應用安裝配置要做到維護輕鬆簡單:

1. 要確保你的應用具有可擴充套件性, 能在負載平衡的多伺服器環境中執行.

2. 配置要簡潔明瞭, 並且集中儲存在一個配置檔案中.

3. 當伺服器配置不當, 導致錯誤出現時, 要能處理異常. 

　常見錯誤 10: 誤用 RESTful

　　RESTful API 在 web 開發中佔有一席之地. 無論是在系統內部使用, 還是整合到外部系統中, 幾乎每個 web 應用都會用到 REST 服務. 儘管如此, 還是有很多人在使用 RESTful 時候, 存在這樣那樣的問題.

　　呼叫 RESTful API 常見的錯誤有:

1.  HTTP 動詞沒寫對. 比如, 用 GET 提交資料. HTTP GET 旨在安全與冪等, 也就是說, 對於同一個資源, 無論你用 GET 呼叫多少次, 返回的結果都是一樣的, 應用的狀態也不會發生任何變化.

2. HTTP 狀態編碼沒用對. 最常見的例子是, 明明有錯誤, 卻返回編碼 200.

    HTTP 200 OK
    {     message:'出錯了'
    }

　　返回 HTTP 200 OK 的前提是, 提交的請求沒有導致伺服器端出現錯誤. 否則, 就應該根據錯誤資訊, 返回相應的錯誤編碼, 如: 400, 401, 500 等等.

　　更多的 HTTP 狀態編碼請檢視這裡.

　總結

　　Web 開發涉及的領域很廣, 包括網站, web service, 功能複雜的 web 應用等.

　　重點是在處理身份驗證和授權的時候要細心, 擴充套件性要事先計劃好.  總之凡事多想想, 人畜無害.

　　原文地址：http://www.toptal.com/web/top-10-mistakes-that-web-developers-make