Web開發者必備：Web應用檢查清單

導讀：想做一個高品質的Web應用，前前後後要做的事情非常多。國外開發者 Ata Sasmaz 為 Web 開發者制作分享了一份檢查清單，包括應用開發、性能、安全、分析、可用性、可靠性、轉換政策、競争政策這些方面需要注意的事項。清單内容可能不全面，歡迎大家在評論中補充。

開發

• 記錄UI錯誤日志

  JavaScript 允許捕獲異常。這些異常需要通過Ajax請求送出到日志服務，否則很難截獲Web環境中的錯誤。

• 可交換的資料層

  資料層可分離，也可以與另一個遵從規範的資料層互換。

• 部署過程自動化

  部署過程應自動化。生産環境所用的項目檔案應由部署伺服器生成，并在無人工幹預的情況下自動完成。

• 使用版本控制系統

  版本控制系統儲存代碼更改的曆史，防止現有代碼的丢失。同時，它還有助于協同開發。GitHub是這項服務最流行的提供商。除此以外，還有BitBucket。微軟也有提供了額外協作特性的Team Foundation。

• 代碼審閱

  人總會有寫錯代碼的時候，而代碼審閱系統能保證開發者的高品質産出。同時，該系統還能讓不止一位開發者熟悉代碼。在某段代碼的作者不在的時候，其他開發者可以順利地做出修改。GitHub和Team Foundation都提供了相應的代碼審閱功能。

• 權限與角色系統

  每個應用都需要設計實作權限和角色系統。設立系統管理者，使用者管理者等角色需要一個靈活的全局角色系統。

• 記錄所有未處理的錯誤

  所有錯誤應當記錄下來，并用于未來的全面檢查。也就是所有錯誤都應當送出給全局錯誤記錄機制。

• 測試過程自動化

  每次部署前，測試伺服器應當運作所有測試。代碼測試通過時部署應用，沒能通過時報告給系統管理者。

• 業務層可以在不同環境上使用

  業務層中的代碼必須通用。即使代碼本身面向Web環境，它也應當能在不要求改變代碼的情況下使用于桌面環境，伺服器環境，移動裝置環境的不同使用者界面，不同資料層上。

• 制定編碼規範

  一份規定明确的編碼規範在未來項目開發的過程中起到重要作用。方法前需要寫上注釋嗎？命名規範是什麼？示例代碼應放置何處？

• 開發者機器配置的指導方案

  開發時最耗時的問題是不同的開發者之間的開發環境不同。需要讓人們知道的是，他們應當安裝什麼軟體，使用的是什麼版本，同時需要安裝什麼元件，以及怎樣安裝這些元件。

性能

• 使用CDN

  Content Delivery Networks（内容分發網絡）通過離訪客最近的伺服器，為你的服務提供圖檔，JS和CSS等靜态檔案來提高通路速度，同時削減了帶寬的用量。CloudFlare是CDN服務的絕佳示例。

• 壓縮所有的JS和CSS檔案

  JS和CSS檔案應當使用YUI compressor這樣的壓縮器來減少檔案體積，并且使用gzip傳輸。把JS代碼的引用放到最後也是不錯的做法。

• 記錄加載較慢的頁面

  Web應用程式應當響應迅速。分析頁面加載的系統有責任識别加載較慢的頁面。運作迅速的頁面可能會遇到一些使用者讀取特定資料時加載時間過長的問題。

• 非關鍵資料使用NoSQL存儲

  NoSQL資料庫（文檔型資料庫）在接收資料和存儲資料時的速度很快，并且可以大規模擴充。由于這類資料庫不能確定關系的完整性，是以應當為關鍵資料使用關系型資料庫。在諸如使用者通知和聊天記錄等場合，NoSQL可以節約成本，安全地使用。

• 選擇附近的資料中心

  資料中心的位址應當靠近絕大多數使用者。處在與使用者同一個國家的資料中心對頁面通路速度大有影響。有必要的情況下，還可以建立多個資料中心。

• 允許資料多來源

  存儲資料的成倍增加，帶來的是應用程式性能降低。程式架構應做好處理多來源的大規模資料的準備。

安全

• 隔離資料庫中的關鍵資訊

  資料庫使用者在通路關鍵資訊時應受到限制，比如取得哪怕是已經Hash過了的密碼和所有使用者的Email位址等資訊。應當使用存儲過程和視圖作驗證，或者作自定義資料。

• 防止遠端執行代碼

  應用程式包含了對安全性較差代碼的依賴時，會使攻擊者在遠端執行相應的攻擊代碼。

• 防止洪水攻擊和垃圾郵件攻擊

  認證使用者發起的洪水攻擊和垃圾郵件攻擊都是可能的。要注意随時跟蹤他們最後發起的不明操作，避免制造大量請求。

• 對密碼散列處理時使用唯一salt值

  所有密碼都應當使用salt值散列處理，并且每個使用者的salt值都是唯一的。人們容易在不同的服務上使用相同的密碼，應用程式有責任保護使用者的密碼。

• 全局的跨站腳本攻擊（XSS）保護

  XSS攻擊的全稱是Cross Site Scripting跨站腳本攻擊，是讓使用者執行遠端惡意腳本的Web漏洞。

• 防止SQL注入漏洞

  SQL注入是常見的漏洞。攻擊者通過構造字元串，可以執行有害的SQL指令。使用ORM是一種防範的好方法。

• 防止跨站請求僞造（CSRF）

  Cross-Site Request Forgery跨站請求僞造是一種常見的Web漏洞，攻擊者在他們的網站上放置一個iframe架構，該架構從程式中請求頁面，而使用者并不處于應用程式中。GET請求不應該修改資料，這是硬性要求，防止從應用程式域名之外發出POST請求，同時，也可以保護程式不受攻擊。相比之下，更好的做法則是在每個表單裡提供接收請求後驗證的token。

• 修改關鍵資訊之前驗證密碼

  即使使用者資訊在電腦上有所記錄，甚至使用者幾分鐘前成功登入了系統，在通路或者修改如密碼，Email或者資料備份等關鍵資訊時總是需要驗證密碼。

• HTTP的嚴格安全傳輸

  如果用HTTPS傳輸資料，就應該隻使用HTTPS傳輸。否則中間人很可能有作為HTTPS到HTTP傳輸的轉換者，讓使用者使用HTTP送出請求以分析資料。

• 在所有應用中使用HTTPS

  HTTPS是世界範圍的加密标準，在第一次連接配接握手之後沒有額外的開銷。所有的頁面和資源都應當使用HTTPS傳輸。使用HTTPS的時候，推薦的資訊來源也要是HTTPS。否則浏覽器就會以安全原因不予顯示。

• 驗證會話的浏覽器和位置資訊

  會話和Cookies都可以被劫持。浏覽器報頭資訊和使用者最後的IP位址的位置資訊都可以和原來的使用者會話對比。一個積極防範的辦法是将會話與使用者IP綁定，但是可能會在動态位址和移動裝置的情況下造成問題。

分析

• 盡可能保留資料

  每項資料、每條請求、每個事件都應當記錄在“大資料”的存儲中。這些資料将來會很有用處，資料挖掘技術将會呈現出有用的分析報告。

• 觀察使用者意向

  對于未來計劃而言，找出使用者使用應用程式與否背後的原因十分重要。

• 允許使用者靈活擷取分析報告

  現如今資料分析非常關鍵。分析報告揭示了未來業務的走向何方。優秀的應用程式不僅能便利使用者，而且能讓使用者按需生成報表。

可靠性

• 分發請求并做到100%上線率

  應用伺服器直接接受連接配接，不如在内部搭建一個分發請求的反向代理伺服器。這樣在有部分伺服器當機的情況下也能由仍然運轉的伺服器提供服務。

• 自動備份資料

  資料應當至少每天備份，而更多的備份任務應當取決于特定存儲和應用伺服器，必要時還需要做好資料中心的災備方案。

• 100% 覆寫業務層和資料層的測試

  測試應當覆寫業務層和資料層的所有代碼。攪亂使用者資料，計算出錯誤的結果，提供錯誤資料，以及存儲發生錯誤将會造成使用者流失和金錢損失。

• 檢測伺服器線上時長

  目前有許多檢測伺服器線上時長的第三方服務。他們同時也提供按指定時間間隔，檢查伺服器狀态的定制服務。

可用性

• 減少頁面重新整理

  與Ajax技術相比，重新整理頁面更慢，同時也在頁面跳轉時使使用者流失。單頁應用（類似Gmail）使用者體驗良好，同時也更難開發，更容易出bug。資源（人力）足夠，則可以選擇開發單頁應用，否則更應該采用Ajax技術。

• 隐藏生産環境中的詳細錯誤資訊

  詳細的錯誤提示頁面輸出了與錯誤有關的任何資訊，是每位開發者都需要的。生産環境中的應用程式仍然能夠記錄這些資訊日志，那麼就有必要隐藏這些資訊。

• 簡化使用者界面

  “學習使用程式”的時代已經過去。在使用者熟悉之前，程式要足夠簡單。在使用者熟悉之後，進階操作就會顯現出來。複雜的界面會使使用者望而卻步。

• 全局搜尋系統

  使用搜尋的傾向已在近年來逐漸上升。Google、Facebook、Twitter都有搜尋功能。所有的軟體巨頭都會提供能對搜尋結果篩選的全局搜尋系統。要讓使用者們在你的應用上也能有一緻的功能。

• 發生狀況時引導使用者

  發生錯誤或者輸入密碼之後，需要向使用者指明他們的來向和去向，請記住這一點。

• 移動端優先的UI

  UI設計的通常做法是首先考慮桌面端，然後适配移動端裝置。這種做法在适配時開銷巨大。UI應當首先考慮移動裝置，再适配桌面端。

• 全局回報系統

  開發者和測試者不能預測問題的狀況時有發生。最好的解決辦法就是每個頁面上都設定能讓使用者通路到的回報機制。

• 一緻的UI行為

  使用者有可能使用着Windows、Mac、Linux、移動裝置或者某個不知名的裝置。而在這些環境中，UI的行為必須一緻。實作這一點的方法就是遵循标準，并且不使用不标準的元件。同時，使用Bootstrap或者Foundation這樣的架構也有幫助。

• 使用友好的URL

  雖然Web應用并不是針對有組織的訪客（來自搜尋引擎），人們在Email或者IM中分享位址的時候總是想要了解到點選以後出現的内容。人們通常對此解釋較少，是以分享的時候URL本身至少能提供相關的資訊。

轉化政策

• 邀請碼系統

  邀請注冊是獲得新使用者最古老也是最有效的轉化政策。成功的邀請系統不僅獎勵邀請人，被邀請人也會受益。

• 支援系統

  使用者總會有問題，而每個應用都需要支援系統。缺少支援系統會讓使用者望而卻步。這裡是一些外部方案：ZenDesk、Desk、Freshdesk、Zoho Support……

• 消息通知和定時發送Email

  讓使用者回頭使用軟體很重要。使用者常常不記得軟體，遺忘了便不再回來。定時發送帶有消息通知的Email能留住使用者。不要忘了保留這類選項的開關，不然那将會成為垃圾郵件。

• 總做得更好

  不論擁有多少使用者，哪怕1個，甚至成千上萬，總是要做得更好。這麼做将會掩蓋每個軟體都會有的瑕疵。

• 整合社交＋激勵

  訪客，哪怕是付費使用者，都很難有機會在社交網絡上分享你的應用。應該為此設立相應的激勵機制。這要求使用Facebook、Twitter等社交網絡API散播相關資訊。

• 郵件清單

  讓使用者保持更新十分重要。使用者使用軟體時，他們會很高興地得知你會為此做出支援，并做到更好。建立郵件清單，讓使用者知道每月的改進是負責任的态度。

• 了解潛在的客戶

  不要指望使用者自然而來，你得為之奮鬥。雖然有很多優質的廣告方案，更好的做法是在網際網路上花少量錢甚至免費提供相應的價值，然後将其引導到相應的産品上來。

• 不要讓使用者流走

  知道使用者離開的原因十分重要。好的系統會在使用者離開的時候發出一封郵件，提供優惠折扣，并且征求回報。

競争政策

• 研究使用者産品需求

  軟體産品的需求從來就不是憑空産生的。需求分析讓開發者與産品經理有據可依。嘗試着通過分析使用者最常使用的部分來了解客戶的真實需求。

• 了解競争對手

  沒有産品是生來完美的。一家公司開發，其他公司改進；最初的那一家因而得到進步。這是每個行業都會有的開發流程。每項産品都會有其競争對手。