摘要：執(zhí)行環(huán)境在很多方面都有其獨(dú)特之處全局變量和函數(shù)便是其中之一事實(shí)上的初始執(zhí)行環(huán)境是由多種多樣的全局變量所定義的這寫全局變量在腳本環(huán)境創(chuàng)建之初就已經(jīng)存在了我們說(shuō)這些都是掛載在全局對(duì)象上的全局對(duì)象是一個(gè)神秘的對(duì)象它表示了腳本最外層上下文在瀏覽器中

JavaScript執(zhí)行環(huán)境在很多方面都有其獨(dú)特之處. 全局變量和函數(shù)便是其中之一. 事實(shí)上, js的初始執(zhí)行環(huán)境是由多種多樣的全局變量所定義的, 這寫全局變量在腳本環(huán)境創(chuàng)建之初就已經(jīng)存在了. 我們說(shuō)這些都是掛載在"全局對(duì)象"(global object) 上的, "全局對(duì)象"是一個(gè)神秘的對(duì)象, 它表示了腳本最外層上下文.

在瀏覽器中, window對(duì)象往往重載并等同于全局對(duì)象, 因此任何的全局作用域中聲明的變量和函數(shù)都是window對(duì)象的屬性:

var color = "red";

function sayColor() {
    alert(color);
}

console.log(window.color); // "red"
console.log(typeof window.sayColor); // "function"

這段代碼中定義了全局變量color和全局函數(shù)sayColor(), 兩者都是window對(duì)象的屬性, 盡管我們并沒(méi)有顯示的執(zhí)行給window對(duì)象掛載屬性的操作.

6.1 全局變量帶來(lái)的問(wèn)題

創(chuàng)建全局變量被認(rèn)為是最糟糕的實(shí)踐, 尤其是在團(tuán)隊(duì)開發(fā)的大背景下更是問(wèn)題多多. 隨著代碼量的增長(zhǎng), 全局變量就會(huì)導(dǎo)致一些非常重要的可維護(hù)性難題. 全局變量越多, 引入錯(cuò)誤的概率將會(huì)因此變得越來(lái)越高.

6.1.1 命名沖突
腳本中的全局變臉和全局函數(shù)越來(lái)越多時(shí), 發(fā)生命名沖突的概率也隨之增高, 很可能無(wú)意間就使用了一個(gè)已經(jīng)聲明了的變量. 所有的變量都被定義為全局變量, 這樣的代碼才是最容易維護(hù)的.

6.1.2 代碼的脆弱性
一個(gè)依賴于全局變量的函數(shù)即是深耦合于上下文環(huán)境之中. 如果環(huán)境發(fā)生改變, 函數(shù)很可能就失效了. 在上一個(gè)例子中, 如果全局變臉color不再存在, sayColor()的方法將會(huì)報(bào)錯(cuò). 這意味著任何對(duì)全局環(huán)境的修改都可能在成某處代碼出錯(cuò). 同樣, 任何函數(shù)也會(huì)不經(jīng)意間修改全局變量. 導(dǎo)致對(duì)全局變量值的依賴變得不穩(wěn)定. 在上個(gè)例子中, 如果color被當(dāng)做參數(shù)傳入, 代碼可維護(hù)性會(huì)變得更佳.

var color = "red";

function sayColor() {
    alert(color); // 不好的做法用全局變量
}

function sayColor(color) {
    alert(color); // 好的做法
}

修改后這個(gè)函數(shù)不再依賴于全局變量, 因此任何對(duì)全局環(huán)境的修改都不會(huì)影響到它. 由于color是一個(gè)參數(shù). 唯一值得注意的是傳入函數(shù)的值得合法性. 其他修改都不會(huì)對(duì)這個(gè)函數(shù)完成它本身的任務(wù)有任何影響.

當(dāng)定義函數(shù)的時(shí)候, 最好盡可能多地將數(shù)據(jù)至于局部作用域內(nèi). 在函數(shù)內(nèi)定義的任何都應(yīng)當(dāng)采用這種寫法. 任何來(lái)自函數(shù)外部的數(shù)據(jù)都應(yīng)當(dāng)以參數(shù)形式傳進(jìn)來(lái). 這樣做可以將函數(shù)和其外部環(huán)境隔離開來(lái). 并且你的修改不會(huì)對(duì)程序其他部分造成影響.

6.1.3 難以測(cè)試
嘗試著在一個(gè)大型web應(yīng)用中實(shí)施一些單元測(cè)試. 在我即將完成核心框架的搭建時(shí), 我加入了一個(gè)團(tuán)隊(duì), 此后我努力讓我的代碼變得易于理解以便后續(xù)為其執(zhí)行測(cè)試. 我非常吃驚的發(fā)現(xiàn), 執(zhí)行測(cè)試編程一項(xiàng)積極困難的工序, 因?yàn)檎麄€(gè)框架要依賴于一些全局變量才會(huì)正常工作.

任何依賴全局變量才能正常工作的函數(shù), 只有為其重新創(chuàng)建完整的全局環(huán)境才能正確的測(cè)試它. 事實(shí)上, 這意味著你除了要管理全局環(huán)境的修改, 你還要在兩個(gè)全局環(huán)境中管理它們: 生產(chǎn)環(huán)境和測(cè)試環(huán)境. 保持兩者的同步是很消耗成本的, 很快你就會(huì)發(fā)現(xiàn)(代碼)可維護(hù)性的噩夢(mèng)才剛剛開始. 越到后來(lái)越難于理清頭緒.

確保你的函數(shù)不會(huì)對(duì)全局變量有依賴, 這將增強(qiáng)你的代碼的可測(cè)試性(testability). 當(dāng)然你的函數(shù)可能會(huì)依賴原生的js全局對(duì)象, 比如Date、Array等. 他們是全局環(huán)境的一部分, 適合js引擎相關(guān)的, 你的函數(shù)總是會(huì)用到這些全局對(duì)象. 總之, 為了保證你的代碼具有最佳的可測(cè)試性, 不要讓函數(shù)對(duì)全局變量有依賴.

6.2 意外的全局變量
js中有不少陷阱, 其中有一個(gè)就是不小心會(huì)創(chuàng)建全局變量. 當(dāng)你給一個(gè)未被var的語(yǔ)句證明過(guò)的變量賦值時(shí), js就會(huì)自動(dòng)創(chuàng)建愛(ài)你一個(gè)全局變量, 比如:

function doSomeThing() {
    var count = 10;
        title = "編寫可維護(hù)的js"; // 不好的寫法: 創(chuàng)建了全局變量
}

6.3 單全局變量方式
依賴盡可能少的全局變量, 即只創(chuàng)建一個(gè)全局變量.
單全局變量模式已經(jīng)在各種流行的類庫(kù)中廣泛使用了.

jQuery定義了兩個(gè)全局對(duì)象, $和jQuery. 只有在$被其他的類庫(kù)使用了的情況下, 為了避免沖突, 應(yīng)當(dāng)使用jQuery.

vue實(shí)例化的對(duì)象 自己定義的vm等

"單全局變量"的意思是所創(chuàng)建的這個(gè)唯一的全局對(duì)象名是獨(dú)一無(wú)二的(不會(huì)和內(nèi)置API沖突), 并將你的所有的功能代碼都掛載到這個(gè)全局對(duì)象上. 因此每個(gè)可能的全局變量都成為你唯一的全局對(duì)象的屬性, 從而不會(huì)創(chuàng)建多個(gè)全局變量. 比如, 假設(shè)我想讓一個(gè)對(duì)象表示本書的一章, 代碼看起來(lái)會(huì)像下面這樣.

function Book(title) {
    this.title = title;
    this.page = 1;
}

Book.prototype.turnPage = function(direction) {
    this.page += direction;
};

var Chapter1 = new Book("第一章");
var Chapter2 = new Book("第二章");
var Chapter3 = new Book("第三章");

這段代碼創(chuàng)建了4個(gè)全局對(duì)象: Book、Chapter1、Chapter2、Chapter3. 單全局變量模式則只會(huì)創(chuàng)建一個(gè)全局對(duì)象并將這些對(duì)象都賦值為它的屬性.

var MaintainableJS = {};

MaintainableJS.Book = function(title) {
    this.title = title;
    this.page = 1;
}

MaintainableJS.Book.prototype.turnPage = function(direction) {
    this.page += direction;
};

MaintainableJS.Chapter1 = new MaintainableJS.Book("第一章");
MaintainableJS.Chapter2 = new MaintainableJS.Book("第二章");
MaintainableJS.Chapter3 = new MaintainableJS.Book("第三章");

這段代碼只有一個(gè)全局對(duì)象, 即MaintainableJS, 其他任何信息都掛載到這個(gè)對(duì)象上. 因?yàn)閳F(tuán)隊(duì)中每個(gè)人度知道這個(gè)全局對(duì)下是哪個(gè), 因此很容易做到繼續(xù)為它添加屬性以避免全局污染.

6.3.1 命名空間
即使你的代碼只有一個(gè)全局對(duì)象, 也可能污染全局. 大多數(shù)使用單全局變量模式的項(xiàng)目同樣包含"命名空間"的概念. 命名空間是簡(jiǎn)單的通過(guò)全局對(duì)象的單一屬性表示的功能性分組. 比如, YUI就是已超命名空間的思路來(lái)管理代碼的. Y.DOM下的所有的方法都是和DOM操作相關(guān)的, Y.Event下所有的方法是和時(shí)間相關(guān)的.
將功能按照命名空間進(jìn)行分組, 可以讓你的全局對(duì)象變得井然有序, 同事可以讓團(tuán)隊(duì)成員能夠知曉性性能應(yīng)該屬于哪個(gè)部分, 或者知道去哪里查找已有的功能. 當(dāng)作者在YaHoo!工作的時(shí)候, 就有一個(gè)不成文的約定, 即每個(gè)站點(diǎn)杜江自己的命名空間掛載至Y對(duì)象上, 因此"My YaHoo!" 使用Y.My, 郵箱使用Y.Mail, 等等. 這樣團(tuán)隊(duì)成員則可以放心大膽的使用其他人的代碼, 而不必?fù)?dān)心沖突.

在js中你可以使用對(duì)象來(lái)輕而易舉的創(chuàng)建你自己的命名空間, 比如:

var ZakasBooks = {};

// 表示這本書的命名空間
ZakasBooks.MaintainableJs = {};

// 表示另一本書的命名空間
ZakasBooks.HighPerformanceJs = {};

一個(gè)常見(jiàn)的約定在每一個(gè)文件中都通過(guò)創(chuàng)建新的全局對(duì)象來(lái)聲明自己的命名空間. 在這種情況下, 上面的這個(gè)例子給出的方法是夠用的.

同樣有另外一個(gè)常見(jiàn), 每個(gè)文件都是需要給一個(gè)命名空間掛載東西. 這種情況下, 你需要首先保證這個(gè)命名空間是已經(jīng)存在的. 這是全局對(duì)象非破壞性的處理命名空間的方式則變得非常有用, 成成這項(xiàng)操作的基本模式是像下面這樣的.

var YourGlobal = {
   namespace: function(ns){
       var parts = ns.split("."),
       object = this, 
       i, 
       len;
       
       for(i = 0, len = parts.length; i < len; i++) {
           if(!object[parts[i]]){
               object[parts[i]] = {};
           }
           object = object[parts[i]];
       }
       
       return object;
   }
}

變量YourGlobal 實(shí)際上可以表示任意名字. 最重要的部分在于namespace()方法, 我們給這個(gè)方法傳入一個(gè)表示命名空間對(duì)象的字符串, 它會(huì)非破壞性的(nondestructively) 創(chuàng)建這個(gè)命名空間, 基本一用法如下.

/*
 * 同時(shí)創(chuàng)建YourGlobal.Books和YourGlobal.Books.MaintainableJs
 * 因?yàn)橹皼](méi)有創(chuàng)建過(guò)它們, 因此每個(gè)都是全新創(chuàng)建的
 */
YourGlobal.namespace("book.MaintainableJs");

// 現(xiàn)在你可以使用這個(gè)命名空間
YourGlobal.Books,MaintainableJs.author = "Nicholas C. Zakas";

/*
 * 不會(huì)操作YourGlobal.Books本身, 同時(shí)會(huì)給它添加HighPerformanceJs
 * 它會(huì)保持YourGlobal.Books.MaintainableJs原封不動(dòng)
 */
YourGlobal.namespace("Books.HighPerformanceJs");

// 仍然是合法的引用
console.log(YourGlobal.Books.MaintainableJs.author);

// 你同樣可以在方法調(diào)用之后立即給它添加新屬性
YourGlobal.namespace("Books").ANewBook = {};

基于你的單全局對(duì)象使用namespace()方法可以讓開發(fā)者放心地認(rèn)為命名空間總是存在的. 這樣, 每個(gè)文件度可以首先調(diào)用namespace()來(lái)聲明開發(fā)者將要使用的命名空間, 這樣做不會(huì)對(duì)已有的命名空間造成任何破壞. 這個(gè)方法可以讓開發(fā)者解放出來(lái), 在使用命名空間之前不必再去判斷它是否存在.

由于你的代碼不是獨(dú)立存在的, 因此要圍繞命名空間定義一些約定. 是否應(yīng)該以首字母大寫的形式來(lái)定義命名空間, 就像YUI? 還是都用小寫字母形式來(lái)定義命名空間, 就像Dojo? 這個(gè)是個(gè)人喜好問(wèn)題, 但是首先定義這些約定可以讓后續(xù)團(tuán)隊(duì)成員在使用但全局變量時(shí)更加高效.

6.3.2 模塊
另一種基于單全局變量的擴(kuò)充方法是使用模塊(modules). 模塊是一種通用的功能片段, 它并沒(méi)有創(chuàng)建新的全局變量或者命名空間. 相反, 所有的這些代碼都存放于一個(gè)表示執(zhí)行一個(gè)任務(wù)或發(fā)布一個(gè)接口的但函數(shù)中. 可以用一個(gè)名稱來(lái)表示這個(gè)模塊, 同樣這個(gè)模塊可以依賴其它模塊.

js本身不包含模塊概念, 自然也沒(méi)有模塊語(yǔ)法(es6支持 import export), 單的確有一些通用的模式來(lái)創(chuàng)建模塊. 兩種最流行的類型是"YUI模塊"模式和"異步模塊定義"(Asynchronous Module Definition, 簡(jiǎn)稱AMD)模式.

YUI模塊
從字面含義理解, YUI模塊就是使用YUI Js類庫(kù)來(lái)創(chuàng)建新模塊的一種模式. YUI3中包含了模塊的概念, 寫法如下.

YUI.add("module-name", function(Y) {

    // 模塊正文
    
}, "version", { requires: [ "dependecy1", "dependency2" ] });

我們通過(guò)調(diào)用YUI.add()并給它傳入模塊名字、待執(zhí)行的函數(shù)(被稱作工廠方法)和可選的依賴列表來(lái)添加YUI模塊. "模塊正文"處則是你寫所有的模塊代碼的地方. 參數(shù)Y是YUI的一個(gè)實(shí)例, 這個(gè)實(shí)例包含所有以來(lái)的模塊提供的內(nèi)容. YUI中約定在每一個(gè)模塊內(nèi)使用命名空間的方式來(lái)管理模塊代碼, 比如:

YUI.add("my-books", function(Y) {

    // 添加一個(gè)命名空間
    Y.namespace("Books.MaintainableJs");
    
    Y.Books.MaintainableJs.author = "Nicholas C. Zakas";
}, "1.0.0", { requires: [ "dependecy1", "dependency2" ] });

同樣, 依賴也是以Y對(duì)象命名空間的形式傳入進(jìn)來(lái). 因此YUI實(shí)際上是將命名空間和模塊的概念合并在了一起, 總體上提供一種靈活的解決方案.

通過(guò)調(diào)用YUI().use()函數(shù)并傳入想加載的模塊名稱來(lái)使用你的模塊.

YUI.use("my-books", "another-modult", function(Y) {
    
    console.log(Y.Books.MaintainableJs.author);
    
})

這段代碼以加載名叫"my-books"和"another-module"的兩個(gè)模塊開始, YUI會(huì)確保這些模塊的依賴都會(huì)完全加載完成, 然后執(zhí)行模塊的正文代碼, 最后才會(huì)執(zhí)行行傳入YUI().use()的回調(diào)函數(shù). 回調(diào)函數(shù)會(huì)帶回Y對(duì)象, Y對(duì)象里包含了加載模塊對(duì)它做的修改, 這時(shí)你的應(yīng)用代碼就可以放心的執(zhí)行了.

"異步模塊定義"(AMD)
AMD模塊和YUI模塊有諸多相似之處. 你指定模塊名稱、依賴和一個(gè)工廠方法, 依賴加載完成后執(zhí)行這個(gè)工廠方法. 這些內(nèi)容全部作為參數(shù)傳入一個(gè)全局函數(shù)define()中, 其中第一個(gè)參數(shù)是模塊名稱, 然后是依賴列表, 最后是工廠方法. AMD模塊和YUI模塊最大的不同在于, (AMD中) 每一個(gè)依賴都會(huì)對(duì)應(yīng)到獨(dú)立的參數(shù)傳入工廠方法里, 比如:

define("module-name", [ "dependency1", "dependency2" ], function(dependency1, dependency2) {
    
    //模塊正文
})

因此, 每個(gè)被命名的依賴最后都會(huì)創(chuàng)建一個(gè)對(duì)象, 這個(gè)對(duì)象會(huì)被帶入工程方法中. AMD以這種方式來(lái)嘗試避免命名沖突, 因?yàn)橹苯釉谀K中使用命名空間有可能發(fā)生命名沖突. 和YUI模塊中創(chuàng)建新的命名空間的方法不同, AMD模塊則期望從工廠方法中返回它們的公有接口, 比如:

define("my-books", [ "dependency1", "dependency2" ], function(dependency1, dependency2) {
    
    var Books = {};
    Books.MaintainableJs = {
        author: "Nicholas C. Zakas"
    }
    
    return Books;
})

AMD模塊同樣可以是匿名的, 完全省略模塊名稱. 因?yàn)槟K加載器可以將js文件名當(dāng)做模塊名稱. 所以如果你有一個(gè)名叫my-books.js的文件, 你的模塊可以只通過(guò)模塊加載器來(lái)加載, 你可以像這樣定義你的模塊.

define([ "dependency1", "dependency2" ], function(dependency1, dependency2) {
    
    var Books = {};
    Books.MaintainableJs = {
        author: "Nicholas C. Zakas"
    }
    
    return Books;
})

想要使用AMD模塊, 你需要使用一個(gè)與之兼容的模塊加載器. Dojo的標(biāo)準(zhǔn)模塊加載器支持AMD模塊的加載, 因此你可以向下面這樣來(lái)加載"my-books" 模塊.

// 使用Dojo加載AMD模塊
var books = dojo.require("my-books");

console.log(books.MaintainableJs.author);

Dojo同樣將自己的也封裝為AMD模塊, 叫做"dojo", 因此它也可以被其他AMD模塊加載.

另一個(gè)模塊加載器是Require.js. RequireJS添加了另一個(gè)全局函數(shù)require(), 專門用來(lái)加載指定的依賴和執(zhí)行回調(diào)函數(shù), 比如:

// 使用RequireJS加載AMD模塊
require(["my-books"], function(books) {
    
    console.log(books.MaintainableJs.author);
    
})

調(diào)用require()時(shí)首先會(huì)立即加載依賴, 這些依賴都加載完成后會(huì)立即執(zhí)行回調(diào)函數(shù).

RequireJS模塊加載器包含很多內(nèi)置邏輯來(lái)讓模塊的加載更加方便, 包括名字到目錄的對(duì)應(yīng)表以及多語(yǔ)種選項(xiàng).

6.4 零全局變量
你的Js代碼注入到頁(yè)面時(shí)可以做到不用創(chuàng)建全局變量的. 這種方法應(yīng)用場(chǎng)景不多, 因此只有在某些特殊場(chǎng)景下才會(huì)有用. 最常見(jiàn)的情形就是一段不會(huì)被其他腳本訪問(wèn)到的完全獨(dú)立的腳本. 之所以存在這種情形, 是因?yàn)樗兴枰哪_本都會(huì)合并到一個(gè)文件, 或者因?yàn)檫@段非常短小且不提供任何借口的代碼會(huì)被插入至一個(gè)頁(yè)面中. 最常見(jiàn)的用法是創(chuàng)建一個(gè)書簽.

書簽是獨(dú)立的, 它們并不知曉頁(yè)面中包含什么且不需要頁(yè)面知道它的存在. 最終我們需要一段"零全局變量"的腳本嵌入到頁(yè)面中, 實(shí)現(xiàn)方法就是使用一個(gè)立即執(zhí)行的函數(shù)調(diào)用并將所有的腳本放置其中, 比如:

(function(win) {

    var doc = win.document;
    
    // 這里定義其他的變量
    
    // 其他相關(guān)代碼
})(window);

這段立即執(zhí)行的代碼傳入了window對(duì)象, 因此這段代碼不需要直接引用任何全局變量. 在這函數(shù)內(nèi)部, 變量doc是指向document對(duì)象的引用, 只要函數(shù)代碼中沒(méi)有直接修改window或doc且所有變量都是用var關(guān)鍵字來(lái)定義, 這頓啊腳本則可以注入到頁(yè)面中而不會(huì)產(chǎn)生任何全局變量. 之后你可以通過(guò)將函數(shù)設(shè)置為嚴(yán)格模式(strict mode)來(lái)避免創(chuàng)建全局變量.

(function(win) {
    
    "use strict"
    
    var doc = win.document;
    
    // 這里定義其他的變量
    
    // 其他相關(guān)代碼
})(window);

這個(gè)函數(shù)包裝器(function wrapper) 可以用于任何不需要?jiǎng)?chuàng)建全局對(duì)象的場(chǎng)景. 正如上文提到的, 這種模式的使用場(chǎng)景有限. 只要你的代碼需要被其他的代碼所依賴, 就不能使用這種零全局變量的方式. 如果你的代碼需要在運(yùn)行時(shí)被不斷擴(kuò)展或修改也不能使用零全局變量的方式. 但是, 如果你的腳本非常短, 且不需要和其他代碼產(chǎn)生交互, 可以考慮使用零全局變量的方式來(lái)實(shí)現(xiàn)代碼.