原文連結：Things to Know When Making a Web Application in 2015
譯者：傑微刊--劉祥明
去年，我從零開始搭建了我的第一個正式的web應用。並從中學到了很多以前所不知的經驗，尤其是在安全和使用者體驗方面。
順便一提，我最近一次嘗試構建具有相當複雜度的東西是在2005年， 所以—我得為自己辯護一下——有很多方面我也需要充電。
不管是在我所知之外還是親眼所見，在開發web應用時，過於瑣碎的任務清單反而讓我們很容易忘記重要的事情——如果你是新進入web開發領域的話這一點尤為明顯。
這裡所列的checklist並不是詳盡無遺的。如果你是一個有經驗的開發者，我想這些東西都不會讓你感到新奇，但是我希望它們能對一些人有用，如果不閱讀這篇文章，他們可能會因此錯過一些好東西。
安全 Security
確認email（Confirm emails）: 使用者註冊時，系統應該給他傳送包含一個連結地址的email，使用者則需要開啟該連結以確認他們的email。如果使用者中途需要更新他們的email, 應該重新發起該流程。
身份管理（Identity Management）：當需要儲存密碼時， 首先應該使用現有被廣泛使用的加密庫對它們進行鹽值化和雜湊加密。如果你碰巧不用考慮身份管理，可以把它外發給Facebook/GitHub/Twitter/等。而僅在自己的應用中使用OAuth認證流程。
加密（Encryption）：權衡各種證照使用過程中所遇到的問題，還沒有哪一種方案優於SSL。所以直接使用它就可以了。同時， 請使用HSTS來保障應用的安全。
憑證（Credentials）：不要把任何伺服器憑證（API keys， 資料庫密碼，等等）提交到原始碼控制系統中。
工程：動畫 Eng:Animations
好鋼用在刀刃上，所以不要把應用中所有東西都變成動畫。大部分CSS動畫都會觸釋出局重繪；在transform和opacity屬性的使用上最好保持克制。
避免因使用transition屬性而引發惰性計算，如果你必須使用它們，請確保儘量使用更加明確的屬性（例如，使用"transition: opacity 250ms ease-in"而不是"transition: all 250ms ease-in"）
使用者體驗 UX
表單（Forms）：提交表單時，應該給使用者一個反饋。如果提交動作不需要把使用者引導到另一個頁面，應該彈框並給使用者一些提示資訊，讓他們知道本次提交是成功還是失敗。
登入重定向（Login redirects）：如果使用者尚未登入就訪問網站的某一個頁面，應該將其重定向到登入頁面，登入成功後再將其重定向回原先的頁面（當然，這裡假設他們已經獲得相應的許可權）。
如果使用者登入時輸入了錯誤的密碼，應為其提供明顯的線索，提醒他如果忘記密碼可以進行密碼重置。
Email
訂閱設定（Subscription settings）：向使用者傳送任何郵件都應該至少包含一個用於修改郵件設定的頁面連結，最好再包含一個連結以便使用者可以取消郵件訂閱。
不要讓使用者通過給你發郵件的方式來取消郵件訂閱。
移動裝置 Mobile
也許你並不需要針對移動裝置進行開發，但是不管怎麼樣，都應該確保你所做的決定是主動的。因為它對應用的設計和工程方面都會產生實質性的影響。
以下所列事項假定你選擇了移動裝置作為應用的其中一個目標平臺。因為我恰巧使用了Grunt作為我的構建工具，所以我囊括了一些我所使用的Grunt特有的外掛，但是很可能類似的外掛也存在於你所使用的JavaScript構建工具中。
工程 Engineering
單頁面應用（Single Page Apps）：如今單頁面應用（SPA）才是王道。SPA最大的優勢是更少的全頁面載入—只在需要的時候載入資源，而無需不斷地重複載入相同的資源。如果你新啟動一個web應用專案，那它就該是一個SPA。
使用者介面 UI
解析度（Resolutions）：如果你只是在發展自己的MVP使用者，不需要保證你的使用者介面能夠正常展現在所有的移動裝置上。但是，應該確保它們在常見手機和平板裝置的解析度下能正常顯示。待你的應用成為一個成熟的產品再考慮所有型別的裝置—我們要適應市場需求。
使用者體驗：頻寬 UX： Bandwidth
移動裝置最大的主題之一就是頻寬相對於桌面應用來說是更寶貴的資源。因此， 應該抓住每個機會減少請求的數量，如果情況允許，將它們變成非同步請求，並儘可能減少每次所請求資源的大小。
JS & CSS—合併及最小化（JS & CSS - Concat and minify）：應該將應用相關的JavaScript 和 CSS 檔案合併到單獨的檔案中（JS合併到一個檔案中，CSS合併到另一個檔案中 ）並將它們進行最小化處理。Grunt-contrib-concat, Grunt-contrib-cssmin 和 Grunt-contrib-uglify是這方面的好幫手。
所有資產—使用CDN（All assets - Use a CDN）：使用CDN能在兩個方面帶來很大的好處。第一個好處對所有的資產都適用，它就是本地化—CDN可以保證它所承載的資源在地理位置上離使用者更近，從而減少載入時間。
第二個好處更適用於應用的依賴（例如， 非應用相關的樣式和JS程式碼）。在這裡，使用CDN可以使得使用者裝置能夠從其快取中載入資源從而大大減少載入時間。例如，很多網站都依賴Angular.js， 使用CDN連結到Angular核心程式碼會觸發快取命中， 此時使用者裝置將從其快取中將它讀取出來使用，而不是通過發起一個額外的HTTP請求將它從伺服器上獲取下來。
CSS—儘量減少腳印（CSS - Reduce your footprint）：大部分開發者在開發他們的應用時，很有可能會使用一些UI框架（例如，Bootstrap， Foundation， 等等）。這些框架往往都很大，雖然可以從CDN上得到它們的最小化版本，但是不可能保證所有被包含進來的樣式都會被使用。因此，使用一些類似uncss（通常和processhtml一起配套使用）的工具移除那些沒有被使用到的樣式對我們來說顯然非常有價值。
但是請注意uncss解析器不能識別動態樣式（那些只對JavaScript事件起作用的樣式），因此需要在瀏覽器中進行嚴格的測試以確保它不會誤刪有用的樣式。
CSS—把重要的東西放在頭部（CSS - Put crucial things in the head）：把那些在應用完成載入前就需要用到的樣式放到頭部；那些沒那麼重要的樣式可以稍後再載入。
JS—儘量減少腳印（JS - Reduce your footprint）：一旦你的應用進入到產品階段， JavaScript程式碼內部的變數對終端使用者來說是毫無意義的，因此， 把變數user.email換成u.e可以在很大程度上減少檔案大小。很慶幸，有一個工具可以為我們完成這項任務—前面提到的uglify，它將JS程式碼打亂成人無法理解的形式，但是卻極大地減小了程式碼的尺寸。
使用者體驗：表單 UX：Forms
儘量讓表單和工作流程保持簡單，如果你把移動裝置作為目標平臺的話這點尤為重要。沒有人願意在他們的iPhone上填寫一份長達5頁的表單。
完整內容點此檢視
譯者：傑微刊--劉祥明
去年，我從零開始搭建了我的第一個正式的web應用。並從中學到了很多以前所不知的經驗，尤其是在安全和使用者體驗方面。
順便一提，我最近一次嘗試構建具有相當複雜度的東西是在2005年， 所以—我得為自己辯護一下——有很多方面我也需要充電。
不管是在我所知之外還是親眼所見，在開發web應用時，過於瑣碎的任務清單反而讓我們很容易忘記重要的事情——如果你是新進入web開發領域的話這一點尤為明顯。
這裡所列的checklist並不是詳盡無遺的。如果你是一個有經驗的開發者，我想這些東西都不會讓你感到新奇，但是我希望它們能對一些人有用，如果不閱讀這篇文章，他們可能會因此錯過一些好東西。
安全 Security
確認email（Confirm emails）: 使用者註冊時，系統應該給他傳送包含一個連結地址的email，使用者則需要開啟該連結以確認他們的email。如果使用者中途需要更新他們的email, 應該重新發起該流程。
身份管理（Identity Management）：當需要儲存密碼時， 首先應該使用現有被廣泛使用的加密庫對它們進行鹽值化和雜湊加密。如果你碰巧不用考慮身份管理，可以把它外發給Facebook/GitHub/Twitter/等。而僅在自己的應用中使用OAuth認證流程。
加密（Encryption）：權衡各種證照使用過程中所遇到的問題，還沒有哪一種方案優於SSL。所以直接使用它就可以了。同時， 請使用HSTS來保障應用的安全。
憑證（Credentials）：不要把任何伺服器憑證（API keys， 資料庫密碼，等等）提交到原始碼控制系統中。
工程：動畫 Eng:Animations
好鋼用在刀刃上，所以不要把應用中所有東西都變成動畫。大部分CSS動畫都會觸釋出局重繪；在transform和opacity屬性的使用上最好保持克制。
避免因使用transition屬性而引發惰性計算，如果你必須使用它們，請確保儘量使用更加明確的屬性（例如，使用"transition: opacity 250ms ease-in"而不是"transition: all 250ms ease-in"）
使用者體驗 UX
表單（Forms）：提交表單時，應該給使用者一個反饋。如果提交動作不需要把使用者引導到另一個頁面，應該彈框並給使用者一些提示資訊，讓他們知道本次提交是成功還是失敗。
登入重定向（Login redirects）：如果使用者尚未登入就訪問網站的某一個頁面，應該將其重定向到登入頁面，登入成功後再將其重定向回原先的頁面（當然，這裡假設他們已經獲得相應的許可權）。
如果使用者登入時輸入了錯誤的密碼，應為其提供明顯的線索，提醒他如果忘記密碼可以進行密碼重置。
訂閱設定（Subscription settings）：向使用者傳送任何郵件都應該至少包含一個用於修改郵件設定的頁面連結，最好再包含一個連結以便使用者可以取消郵件訂閱。
不要讓使用者通過給你發郵件的方式來取消郵件訂閱。
移動裝置 Mobile
也許你並不需要針對移動裝置進行開發，但是不管怎麼樣，都應該確保你所做的決定是主動的。因為它對應用的設計和工程方面都會產生實質性的影響。
以下所列事項假定你選擇了移動裝置作為應用的其中一個目標平臺。因為我恰巧使用了Grunt作為我的構建工具，所以我囊括了一些我所使用的Grunt特有的外掛，但是很可能類似的外掛也存在於你所使用的JavaScript構建工具中。
工程 Engineering
單頁面應用（Single Page Apps）：如今單頁面應用（SPA）才是王道。SPA最大的優勢是更少的全頁面載入—只在需要的時候載入資源，而無需不斷地重複載入相同的資源。如果你新啟動一個web應用專案，那它就該是一個SPA。
使用者介面 UI
解析度（Resolutions）：如果你只是在發展自己的MVP使用者，不需要保證你的使用者介面能夠正常展現在所有的移動裝置上。但是，應該確保它們在常見手機和平板裝置的解析度下能正常顯示。待你的應用成為一個成熟的產品再考慮所有型別的裝置—我們要適應市場需求。
使用者體驗：頻寬 UX： Bandwidth
移動裝置最大的主題之一就是頻寬相對於桌面應用來說是更寶貴的資源。因此， 應該抓住每個機會減少請求的數量，如果情況允許，將它們變成非同步請求，並儘可能減少每次所請求資源的大小。
JS & CSS—合併及最小化（JS & CSS - Concat and minify）：應該將應用相關的JavaScript 和 CSS 檔案合併到單獨的檔案中（JS合併到一個檔案中，CSS合併到另一個檔案中 ）並將它們進行最小化處理。Grunt-contrib-concat, Grunt-contrib-cssmin 和 Grunt-contrib-uglify是這方面的好幫手。
所有資產—使用CDN（All assets - Use a CDN）：使用CDN能在兩個方面帶來很大的好處。第一個好處對所有的資產都適用，它就是本地化—CDN可以保證它所承載的資源在地理位置上離使用者更近，從而減少載入時間。
第二個好處更適用於應用的依賴（例如， 非應用相關的樣式和JS程式碼）。在這裡，使用CDN可以使得使用者裝置能夠從其快取中載入資源從而大大減少載入時間。例如，很多網站都依賴Angular.js， 使用CDN連結到Angular核心程式碼會觸發快取命中， 此時使用者裝置將從其快取中將它讀取出來使用，而不是通過發起一個額外的HTTP請求將它從伺服器上獲取下來。
CSS—儘量減少腳印（CSS - Reduce your footprint）：大部分開發者在開發他們的應用時，很有可能會使用一些UI框架（例如，Bootstrap， Foundation， 等等）。這些框架往往都很大，雖然可以從CDN上得到它們的最小化版本，但是不可能保證所有被包含進來的樣式都會被使用。因此，使用一些類似uncss（通常和processhtml一起配套使用）的工具移除那些沒有被使用到的樣式對我們來說顯然非常有價值。
但是請注意uncss解析器不能識別動態樣式（那些只對JavaScript事件起作用的樣式），因此需要在瀏覽器中進行嚴格的測試以確保它不會誤刪有用的樣式。
CSS—把重要的東西放在頭部（CSS - Put crucial things in the head）：把那些在應用完成載入前就需要用到的樣式放到頭部；那些沒那麼重要的樣式可以稍後再載入。
JS—儘量減少腳印（JS - Reduce your footprint）：一旦你的應用進入到產品階段， JavaScript程式碼內部的變數對終端使用者來說是毫無意義的，因此， 把變數user.email換成u.e可以在很大程度上減少檔案大小。很慶幸，有一個工具可以為我們完成這項任務—前面提到的uglify，它將JS程式碼打亂成人無法理解的形式，但是卻極大地減小了程式碼的尺寸。
使用者體驗：表單 UX：Forms
儘量讓表單和工作流程保持簡單，如果你把移動裝置作為目標平臺的話這點尤為重要。沒有人願意在他們的iPhone上填寫一份長達5頁的表單。
完整內容點此檢視