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、非死book、推ter都有搜索功能。所有的軟件巨頭都會提供能對搜索結果篩選的全局搜索系統。要讓用戶們在你的應用上也能有一致的功能。

• 發生狀況時引導用戶

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

• 移動端優先的UI

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

• 全局反饋系統

開發者和測試者不能預測問題的狀況時有發生。最好的解決辦法就是每個頁面上都設置能讓用戶訪問到的反饋機制。

• 一致的UI行為

用戶有可能使用著Windows、Mac、Linux、移動設備或者某個不知名的設備。而在這些環境中，UI的行為必須一致。實現這一點的方法就是遵循標準，并且不使用不標準的組件。同時，使用Bootstrap或者Foundation這樣的框架也有幫助。

• 使用友好的URL

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

轉化策略

• 邀請碼系統

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

• 支持系統

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

• 消息通知和定時發送Email

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

• 總做得更好

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

• 整合社交＋激勵

訪客，哪怕是付費用戶，都很難有機會在社交網絡上分享你的應用。應該為此設立相應的激勵機制。這要求使用非死book、推ter等社交網絡API散播相關信息。

• 郵件列表

讓用戶保持更新十分重要。用戶使用軟件時，他們會很高興地得知你會為此做出支持，并做到更好。創建郵件列表，讓用戶知道每月的改進是負責任的態度。

• 了解潛在的客戶

不要指望用戶自然而來，你得為之奮斗。雖然有很多優質的廣告方案，更好的做法是在互聯網上花少量錢甚至免費提供相應的價值，然后將其引導到相應的產品上來。

• 不要讓用戶流走

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

競爭策略

• 研究用戶產品需求

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

• 了解競爭對手

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

原文鏈接： Ata Sasmaz   翻譯： 伯樂在線 - 埃姆杰
譯文鏈接： http://blog.jobbole.com/55582/