Web應用上線前，程式設計師該考慮的技術有這些

【伯樂線上注】：《Web應用上線前，程式設計師該考慮的技術有這些》這是 StackExchange 上面的一個經典問題貼。

最贊回覆有 2200+ 頂，雖然大多數人可能都聽過其中大部分內容，但應該會有你沒有深入瞭解的內容。一起來看看。

---

問題

Web 應用上線前，程式設計師應考慮哪些技術細節呢？ 如果 Jeff Atwood 忘記把 HttpOnly cookies、sitemaps 和 cross-site request forgeries 放在同一個網站，那我會把什麼重要的東西也會忘掉呢？

我以一個 Web 開發人員的角度思考這個問題，別人為網站進行美化設計並填充內容。因此，他們可能認為可用性和內容比平臺更重要，程式設計師在這方面沒多少發言權了。而你需要考慮到的是：你實現平臺的穩定性、安全性和滿足其它商業目的（如成本不要太高、耗時不要太長和網站排名）。

而以一位已經在相當可信的環境下，完成了幾個企業內網應用程式專案的開發者角度思考，並在一個流行且權威網站上為整個糟糕的全球資訊網打響第一槍。

另外，我希望能回答得更加具體一點，而不僅僅是一個“Web標準”這樣模糊的答案。通過 HTTP 傳輸的 HTML、JavaScript、CSS 是必須要掌握的，特別是針對那些資深 Web 開發者。所以，超出上述範圍，哪一個標準？在什麼環境下，並且為什麼這樣？麻煩您提供一個跳轉到該標準說明的連結。

 

最佳回覆

下面列表裡的大部分內容，我們大多數人都應該已經聽過了。所以在這之前，你可能只有一到兩個專案沒有深入檢視和理解透徹，或甚至沒聽過。

介面和使用者體驗

• 應意識到瀏覽器實現標準不一致，並確保你的網站能在所有主流瀏覽器上合理執行。至少起碼在最近的 Gecko 引擎（Firefox）、Webkit 引擎（Safari 和一些移動端瀏覽器）、Chrome、支援 IE 瀏覽器（利用 Application Compatibility VPC Images 進行測試）和 Opera。另外，也要考慮瀏覽器在不同作業系統下是如何渲染網站的。
• 要考慮到使用者除了通過主流瀏覽器來瀏覽網站外，還有其它方式：手機、螢幕閱讀器和搜尋引擎等。 這有一些相關資訊：WAI 和 Section508，移動開發：MobiForge。
• Staging：如何部署更新而不影響使用者。進行一次或多次測試或 staging 環境可用來實現架構的更改，確保程式碼或全部內容能部署在一個可控的方式而不會破壞任何東西。有一個自動化的方式部署批准改變網站。最有效地實現方法是使用版本控制系統(Git、CVS、Subversion 等)和一個自動構建機制( Ant、 NAnt 等)。
• 不要向使用者直接顯示不友好的錯誤提示。
• 不要以純文字的方式顯示使用者的 Email 地址，否則他們將會收到該死的垃圾郵件。
• 為使用者連結新增屬性 rel = “nofollow” 來 避免垃圾郵件。
• 為你的網站建立深思熟慮的限制 – 這也屬於下面將要講到的安全性。
• 學會如何實現網頁的 漸進增強。
• POST 提交成功後，要重定向，以防止再次提交引起重新整理。
• 別忘了考慮到訪問性（accessibility，即殘障人士如何使用網站）。這一直是好想法並且有時這是法定要求。WAI-ARIA 和 WCAG 2 都是這方面很好的資源。
• 別讓使用者思考如何操作。

安全性

• 閱讀 《OWASP開發指南》，它提供了全面的網站安全指導。
• 知道注入相關的知識，尤其是 SQL 注入，並知道如何防止它。
• 千萬別相信使用者的輸入，也不要相信任何請求（其中包括 cookies 和 表單域的隱藏欄位值！）。
• 使用 salt（密碼雜湊技術）雜湊密碼併為你的彩虹錶行使用不同的 salts 來防止 rainbow 攻擊。 使用一個效率較低的雜湊演算法，如 bcrypt （ 久經試驗的）或 scrypt （更新，甚至更強）（1，2），來儲存密碼。（如何安全地儲存一個密碼）。NIST 也批准用 PBKDF2 雜湊密碼，FIPS 認可 .NET （想了解更多資訊，請 點選）。應避免直接使用 MD5 或 SHA 家族。
• 別嘗試提出你自己喜歡的認證系統。這很容易在微妙且不可測的方式下出現錯誤，而且你可能直到被入侵才知道發生什麼事
• 瞭解 處理信用卡的規則。（也可以看看這裡這個問題）
• 在登入頁和任何涉及敏感資料的網頁（如信用卡資訊），使用 SSL / HTTPS。
• 防止 會話（session）劫持。
• 避免 跨站指令碼攻擊（XSS）。
• 避免 跨站請求偽造攻擊（CSRF）。
• 避免 點選劫持。
• 系統補丁要保持更新。
• 保證資料庫連線資訊保安。
• 你自身要保持關注最新的攻擊技術和影響你平臺的漏洞。
• 閱讀  Google 的《瀏覽器安全手冊》。
• 閱讀 《Web應用黑客手冊》。
• 考慮 最小特權原則。嘗試將你的應用程式在 非根模式（non-root）的伺服器下執行。（tomcat 案例）

效能

• 如有必要，就實現快取。瞭解和正確地使用 HTTP 快取（caching）和 HTML 5 離線快取。
• 優化圖片 – 別使用一個 20 KB 大小的圖片做為一個重複背景。
• 學習如何用 gzip / deflate 壓縮內容（deflate更好）。
• 合併多個樣式表單或指令碼檔案，以減少瀏覽器傳送請求次數，而且要利用 gzip 壓縮檔案之間重複的部分。
• 瀏覽 Yahoo Exceptional Performance（雅虎優越效能）網站，裡面有很多優秀的指引，其中就包括提高前端效能和它們的 YSlow 工具（需要 Fixfox、Safari、Chrome 或 Opera）。另外，Google PageSpeed （以 瀏覽器擴充套件 的方式）是另一個測試效能的工具，而且它也會優化你的圖片。
• 為較小且有關聯的圖片使用 CSS 圖片精靈 技術，如工具欄（看“把 HTTP 請求減到最低”那點建議）
• 繁忙 Web 站點應考慮將 網頁的內容分開存放 在不同的域名下。特別是…
• 靜態內容（也就是圖片、CSS、JavaScript 和無需通過 cookies 獲取的一般內容）應放進獨立且 不使用 cookies 的域名上，因為所有域名和其子域名為客戶端生成的 cookies 都會伴隨請求傳送回給自己。 一個很好的選擇是使用內容分發網路（CDN），但要考慮到這種情況：CDN（包括可替代的 CDN）可能會失效，這時本地副本能代替它來進行傳輸。
• 將瀏覽器渲染頁面所需 HTTP 請求數量最少化。
• 用Google的 Closure Compiler 壓縮 JavaScript，當然也可以使用 其他壓縮工具。
• 確保有一個 favicon.ico 檔案在網站的根目錄，也就是說 /favicon.ico。瀏覽器會自動請求它，即使在 HTML 中並未提及到它。如果沒有 /favicon.ico，那麼請求返回的結果是 大量的 404 錯誤，這將會耗盡伺服器的頻寬。

SEO（搜尋引擎優化）

• 使用“對搜尋引擎友好”的連結，比如說 example.com/pages/45-article-title 優於 example.com/index.php?page=45。是 googlebot（Google 的 web 爬蟲）用來替換 #! 的。換句話說，./#!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 無須再傳送一個額外的請求了。
• 別使用 “點選這裡” 這類的連結。這是浪費一個 SEO 的機會，並且會對使用螢幕朗讀器使用者造成困惑。
• 擁有一個 XML 網站地圖，它的預設路徑最好是 /sitemap.xml。
• 當你有多個 URL 指向同一個內容時，請使用 <link rel="canonical" ... />。這個問題可利用 Google Webmaster Tools 解決。
• 使用 Google Webmaster Tools 和 Bing Webmaster Tools。
• 在一開始就正確安裝 Google Analytics （或一個開源的分析工具，如 Piwik）。
• 要知道 robots.txt 和搜尋引擎爬蟲是如何工作的。
• 重定向請求（使用 301 永久性移走），要求 www.example.com 重定向到 example.com （或反過來），從而防止分裂兩個站點之間的谷歌排名。
• 知道並不是所有的爬蟲都是好的，有些爬蟲的行為並不好。
• 如果有非文字內容（如視訊等）需要新增到 Google 網站地圖的話，你可以到 Tim Farley’s answer 看看，裡面有一些關於這方面的，而且不錯的資訊。

技術

• 搞懂 HTTP 協議，以及諸如 GET 、POST、sessions 和 cookies 這些概念，而且要知道“無狀態”是什麼意思。
• 根據 W3C 文件 編寫你的 XHTML / HTML 和 CSS 程式碼，並確保它們 有效。這裡的目的是避免瀏覽器的怪異模式，並讓它們更容易在非傳統瀏覽器（如螢幕閱讀器和移動裝置）上執行。
• 搞懂瀏覽器是如何處理 JavaScript。
• 搞懂頁面上的 JavaScript、樣式表單和其他資源是如何載入和執行的，並考慮它們對效能的影響。現在廣泛認同的做法是：除了通用指令碼，如 analytics apps 或 HTML5 shims，將其它指令碼放到頁面底部。
• 搞懂 JavaScript 沙箱如何工作，特別是你打算用 iframes。
• 要意識到 JavaScript 可能會被禁用，因此 AJAX 也只是一個擴充套件，不一定會被執行。即使大多數普通的使用者並不會理會 JavaScript 被禁用，但要記住 NoScript 正變得更流行，移動裝置可能預設禁止 JavaScript，而且 Google 在索引你的網站時，並不會執行大多數 JavaScript。
• 學會區分 301 和 302 重定向 的不同之處（這也是一個 SEO 問題）。
• 儘可能多地學習你部署平臺的相關知識。
• 考慮使用 Reset Style Sheet（重置樣式表單） 或 normalize.css。
• 考慮使用 JavaScript 框架（如 jQuery、MooTools、Prototype、Dojo 或 YUI 3），它們會解決很多在使用 JavaScript 操作 DOM 時的瀏覽器差異問題。
• 把效能和 JS 框架合在一起討論，考慮使用諸如 Google Libraries API 服務來載入框架， 以至於瀏覽器能使用已快取框架的副本，而不是從你的網站下載同樣的副本。
• 不要重複造輪子。在做任何事之前，可搜尋一個元件或案例是如何實現的。但有 99% 機會是其它人已經做過了，併發布了 OSS 版本的程式碼。
• 另外，即時確定你需要的是什麼，但也別使用太多庫。特別是在 Web 客戶端，保持輕量、快速和靈活非常重要。

BUG 修復

• 要明白你將花費 20% 時間敲程式碼，而剩下 80% 的時間是在維護你的程式碼，所以程式碼質量很重要。
• 建立一個良好的錯誤報告解決方案。
• 為使用者提供一個能向你提交建議與批評的系統。
• 為將來的維護和技術支援人員撰寫文件，解釋清楚系統是怎麼執行的。
• 經常備份！（並確保那些備份是可用的）除了備份機制，你還必須有一個恢復機制。
• 使用版本控制系統來儲存你的檔案，如 Subversion、Mercurial 或 Git。
• 別忘記進行驗收測試。框架（如 Selenium）能為你提供相應幫助。特別是如果你想完全自動化測試，也可通過使用持續整合工具，比如 Jenkins。
• 在網站執行時，要確保你有足夠的日誌，當然你可以使用框架，如 log4j、log4net 或 log4r。因為當你的網站某部分發生錯誤，你將需要一種方式找出是哪裡發生的。
• 當日志能確保你能同時捕捉到處理異常和未處理異常。那麼可通過記錄/分析輸出的日誌，可顯示網站的關鍵問題出現在哪裡。

其他

• 伺服器端和客戶端都要監控和分析（應主動而不是被動）。
• 使用能與使用者保持聯絡的服務（如 UserVoice 和 Intercom，或其它類似的工具）。
• 採用 Vincent Driessen 的 Git 分支模型（Git branching model）。

文中有很多省略掉的東西，並不是因為它們不是有用的答案，而是它們過於詳細，且超出本問題的範圍。而對於想懂得更多的人來說，他們希望學到更多的東西，因此他們應該知道這些概述。另外，我也歡迎大家編輯補充這個答案，因為我可能忽略了一些東西或犯了一些錯誤。

打賞支援我翻譯更多好文章，謝謝！

打賞譯者