前端優秀實踐之可維護性
在早期網站中，JavaScript主要用于實現一些小型動效或表單驗證。今天的Web應用則動輒成千上萬行JavaScript代碼，用于完成各種各樣復雜的處理。這些變化要求開發者把可維護能力放到重要位置上。正如更傳統意義上的軟件工程師一樣，JavaScript工程師受雇是要為公司創造價值的。現代前端工程師的使命，不僅僅是要保證產品如期上線，更重要的是要隨著時間推移為公司不斷積累知識資產。
編寫可維護的代碼十分重要，因為很多開發者都會花大量時間去維護別人寫的代碼。實際開發中，從第一行代碼開始寫起的情況是非常少見的。通常都是要在別人的代碼之上來構建自己的工作。讓自己的代碼容易維護，可以保證其他開發者更好地完成自己的工作。
注意：可維護代碼的概念并不止適用于JavaScript，其中很多概念適用于任何編程語言。當然，有部分概念可能確實是特定于JavaScript的。
1. 什么是可維護的代碼
可維護的代碼有幾個特點。通常，說代碼可維護就意味著它具備如下特點。
- 容易理解：無需求助原始開發者，任何人一看代碼就知道是干什么的，怎么實現的。
- 符合常識：代碼中的一切都顯得自然而然，無論操作有多么復雜。
- 容易適配：即使數據發生變化也不用完全重寫。
- 容易擴展：代碼架構經過認真設計，支持未來擴展核心功能。
- 容易調試：出問題時，代碼可以給出明確的信息，通過它能直接定位問題。
能夠寫出可維護的JavaScript代碼是一項重要的專業技能。這個技能是一個周末就拼湊一個網站的業余愛好者和對自己所做的一切都深思熟慮的專業開發者的重要區別。
2. 編碼規范
編寫可維護代碼的第一步是認真考慮編碼規范。編碼規范在多數編程語言中都會涉及，簡單上網一搜，就可以找到成千上萬的相關文章。專業組織都會有為開發者建立的編碼規范，旨在讓人寫出更容易維護的代碼。優秀開源項目都有嚴格的編碼規范，能夠讓社區的所有人容易理解代碼的組織。
編碼規范對JavaScript而言非常重要，因為這門語言實在太靈活了。與多數面向對象語言不同，JavaScript并不強迫開發者把任何東西都定義為對象。相反，JavaScript支持任何編程風格，包括傳統的面向對象編程和聲明式編程，以及函數式編程。簡單看幾個開源的JavaScript庫，就會發現有很多方式可以創建對象、定義方法和管理環境。
接下來的幾節會討論制定編碼規范的一些基礎方面。這些主題都很重要，當然每個人的需求不同，實現方式也可以不同。
2.1 可讀性
要想讓代碼容易維護，首先必須讓人容易看懂?？勺x性必須考慮代碼是一種文本文件。為此，代碼縮進是保證可讀性的重要基礎。如果所有人都使用相同的縮進，整個項目的代碼就會更容易看懂?？s進通常要使用空格數而不是Tab(制表符)來定義，因為后者在不同文本編輯器中的顯示會有差異。一般來說，縮進都是以4個空格為單位，當然具體多少個可以自己定。
可讀性的另一方面是代碼注釋。在多數編程語言中，廣泛接受的做法是為每個方法都編寫注釋。由于JavaScript可以在代碼中任何地方創建函數，所以這一點容易被忽視。正因為如此，可能給JavaScript中的每個函數都寫注釋才更重要。一般來說，以下這些地方都是應該寫注釋的。
- 函數和方法。每個函數和方法都應該有注釋來描述其用途，以及完成任務所用的算法。同時，也寫清使用這個函數或方法的前提(假設)、每個參數的含義，以及函數是否返回值(因為通過函數定義看不出來)。
- 大型代碼塊。多行代碼但用于完成單一任務的，應該在前面給出注釋，把要完成的任務寫清楚。
- 復雜的算法。如果使用了不同尋常的手法解決了問題，要通過注釋解釋明白。這樣不僅可以幫到別人，也可以讓自己今后再看的時候更快想起來。
- 使用黑科技。由于瀏覽器之間的差異，JavaScript代碼中通常都會包含一些黑科技。不要假設其他人一看就能明白某個黑科技是為了解決某個瀏覽器的什么問題。如果對某個瀏覽器不能使用正常方式達到目的，那要在注釋里把黑科技的用途寫出來。這樣可以避免別人誤以為黑科技沒有用而把它“修復”掉，結果你已經修好的問題又會復現。
縮進和注釋可以讓代碼更容易理解，將來也更容易維護。
2.2 變量和函數命名
變量和函數的適當命名對于可讀性和可維護性也是至關重要的。由于很多JavaScript開發者都是“草莽”出身，所以很容易用foo、bar命名變量，用doSomething來命名函數。專業JavaScript開發者必須改掉這些積習，這樣才能寫出可維護的代碼。以下是關于命名的通用規則。
- 變量名應該是名詞，例如car或person。
- 函數名應該以動詞開始，例如getName()。返回布爾值的函數通常以is開頭，比如isEnabled()。
- 對變量和函數都使用符合邏輯的名字，不用擔心長度。長名字的問題可以通過后處理和壓縮解決。
- 變量、函數和方法應該以小寫字母開頭，使用駝峰大小寫形式，如getName()和isPerson。類名應該首字母大寫，比如Person、RequestFactory。常量值應該全部大寫并以下劃線相接，比如REQUEST_TIMEOUT。
- 名字要盡量用描述性和直觀的詞匯，但不要過于冗長。getName()一看就知道會返回名字，而PersonFactory一看就知道會產生某個Person對象或實例。
要完全避免沒有用的變量名，比如不能表示所包含數據的類型。通過適當命名，代碼讀起來就會像故事，因此更容易理解。
2.3 變量類型透明化
因為JavaScript是松散類型的語言，所以很容易忘記變量包含的數據類型。適當命名可以在某種程度上解決這個問題，但還不夠。有三種方式可以表明變量的數據類型。
第一種方式是通過初始化。定義變量時，應該立即將其初始化為一個將來要使用類型的值。例如，要保存布爾值的變量可以將其初始化為true或false，而要保存數值的變量可以將其初始化為一個數值。再看幾個例子：
- // 通過初始化表明變量類型
- let found = false; // Boolean
- let count = -1; // number
- let name = ""; // string
- let person = null; // object
初始化為特定數據類型的值可以明確表示變量的類型。在ES6之前，初始化方式不適合函數聲明中函數的參數。ES6之后，可以在函數聲明中為參數指定默認值來表明參數類型。
第二種表示變量類型的方式是使用匈牙利表示法。匈牙利表示法指的是在變量名前面前綴一個或多個字符表示數據類型。這種表示法曾經在腳本語言中非常流行，很長時間以來也是JavaScript首選的格式。對于基本數據類型，用o表示對象(object)、s表示字符串(string)，i表示整數(integer)，f表示浮點數(float)、b表示布爾值(boolean)。下面看幾個例子。
- // 使用匈牙利表示法標明數據類型
- let bFound; // Boolean
- let iCount; // integer
- let sName; // string
- let oPerson; // object
匈牙利表示法也可以應用給函數參數。匈牙利表示法的缺點是讓代碼可讀性有所下降，不夠直觀，破壞了類似句子的自然閱讀流暢性。為此，匈牙利表示法已經被很多開發者拋棄。
最后一種表明數據類型的方式是使用類型注釋。類型注釋放在變量名后面，初始化表達式的前面?；舅悸肥窃谧兞颗赃吺褂米⑨屨f明類型，比如：
- // 使用類型注釋標明數據類型
- let found /*:Boolean*/ = false;
- let count /*:int*/ = 10;
- let name /*:String*/ = "Nicholas";
- let person /*:Object*/ = null;
類型注釋在保持整體可讀性的同時向代碼中注入了類型信息。類型注釋的缺點是不能再使用多行注釋把大型代碼塊注釋掉了。因為類型注釋也是多行注釋，因此會造成干擾，如下面的例子所示：
- // 這樣多行注釋不會生效
- /*
- let found /*:Boolean*/ = false;
- let count /*:int*/ = 10;
- let name /*:String*/ = "Nicholas";
- let person /*:Object*/ = null;
- */
這里本來是想使用多行注釋把所有變量聲明都注釋掉。但類型注釋產生了干擾，因為第一個/*(第2行)會與第一個*/(第3行)匹配，結果會導致語法錯誤。如果想注釋掉包含類型注釋的代碼，只能使用單行注釋一行一行地注釋掉每一行(有的編輯器可以自動完成)。
以上是三種標明變量數據類型的最常用方式。每種方式都有優點和缺點，可以根據自己的情況選用。關鍵要看哪一種最適合自己的項目，并保證一致性。
3. 松散耦合
只要應用的某個部分對另一個部分依賴得過于緊密，代碼就會變成強耦合，因而難以維護。典型的問題是在一個對象中直接引用另一個對象。這樣，修改其中一個，可能必須還得修改另一個。緊密耦合的軟件難于維護，肯定需要頻繁地重寫。
考慮到相關的技術，Web應用在某些情況下可能變得過于強耦合。關鍵在于有這個意識，隨時注意不要讓代碼產生強耦合。
3.1 解耦HTML/JavaScript
Web開發中最常見的耦合是HTML/JavaScript耦合。在網頁中，HTML和JavaScript分別代表不同層面的解決方案。HTML是數據，JavaScript是行為。因為它們之間要交互操作，需要通過不同的方式將這兩種技術聯系起來?？上У氖?，其中一些方式會導致HTML與JavaScript強耦合。
把JavaScript直接嵌入在HTML中，包括使用<script>元素包含嵌入代碼或使用HTML屬性添加事件處理程序，都會造成強耦合。比如下面的例子：
- <!-- 使用<script>造成HTML/JavaScript強耦合 -->
- <script>
- document.write("Hello world!");
- </script>
- <!-- 使用事件處理程序屬性造成HTML/JavaScript強耦合 -->
- <input type="button" value="Click Me" onclick="doSomething()"/>
雖然技術上這樣做沒有問題，但實踐中這樣會導致HTML的數據與JavaScript的行為緊密耦合在一起。理想情況下，HTML和JavaScript應該完全分開，通過外部文件引入JavaScript，然后使用DOM添加行為。
HTML與JavaScript強耦合的情況下，每次分析JavaScript的報錯都要首先確定錯誤來自HTML還是JavaScript。而且，這樣也會引入代碼可用性的新錯誤。在這個例子中，用戶可能會在doSomething()函數可用之前點擊按鈕，從而導致JavaScript報錯。由于每次修改按鈕的行為都需要既改HTML又改JavaScript，而實際上只有后者才是有必要修改的。這樣就會降低代碼的可維護性。
在相反的情況下，HTML和JavaScript也會變得強耦合：把HTML包含在JavaScript中。這種情況通常發生在把一段HTML通過innerHTML插入到頁面中，比如：
- // HTML緊耦合到了JavaScript
- function insertMessage(msg) {
- let container = document.getElementById("container");
- container.innerHTML = `<div class="msg">
- <p> class="post">${msg}</p>
- <p><em>Latest message above.</em></p>
- </div>`;
- }
一般來說，應該避免在JavaScript中創建大量HTML。同樣，這主要是為了做到數據層和行為層各司其職，在出錯時更容易定位問題所在。如果使用上面的代碼示例，那么如果動態插入的HTML格式不對，就會造成頁面布局出錯。但在這種情況下定位錯誤就更困難了。因為這時候通常首先會去找頁面中出錯的HTML源代碼，但又找不到，因為它是動態生成的。而且修改數據或頁面，還需要修改JavaScript，這說明兩層是緊密耦合的。
HTML渲染應該盡可能與JavaScript分開。在使用JavaScript插入數據時，應該盡可能不要插入標記。相應的標記可以包含并隱藏在頁面中，在需要的時候JavaScript可以直接用它來顯示，而不需要動態生成。另一個辦法是通過Ajax請求獲取要顯示的HTML，這樣也可以保證同一個渲染層(PHP、JSP、Ruby等)負責輸出標記，而不是把標記嵌在JavaScript中。
解耦HTML和JavaScript可以節省排錯時間，因為更容易定位錯誤來源。同樣解耦也有助于保證可維護性，對行為的修改只涉及JavaScript，而對標記的修改則只涉及要渲染的文件。
3.2 解耦CSS/JavaScript
Web應用的另一層是CSS，主要負責頁面的外觀。JavaScript和CSS是緊密相關的，它們都是建構在HTML之上的，因此也經常一起使用。與HTML和JavaScript的情況類似，CSS也可能與JavaScript產生強耦合。最常見的例子就是使用JavaScript修改個別樣式，比如：
- // CSS緊耦合到了JavaScript
- element.style.color = "red";
- element.style.backgroundColor = "blue";
因為CSS負責頁面外觀，任何樣式的問題都應該通過CSS文件解決。可是，如果JavaScript直接修改個別樣式(比如顏色)，就會增加一個排錯時要考慮甚至要修改的因素。結果是JavaScript某種程度上承擔了頁面顯示的任務，與CSS搞成了緊密耦合。如果將來有一天要修改樣式，那么CSS和JavaScript都需要修改。這對負責維護的開發者來說是一個惡夢。層與層的清晰解耦是必需的。
現代Web應用經常使用JavaScript改變樣式，因此雖然不太可能完全解耦CSS和JavaScript，但可以讓這種耦合變成更松散。這主要可以通過動態修改類名而不是樣式來實現，比如：
- // CSS與JavaScript松散耦合
- element.className = "edit";
通過修改元素的CSS類名，可以把大部分樣式限制在CSS文件里。JavaScript只負責修改應用樣式的類名，而不直接影響元素的樣式。只要應用的類名沒錯，那么外觀的問題就只跟CSS有關，而跟JavaScript無關。
同樣，保證層與層之間的適當分離是至關重要的。顯示出問題就只應該去CSS里解決，行為出問題就只應該找JavaScript的問題。這些層之間的松散耦合可以提升整個應用的可維護性。
3.3 解耦應用邏輯/事件處理程序
每個Web應用中都會有大量事件處理程序在監聽各種事件?？墒牵渲泻苌儆姓嬲龅綉眠壿嬇c事件處理程序分離的。來看下面的例子：
- function handleKeyPress(event) {
- if (event.keyCode == 13) {
- let target = event.target;
- let value = 5 * parseInt(target.value);
- if (value > 10) {
- document.getElementById("error-msg").style.display = "block";
- }
- }
- }
這個事件處理程序除了處理事件，還包含了應用邏輯。這樣做的問題是雙重的。首先，除了事件沒有辦法觸發應用邏輯，結果造成調試困難。如果沒有發生預期的結果怎么辦?是因為沒有調用事件處理程序，還是因為應用邏輯有錯誤?其次，如果后續事件也會對應相同的應用邏輯，就會導致代碼重復，否則就要把它提取到一個函數中。無論如何，都會導致原本不必要的多余工作。
更好的做法是將應用邏輯與事件處理程序分開，各自只負責處理各自的事情。事件處理程序應該專注于event對象的相關信息，然后把這些信息傳給處理應用邏輯的某些方法。例如，前面的例子可以重寫成這樣：
- function validateValue(value) {
- value = 5 * parseInt(value);
- if (value > 10) {
- document.getElementById("error-msg").style.display = "block";
- }
- }
- function handleKeyPress(event) {
- if (event.keyCode == 13) {
- let target = event.target;
- validateValue(target.value);
- }
- }
這樣修改之后，應用邏輯跟事件處理程序就分開了。handleKeyPress()函數只負責檢查用戶是不是按下了回車鍵(event.keyCode等于13)，如果是則取得事件目標，并把目標的值傳給validateValue()函數，由該函數處理應用邏輯。注意，validateValue()函數中不包含任何依賴事件處理程序的代碼。這個函數只負責接收一個值，然后可以對這個值做任何處理。
把應用邏輯從事件處理程序中分離出來有很多好處。首先，可以方便地修改觸發某個流程的事件。如果原來是通過鼠標單擊觸發流程，而現在又想增加鍵盤操作來觸發，那么修改起來也很簡單。其次，可以在不用添加事件的情況下測試代碼，這樣創建單元測試甚至與應用自動化整合都會更簡單。
以下是在解耦應用和業務邏輯時應該注意的幾點。
- 不要把event對象傳給其他方法，而是只傳遞event對象中必要的數據。
- 應用中每個可能的操作都應該無需事件處理程序就可以執行。
- 事件處理程序應該處理事件，而把后續處理交給應用邏輯。
做到上述幾點能夠給任何代碼的可維護性帶來巨大的提升，同時也能為將來的測試和開發提供很多可能性。
4. 編碼慣例
編寫可維護的JavaScript不僅僅涉及代碼格式和規范，也涉及代碼做什么。大企業開發Web應用通常需要很多人協同工作。這時候就需要保證每個人的瀏覽器環境都有恒定不變的規則。為此，開發者應該遵守某些編碼慣例。
4.1 尊重對象所有權
JavaScript的動態天性意味著幾乎可以在任何時候修改任何東西。過去有人說，JavaScript中沒有什么是神圣不可侵犯的，因為不能把任何東西標記為最終結果或者恒定不變。但ECMAScript 5引入防篡改對象之后，情況不同了。當然，對象默認還是可以修改的。在其他語言中，在沒有源代碼的情況下對象和類都是不可修改的。JavaScript則允許在任何時候修改任何對象，因此就可能導致意外地覆蓋默認行為。既然這門語言沒有什么限制，那就需要開發者自己限制自己。
在企業開發中，可能最最重的編碼慣例就是尊重對象所有權，這意味著不要修改不屬于你的對象。簡單地講，如果你不負責創建和維護某個對象，包括它的構造函數或它的方法，就不應該對它進行任何修改。更具體一點說，就是：
- 不要給實例或原型添加屬性
- 不要給實例或原型添加方法
- 不要重定義已有的方法
問題在于，開發者會假設瀏覽器環境以某種方式運行。修改了多個人使用的對象也就意味著會有錯誤發生。如果有人希望某個函數叫stopEvent()，用于取消某個事件的默認行為。然后，你把它給改了，除了取消事件的默認行為，又添加了其他事件處理程序?？上攵瑔栴}肯定會接踵而至。別人還會認為這個函數只做最開始的那點事，由于對它后來添加的副作用并不知情，很可能會用錯或者造成損失。
以上規則不僅適用于自定義類型和對象，同樣適用于原生類型和對象，比如Object、String、document、window，等等?？紤]到瀏覽器廠商也有可能會在不宣布的情況下以非預期方式修改這些對象，那么潛在的風險就更大了。
以前有一個流行的Prototype庫就發生過類似事件。當時，這個庫在document對象上實現了getElementsByClassName()方法，返回一個Array的實例，而這個實例上還增加了each()方法。jQuery的作者John Resig后來在自己的博客上分析了這個問題造成的影響。他在博客中(https://johnresig.com/blog/getelementsbyclassname-pre-prototype-16/)指出這個問題是由于瀏覽器也原生實現了相同的getElementsByClassName()方法造成的。但Prototype的同名方法返回的是Array而非NodeList，后者沒有each()方法。使用這個庫的開發者之前會寫這樣的代碼：
- document.getElementsByClassName("selected").each(Element.hide);
盡管這樣寫在沒有原生實現getElementsByClassName()方法的瀏覽器里沒有問題，但在實現它的瀏覽器里就會出問題。因為兩個同名方法返回的結果不一樣。我們不能預見瀏覽器廠商將來會怎么修改原生對象，因此不管怎么修改它們都可能在將來某個時刻出現沖突時導致問題。
為此，最好的方法是永遠不要修改不屬于你的對象。只有你自己創建的才是你的對象，包括自定義類型和對象字面量。Array、document等這些都不是你的，因為在你的代碼執行之前它們已經存在了?？梢赃@樣為對象添加新功能：
- 創建包含想要功能的新對象，通過它與別人的對象交互。
- 創建新自定義類型繼承本來想要修改的類型，給自定義類型添加新功能。
很多JavaScript庫目前都贊同這個開發理念，這樣無論瀏覽器怎樣改變都可以發展和適應。
4.2 不聲明全局變量
與尊重對象所有權密切相關的是盡可能不聲明全局變量和函數。同樣，這也關系到創建一致和可維護的腳本運行環境。最多可以創建一個全局變量，作為其他對象和函數的命名空間。來看下面的例子：
- // 兩個全局變量——不要！
- var name = "Nicholas";
- function sayName() {
- console.log(name);
- }
以上代碼聲明了兩個全局變量：name和sayName()。可以像下面這樣把它們包含在一個對象中：
- // 一個全局變量——推薦
- var MyApplication = {
- name: "Nicholas",
- sayName: function() {
- console.log(this.name);
- }
- };
這個重寫后的版本只聲明了一個全局對象MyApplication。在這個對象內部，又包含name和sayName()。這樣可以避免之前版本的幾個問題。首先，變量name會覆蓋window.name屬性，而這可能會影響其他功能。其次，有助于分清功能都集中在哪里。調用MyApplication.sayName()從邏輯上就會暗示出現任何問題，都可以在MyApplication的代碼中找原因。
這樣一個全局對象可以擴展為命名空間的概念。命名空間涉及創建一個對象，然后通過這個對象來暴露能力。比如，Google Closure庫就利用了這樣的命名空間來組織其代碼。下面是幾個例子：
- goog.string：用于操作字符串的方法。
- goog.html.utils：與HTML相關的方法。
- goog.i18n：與國際化(i18n)相關的方法。
對象goog就相當于一個容器，其他對象都包含在這里面。只要使用對象以這種方式來組織功能，就可以稱該對象為命名空間。整個Google Closure庫都構建在這個概念之上，能夠在同一個頁面上與其他JavaScript庫共存。
關于命名空間，最重要的是確定一個所有人都同意的全局對象名稱。這個名稱要足夠獨特，不可能與其他人的沖突。多數情況下，可以使用開發者所在的公司名，例如goog或Wrox。下面的例子演示了使用Wrox作為命名空間來組織功能：
- // 創建全局對象
- var Wrox = {};
- // 為本書（Professional JavaScript）創建命名空間
- Wrox.ProJS = {};
- // 添加本書用到的其他對象
- Wrox.ProJS.EventUtil = { ... };
- Wrox.ProJS.CookieUtil = { ... };
在這個例子中，Wrox是全局變量，然后在它的下面又創建了命名空間。如果本書所有代碼都保存在Wrox.ProJS命名空間中，那么其他作者的代碼就可以使用自己的對象來保存。只要每個人都遵循這個模式，就不必擔心有人會覆蓋這里的EventUtil或CookieUtil，因為即使重名它們也只會出現在不同的命名空間中。比如下面的例子：
- // 為另一本書（Professional Ajax）創建命名空間
- Wrox.ProAjax = {};
- // 添加其他對象
- Wrox.ProAjax.EventUtil = { ... };
- Wrox.ProAjax.CookieUtil = { ... };
- // 可以照常使用ProJS下面的對象
- Wrox.ProJS.EventUtil.addHandler( ... );
- // 以及ProAjax下面的對象
- Wrox.ProAjax.EventUtil.addHandler( ... );
雖然命名空間需要多寫一點代碼，但從可維護性角度看，這個代價還是非常值得的。命名空間可以確保代碼與頁面上的其他代碼互不干擾。
4.3 不要比較null
JavaScript不會自動做任何類型檢查，因此就需要開發者擔起這個責任。結果，很多JavaScript代碼都不會做類型檢查。最常見的類型檢查是看一個值是不是null。然而，與null進行比較的代碼太多了，其中很多都因為類型檢查不夠而頻繁引發錯誤。比如下面的例子：
- function sortArray(values) {
- if (values != null) { // 不要這樣比較！
- values.sort(comparator);
- }
- }
這個函數的目的是使用給定的比較函數對數組進行排序。為保證函數正常執行，values參數必須是數組。但是，if語句在這里只簡單地檢查了這個值不是null。實際上，字符串、數值還有其他很多值都可以通過這里的檢查，結果就會導致錯誤。
現實當中，單純比較null通常是不夠的。檢查值的類型就要真的檢查類型，而不是檢查它不能是什么。例如，在前面的代碼中，values參數應該是數組。為此，應該檢查它到底是不是數組，而不是檢查它不是null。可以像下面這樣重寫那個函數：
- function sortArray(values) {
- if (values instanceof Array) { // 推薦
- values.sort(comparator);
- }
- }
這個函數的這個版本可以過濾所有無效的值，根本不需要使用null。
- 如果看到比較null的代碼，可以使用下列某種技術替換它。
- 如果值應該是引用類型，使用instanceof操作符檢查其構造函數。
- 如果值應該是原始類型，使用typeof檢查其類型。
- 如果希望值是有特定方法名的對象，使用typeof操作符確保對象上存在給定名字的對象。
代碼中比較null的地方越少，就越容易明確類型檢查的目的，從而消除不必要的錯誤。
4.4 使用常量
依賴常量的目標是從應用邏輯中分離數據，以便修改數據時不會引發錯誤。顯示在用戶界面上的字符串就應該以這種方式提取出來，可以方便實現國際化。URL也應該這樣提取出來，因為隨著應用越來越復雜，URL也極有可能變化?；旧?，像這種地方因為這種或那種原因將來需要修改時，可能就要找到某個函數，然后修改其中的代碼。而每次像這樣修改應用邏輯，都可能引入新錯誤。為此，可以把這些可能會修改的數據提取出來，放在單獨定義的常量中，以實現數據與邏輯分離。
關鍵在于把數據從使用它們的邏輯中分離出來?？梢允褂靡韵聵藴蕶z查哪些數據需要提取。
- 重復出現的值。任何使用超過一次的值都應該提取到常量中。這樣可以消除一個值改了而另一個值沒改造成的錯誤。這里也包括CSS的類名。
- 用戶界面字符串。任何會顯示給用戶的字符串都應該提取出來，以方便實現國際化。
- URL：Web應用中資源的地址經常會發生變化，因此建議把所有URL集中放在一個地方管理。
- 任何可能變化的值。任何時候，只要在代碼中使用字面值，就問問自己這個值將來有沒有可能會變。如果答案是有可能，那么就應該把它提取到常量中。
使用常量是企業級JavaScript的重要技術，因為它可以讓代碼更容易維護，同時可以讓代碼免受數據變化的影響。
