Web開發中須要瞭解的東西

在StackExchange上有人問了這樣一個問題:What should every programmer know about web development?(關於Web開發,什麼是全部程序員須要知道的?)裏面給出的答案很是不錯,因此,我翻譯轉載過來。 順便說一下,StackExchange真是很是好,你們能夠對同一個答案作貢獻和修訂,看看這個問題的修訂過程你就知道了——專業的問答網站應該怎麼去作。這就是我在這篇文章中也說過真正的用戶體驗是什麼樣的php

好了,下面是正文(我對原文作了一些批註,也許不對或有誤導,請你們指正)css

下面的這些東西可能對於大多數人並不陌生,可是可能會有些東西你之前並無看過,或是沒有徹底搞懂,甚至都沒有據說過。(陳皓注:我相信當你看完這個列表後,你會以爲對於我國的Web開發有點弱了,仍是那句話,表面上的東西永遠是膚淺的)html

接口和用戶體驗

  • 當心瀏覽器的實現標準上的不一致,確信讓你的網站可以適當地跨瀏覽器。至少,你的網站須要測試一下下面的瀏覽器:

最後,你可使用一下這個工具 來看看你的網頁在不一樣的瀏覽器下是怎麼被顯示出來的(陳皓注:這個工具就是之前本站介紹過的在不一樣瀏覽器和平臺上檢查你的網站的兼容性前端

  • 多考慮一下人們是怎麼來訪問你的網站而不是那些主流的瀏覽器:手機,讀屏軟件和搜索引擎,例如:一些Accessibility的東西: WAI 和  Section508, 移動設備開發:MobiForge.
  • 部署Staging:怎麼部署網站的更新而不會影響用戶的訪問。 Ed Lucas的答案 可讓你瞭解一些(陳皓注:Ed說了一些如版本控制,自動化build,備份,回滾等機制)。
  • 千萬不要直接給用戶顯示不友好的錯誤信息。
 
  • 千萬不要把用戶的郵件地址以明文顯示出來,這樣會被爬蟲爬走並被讓用戶的郵箱被垃圾郵件搞死。
  • 爲用戶的連接加上 rel="nofollow" 的屬性以 避免垃圾網站的干擾。(陳皓注:nofollow是HTML的一個屬性,用於通知搜索引擎「這個連接所指向的網頁非我所能控制,對其內容不予置評」,或者簡單地說,該連接不是對目標網站或網頁的「投票」,這樣搜索引擎不會再訪問這個連接。這個是用來減小一些特定垃圾頁面對原網站的影響,從而能夠改善搜索結果的質量,而且防止垃圾連接的蔓延。)
  • 爲網站創建一些的限制 - 這個屬於安全性的範疇。(陳皓注:好比你在Google註冊郵箱時,你一口氣註冊超過兩個以上的郵箱,gmail要求給你發短信或是給你打電話認證,好比Discuz論壇的會限制你發貼或是搜索的間隔時間等等,更多的網站會用CAPTCHA來確認是人爲的操做。 這些限制都是爲了防止垃圾和惡意攻擊)
  • 學習如何作 Progressive Enhancement. (陳皓注:Progressive Enhancement是一個Web Design的理念,如:1)基礎的內容和功能應該能夠被全部的瀏覽器存取,2)頁面佈局的應該使用外部的CSS連接,3)Javascript也應該是外部連接還應該是 unobtrusive 的,4)應該讓用戶能夠設置他們的偏好)
  • 嚴重關注Accessibility。由於這是法律上的需求(陳皓注:Section 508是美國的508法案,其是美國勞工復健法的改進,它是一部聯邦法律,這個法律要求全部技術要考慮到殘障人士的應用,若是某個大衆信息傳播網站,若是某些用戶羣體(如殘疾人)瀏覽該網站獲取信息時,若是他們沒法正常得到所指望的信息(如沒法正常瀏覽),那能夠依據相關法規,能夠對該網站依法起訴)。 WAI-ARIA 爲這方面的事提供很不錯的資源.

安全

  • 在網上有不少關於安全的文章,可是 OWASP 開發指導 涵蓋了幾乎全部關於Web站點安全的東西。(陳皓注:OWASP(開放Web應用安全項目- Open Web Application Security Project)是一個開放的非營利性組織,目前全球有130個分會近萬名會員,其主要目標是研議協助解決Web軟體安全之標準、工具與技術文件,長期 致力於協助政府或企業瞭解並改善網頁應用程式與網頁服務的安全性。OWASP被視爲Web應用安全領域的權威參考。2009年下列發佈的美國國家和國際立法、標準、準則、委員會和行業實務守則參考引用了OWASP。美國聯邦貿易委員會(FTC)強烈建議全部企業需遵循OWASP十大WEB弱點防禦守則)
  • 永遠不要相信用戶的輸入(包括Cookies,由於那也是用戶的輸入)
  • 對用戶的口令進行Hash,並使用salt,以防止Rainbow 攻擊(陳皓注:Hash算法可用MD5或SHA1等,對口令使用salt的意思是,user 在設定密碼時,system 產生另一個random string(salt)。在datbase 存的​​是與salt + passwd 產的md5sum 及salt。 當要驗證密碼時就把user 輸入的string 加上使用者的salt,產生md5s​​um 來比對。 理論上用salt 能夠大幅度讓密碼更難破解,相同的密碼除非恰好salt 相同,最後​​存在database 上的內容是不同的。google一下md5+salt你能夠看到不少文章。關於Rainbow 攻擊,其意思是很像密碼字典表,但不一樣的是,Rainbow Table存的是已經被Hash過的密碼了,並且其查找密碼的速度更快,這樣可讓攻擊很是快)。使用慢一點的Hash算法來保存口令,如 bcrypt (被時間檢證過了) 或是 scrypt (更強,可是也更新一些) (12)。你能夠閱讀一下 How To Safely Store A Password(陳皓注:酷殼之前曾介紹過bcrypt這個算法,這裏,我更建議咱們應該讓用戶輸入比較強的口令,好比Apple ID註冊的過程須要用戶輸入超過8位,須要有大小寫和數字的口令,或是作出相似於這樣的用戶體驗的東西)。
  • 使用 SSL/HTTPS 來加密傳輸登陸頁面或是任可有敏感信息的頁面,好比信用卡號等。
  • 知道如何對付session 劫持。(陳皓注:請參看wikipedia的這Session Hijacking,)
  • 保持你的系統裏的全部軟件更新到最新的patch。
  • 確保你的數據庫鏈接是安全的。
  • 確保你能瞭解最新的攻擊技術,以及你係統的脆弱處。

性能

  • 優化頁面 —— 不要使用20KB圖片來平鋪網頁背景。(陳皓注:還有不少網頁頁面優化性的文章,你能夠STFG – Search The Fucking Google一下。若是你要調試的話,你可使用firebug或是chrome內置的開發人員的工具來查看網頁裝載的性能)
  • 學習如何 gzip/deflate 網頁 (deflate 更好).
  • 把多個CSS文件和Javascript文件合併成一個,這樣能夠減小瀏覽器的網絡連數,而且使用gzip壓縮被反覆用到的文件。
  • 爲那些小的圖片使用 CSS Image Sprites,就像工具條同樣。 (參看 「最小化 HTTP 請求」 ) (陳皓注:把全部的小圖片合併成一個圖片,而後用CSS把顯示其中的一塊,這樣,這些小圖片只用傳輸一次,酷殼的Wordpress樣式的那個RSS訂閱列表中的小圖標就是這樣作的)
  • 繁忙的網絡應該考慮把網頁的內容分開存放在不一樣的域名下。(陳皓注:好比有專門的圖片服務器——圖片至關耗帶寬,或是專門的Ajax服務器)
  • 靜態網頁 (如,圖片,CSS,JavaScript,以及一些不須要訪問cookies的網頁) 應該放在一個不使用cookies的獨立的域名下,由於全部在同一個域名或子域名下的cookie會被這個域名下的請求一同發送。另外一個好的選擇是使用 Content Delivery Network (CDN).
  • 使用單個頁面的HTTP請求數最小化。
  • 爲Javascript使用 Google Closure Compiler 或是 其它壓縮工具(陳皓注:壓縮Javascript代碼可讓你的頁面減小網絡傳輸從而能夠獲得很快的喧染。注意,並非全部的工具均可以正確壓縮Javascript的,Google的這個工具甚至還能夠幫你優化你的代碼)
  • 確認你的網站有一個 favicon.ico 文件放在網站的根下,如 /favicon.ico瀏覽器會自動請求這個文件,就算這個圖標文件沒有在你的網頁中明顯說明,瀏覽器也會請求。若是你沒有這個文件,就會出大量的404錯誤,這會消耗你的服務器帶寬。(陳皓注:服務器返回404頁面會比這個ico文件可能還大)

SEO (搜索引擎優化)

  • 使用 「搜索引擎喜歡的」 URL,如:使用 example.com/pages/45-article-title 而不是 example.com/index.php?page=45 (陳皓注:這裏的URL是說Wordpress的,後者是默認的)
  • 若是你的動態頁面要使用 # ,那麼請把其改爲 #! ,而在服務端,你須要處理$_REQUEST["_escaped_fragment_"] 這是Google搜索引擎須要的。換句話說,./#!page=1 會被Google搜索引擎轉成 ./?_escaped_fragments_=page=1。 (陳皓注:一般來講URL中的#後的東西都不會被傳到服務器上,因此,爲了要讓Google能夠抓取AJAX的東西,你須要使用#!,而Google會把「#!」轉成「_escaped_fragment_」來向服務器發請求,Twitter的大量的連接者是#!的,好比:https://twitter.com/#!/your_activity)。另外,用戶也許會使用Firefox 或 Chromium, history.pushState({"foo":"bar"}, "About", "./?page=1"); 是一個很不錯的命令。因此,就算是咱們的地址欄上的地址改變了,頁面也不會從新裝載。這可讓你使用 ? 而不是 #! 也能無刷地保住當前的動態的頁面,這可讓AJAX的請求被瀏覽器記住。
  • 別使用 「click here」 這樣的連接。這樣一來,沒法SEO,並且對於一些須要使用讀屏人來講很不友好(陳皓注:關於讀屏軟件,可參看本站的「若是看不見你還能編程嗎」)
  • 瞭解 robots.txt 和搜索引擎爬蟲是如何工做的。
  • 重定向請求 (使用 301 重定向網站) ,若是你要把 www.example.com 定向到 example.com(或是其它的變動) 這樣能夠防止Google的rank由於域名的變化發生改變。(陳皓注:301重定向通常用做域名變動)
  • 知道並非全部的爬蟲都是好的,有些爬蟲的行爲並很差。(陳皓注:好比向你的網站發大量的請求致使服務器性能低下)
  • 若是你有一些非文本的內容須要在 Google’s sitemap  中,好比視頻什麼的。Tim Farley的答案,可讓你看到不少有價值的東西。

技術

  • 理解什麼是 HTTP 好比 GET, POST, sessions, cookies等,瞭解什麼是 「stateless」 無狀態。
  • 讓你的 XHTML/HTML 和 CSS 符合 W3C 規範,並確認他們都是 合格的。咱們的目標是避免瀏覽器的 「quirks mode」,而且可讓其更容易地能和非標準的瀏覽器工做,好比讀屏器或移動設備。
  • 理解瀏覽器是怎麼處理 JavaScript 的。(陳皓:你會看到有些Javascript代碼在頁面上前面,有些則是在後面,因此你須要對其瞭解清楚爲何是這樣)
  • 瞭解瀏覽器是怎麼裝載 JavaScript,CSS和其它資源的,瞭解其對視覺上的影響。(陳皓注:10年前我作網頁的時候由於HTML還很弱,因此只能使用table來佈局,使用table佈局的問題就是整個table讀完後頁面纔會顯示,用戶的視覺體驗並很差)。在某些狀況下,你可能須要把你的腳本放在頁面的後面
  • 理解 JavaScript 的 sandbox 是怎麼怎麼工做的,尤爲是你想使用iframes。
  • 請注意 JavaScript 可能會被禁止,這樣會讓你的AJAX失效。就算是大多數用戶都開啓了Javascript功能,可是也可能在一些狀況下腳本是不被運行的,好比移動終端上,搜索引擎抓網頁的時候也並不會執行你的腳本。
  • 儘量多地學習你的部署平臺。(好比:操做系統,Web Server:Apache/Nginx,防火牆,數據庫,等等)
  • 把視覺效果和JS框架合在一塊兒討論,考慮使用一個Service,如:Google Libraries API 來裝載框架,這樣可讓瀏覽器可能早就把這個JS框架已經cache了而不須要再從你的網站上下載了。

Bug fixing

  • 明白你會花20%的時間寫代碼,而80%的時候在維護,因此你要當心編碼。(陳皓注:參看本站的「多些時間能夠少些代碼」一文)
  • 設計一個好的錯誤報告機制。
  • 設計一個入口可讓人們聯繫到你並給你建議和批評。
  • 爲你開發的東西造成文檔,這樣可讓後來的人容易維護你的軟件和系統。
  • 頻繁備份(也可確保你的這些備份功能正常) Ed Lucas 的回答 有一些忠告。你還須要有一個恢復策略,而不僅是一個備份策略。
  • 使用一個版本控制系統來保存你的代碼,如: Subversion 或 Git.
  • 別忘了作Acceptance Testing,使用 Selenium 能幫到你。
  • 確保你有足夠的日誌,你可使用 log4j, log4n 或 log4r。若是出了問題,這是可讓你快速找到問題的方式。
  • 當你寫日誌的時候,確保你記錄了你捕獲了處理和未處理異常。報告和分析日誌可讓你知道你網站的問題。

這裏有多的東西被省略了,並非由於那些可能不是有幫助的答案,而是由於那些東西都太細節了,超出了這個問題的範圍,由於這原本就是一個Web開發須要瞭解東西的Overview。我想你能夠去看一下其它人的答案,我有時間,我也會補充別人的答案進來。請隨意編輯這個答案,由於可能有些東西忘了,也有可能有些東西不對。html5

相關文章
相關標籤/搜索