【伯樂在線注】:《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)。
文中有很多省略掉的東西,並不是因爲它們不是有用的答案,而是它們過於詳細,且超出本問題的範圍。而對於想懂得更多的人來說,他們希望學到更多的東西,因此他們應該知道這些概述。另外,我也歡迎大家編輯補充這個答案,因爲我可能忽略了一些東西或犯了一些錯誤。