web應用程式開發是傾向於在客戶端執行所有使用者邏輯和互動**，讓伺服器暴露rest或者rpc介面。編譯器是針對js作為乙個平台,第二版ecmascript正是考慮到這一點在設計。客戶端框架例如backbone, ember和require鼓勵建立功能豐富的應用程式，不僅有豐富的**，而且各個元件，元件與資料之間有很多相互作用。
這真的很好，或許還能產生一些優秀的使用者體驗，但是毫無疑問的是，這是很難開發web應用程式和web頁面。
根本原因是在網際網路上服務你的**和資料，執行在一些隨機的瀏覽器上，在j**ascript中，這是一種你需要特別小心的語言，它是乙個完全缺乏**部署的平台。而且它不會很快就得到改善。我覺得如果星際迷航是現實生活，那麼jean-luc picard隊長每隔一段時間不能打架的原因是他仍然是克林儀表板載入。
我想強調的是三個相對常見的錯誤和容易的解決方案，並且談談一些我們遇到的從readyforzero學到的特別的事情。
剝離「快取清除」頭資訊
你可能使用cdn來快取靜態資源，這當然是合理的。如果你向伺服器請求非快取的資源（比如在aws端使用"custom-origin"將檔案指向真實的網路站點），這就需要小心了。你可能會在部署新版本的檔案後新增一段快取清除的字串（頭資訊）到檔名上來達到這個目的，這樣你的檔名看起來是這樣的：
這很容易做到，你可以選擇任意的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炸彈
每個人都知道，我們需要壓縮我們的j**ascript檔案，並把它們連線在一起。但是盲目地這樣做並非明智之舉。如果連線的檔案很大，那麼更有效的方法就是並行化。另外，如果你需要頻繁的修改檔案的某一部分，你可能會導致很多地方失效，而檔案很大部分卻沒有被修改過。
如果把頻繁修改的部分分離出來，那麼就可以解決兩邊的問題。我建議使用require.js - 它可以實現對你的j**ascript的真正的依賴關係管理，而且第一次使用的時候，設定很簡單（稍後新增會很痛苦），而且可以幫助你理解和管理依賴關係，包括一些高階選項，例如非同步載入。
需要注意的：require.js會等待一段時間後會放棄載入資源，這個可以通過指定waitseconds選項實現，這個選項的預設值似乎7秒，它依賴於你的使用者在**（例如：手機），可以是很短的時間。
3. 沒有彙總錯誤事件
你不能只讓你的j**ascript上線使用，而不關心它的運**況。你不可能測試每乙個瀏覽器和每個使用者的狀態組合。另外，不同的載入時間可能導致怪異的狀態。所以，建立某種反饋機制來判斷你的使用者是否遇到錯誤，變得十分重要。這很簡單，你只需通過指定乙個全域性錯誤處理程式，收集錯誤，並傳送會伺服器。以下是乙個例子：
棘手的部分是，很多時候會出現一些非0的錯誤，因為使用者可能安裝了各種怪異的外掛程式或者其他。所以你需要跟蹤穩定的狀態到底是什麼，還程式設計客棧有是否有任何的偏差。
readyforzero，我們在頂層捕獲onerror事件，並把它們傳送會伺服器，然後生成乙個**，彙總多少個使用者發生了錯誤，和這些錯誤發生在**。我們發現很多時候，錯誤訊息並不足夠，所以我們同樣需要從我們的事件系統回傳最後幾個事件。通過分析使用者最近觸發的backbone或者jquery事件，對於獲取當時使用者觸發錯誤時候的上下文資訊，有很大的幫助。
垂手可得的改進
令人沮喪的是下面這些點不是我們必須擔心的。公司更應該關注在產品上，快速高質量地把它們弄出來。但是請記住如果這些垂首可得的改進獲得實施，你將能更專注於大動作上。
人們總是被一些瑣事糾纏住花費了大量時間，但是僅僅讓你的應用正常執行就能獲得大的成長。
1，你的客戶端**有沒有記憶體洩露？你確定嗎？你是怎麼知道的？
2，在readyforzero[注1]我們有很多聰明的人們致力於推動這門藝術。
[注1]readyforzero：是由 y combinator資助的一家公司，公司的目的是通過網路平台幫助消費者擺脫信用卡債務。
本文標題: 可簡單避免的三個js發布錯誤
本文位址: /news/exp/48680.html
避免馬虎的三個方法
每個人都會有馬虎的時候，對於程式設計師來說，bug簡直是家常便飯，但是如果能避免一些馬虎產生的bug，效率定會提公升不少，那麼應該怎麼做呢？首先，造成馬虎的原因不是沒有想到，每個人都不是盡善盡美的，每個人考慮問題都會有疏漏。不能以沒有想到或者意想不到去開脫。接下來分析馬虎的三個具體原因 第乙個原因 ...
三個簡單的排序
氣泡排序 從第乙個元素開始,和它右邊的哪個元素比較,如果它比右邊的哪個元素大的話,就交換位置,經過第一次後,最右邊的那個元素,就是最大的哪個元素.第二次同樣,從第一元素開始,但是比較到倒數第二個元素,這樣右邊第二個元素就是第二高的元素.依次這樣下去,每次比較的結束值就是,比上一次小乙個,直到結束的標...
棧的三個簡單應用
根據真題需求，主要再回顧一下棧在括號匹配 表示式求值和共享棧的運用。問題描述 演算法思想 若是左括號，入棧 若是右括號，出棧乙個左括號判 斷是否與之匹配 檢驗到字串尾時，還要檢查棧是否為空，只有棧空，整個字串才是括號匹配的。演算法實現 bool check char str sharestack 棧...