東莞網(wǎng)站建設(shè)專家分享：可簡單避免的三個(gè)JS發(fā)布錯(cuò)誤

       Web應(yīng)用程序開發(fā)是傾向于在客戶端運(yùn)行所有用戶邏輯和交互代碼，讓服務(wù)器暴露REST或者RPC接口。編譯器是針對JS作為一個(gè)平臺,第二版ECMAScript正是考慮到這一點(diǎn)在設(shè)計(jì)?？蛻舳丝蚣芾?span lang="EN-US">Backbone, Ember和Require鼓勵(lì)創(chuàng)建功能豐富的應(yīng)用程序，不僅有豐富的代碼，而且各個(gè)組件，組件與數(shù)據(jù)之間有很多相互作用。

      這真的很好，或許還能產(chǎn)生一些優(yōu)秀的用戶體驗(yàn)，但是毫無疑問的是，這是很難開發(fā)web應(yīng)用程序和web頁面。

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

      我想強(qiáng)調(diào)的是三個(gè)相對常見的錯(cuò)誤和容易的解決方案，并且談?wù)勔恍┪覀冇龅降膹?span lang="EN-US">ReadyForZero學(xué)到的特別的事情。

      剝離“緩存清除”頭信息

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

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

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

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

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

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

      ·CDN把這個(gè)請求傳給了你設(shè)置的custom origin， 碰巧這個(gè)請求發(fā)到了服務(wù)器B上。

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

      ·CDN把舊版的的文件當(dāng)新的緩存了。

      這件事情考慮起來很簡單明了，但是盲目的聽從網(wǎng)絡(luò)上的建議很可能導(dǎo)致錯(cuò)誤。更糟糕的是在你這看起來一切都是好的你根本不知道發(fā)生了錯(cuò)誤，但是其它地區(qū)的用戶使用了不同CDN很可能緩存了錯(cuò)誤的版本。解決方案是不要?jiǎng)冸x“緩存清除”字符串并將靜態(tài)資源存放在能夠正確支持各個(gè)版本的地方。

      2. 處理龐大的JS炸彈

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

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

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

      3. 沒有匯總錯(cuò)誤事件

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

      棘手的部分是，很多時(shí)候會出現(xiàn)一些非0的錯(cuò)誤，因?yàn)橛脩艨赡馨惭b了各種怪異的插件或者其他。所以你需要跟蹤穩(wěn)定的狀態(tài)到底是什么，還有是否有任何的偏差。

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

      垂手可得的改進(jìn)

      令人沮喪的是下面這些點(diǎn)不是我們必須擔(dān)心的。公司更應(yīng)該關(guān)注在產(chǎn)品上，快速高質(zhì)量地把它們弄出來。但是請記住如果這些垂首可得的改進(jìn)獲得實(shí)施，你將能更專注于大動(dòng)作上。

      人們總是被一些瑣事糾纏住花費(fèi)了大量時(shí)間，但是僅僅讓你的應(yīng)用正常運(yùn)行就能獲得大的成長。

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

      2，在ReadyForZero[注1]我們有很多聰明的人們致力于推動(dòng)這門藝術(shù)。

      [注1]ReadyForZero：是由 Y Combinator資助的一家公司，公司的目的是通過網(wǎng)絡(luò)平臺幫助消費(fèi)者擺脫信用卡債務(wù)。

 文章由東莞網(wǎng)站建設(shè)專家推薦， 如需轉(zhuǎn)載請注明出處。

想要建營銷型網(wǎng)站，請點(diǎn)擊進(jìn)入捷聯(lián)營銷型網(wǎng)站：http://www.financeideaszone.com/Website/