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散播相關信息。

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

• 瞭解潛在的客戶
  不要期望用戶天然而來，你得爲之奮鬥。雖然有不少優質的廣告方案，更好的作法是在互聯網上花少許錢甚至免費提供相應的價值，而後將其引導到相應的產品上來。

• 不要讓用戶流走
  知道用戶離開的緣由十分重要。好的系統會在用戶離開的時候發出一封郵件，提供優惠折扣，而且徵求反饋。

競爭策略

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

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

---

原文：Checklist
轉載自：伯樂在線 - 埃姆傑