自從1990年有了www互聯(lián)網這個概念后，web應用程序經歷了從提供靜態(tài)HTML頁面到完全動態(tài)的復雜的業(yè)務應用的改變。

　　今天我們有各種各樣的電子資源或圖書來告訴我們如何開發(fā)各種各樣的應用程序?，F在的開發(fā)環(huán)境也足夠智能，可以幫我們發(fā)現并修復很多錯誤。甚至有很多不同的開發(fā)平臺提供方便的將靜態(tài)頁面轉換為高度可交互的應用的功能。

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

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

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

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

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

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

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

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

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

　　Authorization（授權）:確認某個用戶是否有權獲取某個資源，或執(zhí)行某個行為。

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

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

　　想想看，你的瀏覽器擁有一個已登錄的用戶的信息，大概是這樣的一個對象

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

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

POST /changepassword/:username/:newpassword

　　在你的/changepassword方法, 你檢驗到這個用戶已經登錄了并且  token沒有過期. 然后用username參數找到這個用戶的信息, 并改變用戶的密碼。

　　那么，你驗證了這個用戶是已經登錄的，然后你執(zhí)行力他的請求也就是改變了他的密碼?？磥磉M展正確，對嗎？不幸的是，并不是這樣的。

　　關鍵點是校驗改變執(zhí)行這個操作的用戶和要改變的密碼的用戶同一個。瀏覽器上存儲的任何信息都可以被篡改，并且任何一個高級點的用戶只適用瀏覽器自帶的工具都可以輕易地把username:'elveis'改成username:’Administrator'.Administrator'.

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

　　你需要在你的 /changepassword 方法里驗證實際的請求者和請求的內容，并且實現用戶只能修改他自己的數據這樣的授權。

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

　常見錯誤#3: 沒有準備好擴展

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

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

　　例如，假設你選擇直接在web服務器上存儲用戶的上傳照片。這是一個完美的可行的方案--應用可以快速的獲取到這些文件，在每個開發(fā)平臺都有處理文件的方法，并且你都可以把這些圖片以靜態(tài)內容的方式提供，這意味這著應用程序的最小負載。

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

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

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

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

　　此外,SEO經常被推遲到最后才做。這需要很大的代價. SEO不僅僅是關于設置良好的內容、標簽、關鍵字、 meta-data,、圖像的 alt 標簽,、site map等等. 它還包括消除重復的內容、擁有可抓取的網站架構、高效的加載時間、智能的反向鏈接等等。

　　就像擴展性一樣，你應該在開始構建web應用程序的時候就考慮到SEO，不然你可能會發(fā)現完成SEO實現工程意味著重寫整個系統(tǒng)。

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

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

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

　　任何費時的動作都應該用另外一個線程來處理，從而盡快地釋放掉http請求。這種情況下，你因該有一個外部的郵件服務來接收訂單并發(fā)送通知。

　常見錯誤 #6: 沒有優(yōu)化帶寬使用

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

　　優(yōu)化網絡帶寬使用可以帶來極大的性能提升，并且你可能是需要一些小技巧來實現這樣的提升。這有一些規(guī)范的團隊默認做的事情，包括:

1. 縮小所有的JavaScript

2. 縮小所有的CSS

3. 壓縮服務器端的HTTP

4. 圖片尺寸和分辨率的優(yōu)化

　常見錯誤 #7: 沒有為不同大小的屏幕開發(fā)

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

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

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

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

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

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

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

2. 不要用統(tǒng)計數據來為不支持某個瀏覽器辯解。有很多組織采納新軟件或升級很慢?？赡苡写罅吭谀枪ぷ鞯挠脩粢L問你的網站，但是他們因為內部安全或商業(yè)策略不能安裝最新的免費瀏覽器。

3. 避免使用特定于瀏覽器的代碼。在大多數情況下都有一個優(yōu)雅的跨瀏覽器兼容解決方案。

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

　　想當然是萬錯之源! 對于可移植性來說, 尤為如此.  你有見過幾個人, 把文件路徑, 數據庫連接字符串直接寫在代碼中. 你又見過多少人事先假設服務器上已經安裝這個庫那個庫的? 事先假設應用的最終運行環(huán)境, 跟你本地的開發(fā)環(huán)境一致, 本身就是個錯誤.

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

1. 要確保你的應用具有可擴展性, 能在負載平衡的多服務器環(huán)境中運行.

2. 配置要簡潔明了, 并且集中保存在一個配置文件中.

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

　常見錯誤 10: 誤用 RESTful

　　RESTful API 在 web 開發(fā)中占有一席之地. 無論是在系統(tǒng)內部使用, 還是集成到外部系統(tǒng)中, 幾乎每個 web 應用都會用到 REST 服務. 盡管如此, 還是有很多人在使用 RESTful 時候, 存在這樣那樣的問題.

　　調用 RESTful API 常見的錯誤有:

1.  HTTP 動詞沒寫對. 比如, 用 GET 提交數據. HTTP GET 旨在安全與冪等, 也就是說, 對于同一個資源, 無論你用 GET 調用多少次, 返回的結果都是一樣的, 應用的狀態(tài)也不會發(fā)生任何變化.

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

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

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

　　更多的 HTTP 狀態(tài)編碼請查看這里.

　總結

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

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

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

　　哈爾濱品用軟件有限公司致力于為哈爾濱的中小企業(yè)制作大氣、美觀的優(yōu)秀網站，并且能夠搭建符合百度排名規(guī)范的網站基底，使您的網站無需額外費用，即可穩(wěn)步提升排名至首頁。歡迎體驗最佳的哈爾濱網站建設。