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散播相關資訊。

• 郵件列表

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

• 瞭解潛在的客戶

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

• 不要讓使用者流走

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

　競爭策略

• 研究使用者產品需求

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

• 瞭解競爭對手

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

　　原文連結： Ata Sasmaz   翻譯： 伯樂線上 - 埃姆傑