Web應用程序開發是傾向于在客戶端運行所有用戶邏輯和交互代碼，讓服務器暴露REST或者RPC接口。編譯器是針對JS作為一個平臺,第二版ECMAScript正是考慮到這一點在設計。客戶端框架例如Backbone, Ember和Require鼓勵創建功能豐富的應用程序，不僅有豐富的代碼，而且各個組件，組件與數據之間有很多相互作用。

這真的很好，或許還能產生一些優秀的用戶體驗，但是毫無疑問的是，這是很難開發web應用程序和web頁面。

根本原因是在互聯網上服務你的代碼和數據，運行在一些隨機的瀏覽器上，在javascript中，這是一種你需要特別小心的語言，它是一個完全缺乏代碼部署的平臺。而且它不會很快就得到改善。我覺得如果星際迷航是現實生活，那么Jean-Luc Picard隊長每隔一段時間不能打架的原因是他仍然是克林儀表板加載。

我想強調的是三個相對常見的錯誤和容易的解決方案，并且談談一些我們遇到的從ReadyForZero學到的特別的事情。

剝離“緩存清除”頭信息

你可能使用CDN來緩存靜態資源，這當然是合理的。如果你向服務器請求非緩存的資源（比如在AWS<Amazon Web Service>端使用"custom-origin"將文件指向真實的網絡站點），這就需要小心了。你可能會在部署新版本的文件后添加一段緩存清除的字符串（頭信息）到文件名上來達到這個目的，這樣你的文件名看起來是這樣的：

http://example.com/js/main__V0123456789abcdef__.js

這很容易做到，你可以選擇任意的Hash算法來生成一段指紋信息作為這個字符串，這樣它就會隨著文件內容變化而變化。當新的url被引用時，它不可能被緩存，這樣就可以獲取到服務器上的新版本。錯誤就發生在這里。在網絡上有很多都建議剝離“緩存清除”頭信息，而是讓你的服務器直接提供新版本的文件。如果你有多臺服務器集群這可能導致你的站點上不同文件（如：html、js）的版本不一致（如js已更新但是html（從另一臺服務器請求）仍然是舊的），不僅如此，更嚴重是它很容易導致CDN緩存了錯誤的版本。這個錯誤是這樣發生的：

·初始階段，所有的服務器都是HTML1 和JS1.

·服務器A重啟了，并提供HTML2和JS2.

·一個客戶端向CDN請求main__V2__.js，這個時候這個文件是新的所以CDN上沒有緩存。

·CDN把這個請求傳給了你設置的custom origin， 碰巧這個請求發到了服務器B上。

·服務器B剝離了“緩存清除”字符串并返回舊的版本。

·CDN把舊版的的文件當新的緩存了。

這件事情考慮起來很簡單明了，但是盲目的聽從網絡上的建議很可能導致錯誤。更糟糕的是在你這看起來一切都是好的你根本不知道發生了錯誤，但是其它地區的用戶使用了不同CDN很可能緩存了錯誤的版本。解決方案是不要剝離“緩存清除”字符串并將靜態資源存放在能夠正確支持各個版本的地方。

2. 處理龐大的JS炸彈

每個人都知道，我們需要壓縮我們的javascript文件，并把它們連接在一起。但是盲目地這樣做并非明智之舉。如果連接的文件很大，那么更有效的方法就是并行化。另外，如果你需要頻繁的修改文件的某一部分，你可能會導致很多地方失效，而文件很大部分卻沒有被修改過。

如果把頻繁修改的部分分離出來，那么就可以解決兩邊的問題。我建議使用require.js - 它可以實現對你的javascript的真正的依賴關系管理，而且第一次使用的時候，設置很簡單（稍后添加會很痛苦），而且可以幫助你理解和管理依賴關系，包括一些高級選項，例如異步載入。

需要注意的：require.js會等待一段時間后會放棄載入資源，這個可以通過指定waitSeconds選項實現，這個選項的默認值似乎7秒，它依賴于你的用戶在哪里（例如：手機），可以是很短的時間。

3. 沒有匯總錯誤事件

你不能只讓你的javascript上線使用，而不關心它的運行情況。你不可能測試每一個瀏覽器和每個用戶的狀態組合。另外，不同的載入時間可能導致怪異的狀態。所以，建立某種反饋機制來判斷你的用戶是否遇到錯誤，變得十分重要。這很簡單，你只需通過指定一個全局錯誤處理程序，收集錯誤，并發送會服務器。以下是一個例子：

window.onerror = function(message, url, linenumber) {  
    sendToServer({message: message, line: linenumber, url: url});  
} 

棘手的部分是，很多時候會出現一些非0的錯誤，因為用戶可能安裝了各種怪異的插件或者其他。所以你需要跟蹤穩定的狀態到底是什么，還有是否有任何的偏差。

ReadyForZero，我們在頂層捕獲onError事件，并把它們發送會服務器，然后生成一個日報，匯總多少個用戶發生了錯誤，和這些錯誤發生在哪里。我們發現很多時候，錯誤消息并不足夠，所以我們同樣需要從我們的事件系統回傳最后幾個事件。通過分析用戶最近觸發的Backbone或者JQuery事件，對于獲取當時用戶觸發錯誤時候的上下文信息，有很大的幫助。

垂手可得的改進

令人沮喪的是下面這些點不是我們必須擔心的。公司更應該關注在產品上，快速高質量地把它們弄出來。但是請記住如果這些垂首可得的改進獲得實施，你將能更專注于大動作上。

人們總是被一些瑣事糾纏住花費了大量時間，但是僅僅讓你的應用正常運行就能獲得大的成長。

1，你的客戶端代碼有沒有內存泄露？你確定嗎？你是怎么知道的？

2，在ReadyForZero[注1]我們有很多聰明的人們致力于推動這門藝術。

[注1]ReadyForZero：是由 Y Combinator資助的一家公司，公司的目的是通過網絡平臺幫助消費者擺脫信用卡債務。

原文鏈接：http://www.oschina.net/translate/client-side-complexity