Web開發中需要了解的東西

碼頭工人 12年前發布 | 28K 次閱讀 web

文/陳皓

在 StackExchange 上有人問了這樣一個問題：What should every programmer know about web development?（關于 Web 開發，什么是所有程序員需要知道的？）里面給出的答案非常不錯，所以，我翻譯轉載過來。 順便說一下，StackExchange 真是非常好，大家可以對同一個答案做貢獻和修訂，看看這個問題的修訂過程你就知道了——專業的問答網站應該怎么去做。這就是我在這篇文章中也說過真正的用戶體驗是什么樣的。

好了，下面是正文（我對原文做了一些批注，也許不對或有誤導，請大家指正）

下面的這些東西可能對于大多數人并不陌生，但是可能會有些東西你以前并沒有看過，或是沒有完全搞懂，甚至都沒有聽說過。（陳皓注：我相信當你看完這個列表后，你會覺得對于我國的 Web 開發有點弱了，還是那句話，表面上的東西永遠是膚淺的）

接口和用戶體驗

  • 小心瀏覽器的實現標準上的不一致，確信讓你的網站能夠適當地跨瀏覽器。至少，你的網站需要測試一下下面的瀏覽器：
    • </ul>

    最后，你可以使用一下這個工具 來看看你的網頁在不同的瀏覽器下是怎么被顯示出來的（陳皓注：這個工具就是以前本站介紹過的在不同瀏覽器和平臺上檢查你的網站的兼容性）

    • 多考慮一下人們是怎么來訪問你的網站而不是那些主流的瀏覽器：手機，讀屏軟件和搜索引擎，例如：一些 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 (更強，但是也更新一些) (1, 2)。你可以閱讀一下 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_”來向服務器發請求，推ter 的大量的鏈接者是#!的，比如：https://推ter.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。我想你可以去看一下其它人的答案，我有時間，我也會補充別人的答案進來。請隨意編輯這個答案，因為可能有些東西忘了，也有可能有些東西不對。


    來自: coolshell.cn

     本文由用戶 碼頭工人 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
     轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
     本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！
      本文地址：http://www.baiduhome.net/news/view/1ca444