摘要：最近閱讀了編寫可維護的，在這里記錄一下讀書筆記。禁止使用，，，的字符串形式。避免使用級事件處理函數。讓事件處理程序成為接觸到對象的唯一函數。檢測函數是檢測檢測函數的最佳選擇。為特定瀏覽器的特性進行測試，并僅當特性存在時即可應用特性檢測。

最近閱讀了《編寫可維護的 JavaScript》，在這里記錄一下讀書筆記。書中主要基于三個方向來講解怎么增加代碼的可維護性：編程風格、編程實踐、自動化。

筆記已加入到我的博客里，歡迎 Star。

縮進方式

使用空格（推薦）。

使用制表符（Tab 鍵）。

不同的操作系統對于制表符的解釋不一致，導致看起來不一致。

命名方式

變量名用名詞。

常量使用大寫單詞加下劃線 MAX_NUM。

函數名用動詞開頭

構造函數用大駝峰寫法。

null 對象的用法

初始化一個變量。

和一個已經初始化的變量做比較。

函數參數期望是對象時，用作參數傳入。

函數返回值是對象時，可以當做返回值。

// 好的寫法
var person = null;

function getPerson(num){

  if (num >5) {
    return new Person("Lily");
  } else {

    // 好的寫法
    return null;
  }
}

var person = new Person();

// 好的寫法
console.log(person === null);

不要和非對象，或者未賦值變量做比較。

不要用來檢測函數參數是否傳入。

var person;

// 不好的寫法
console.log(person === null);

function doSomeThing(arr1, arr2){

  // 不好的寫法
  if(arr1 === null){
    console.log("arr1 參數沒有傳遞");
  }
}

使用注釋的一般原則是：讓代碼變得更清晰。我們一般通過這幾點來注釋代碼：

難以理解的代碼。

可能被誤解的代碼。

瀏覽器 hack。

注釋的書寫規范：

注釋的上方需要一個空行。

單行注釋，如果在尾部注釋，需要加一個空格。

多行注釋中的每一行需對齊，最好也有一個星號。

可以加一些注釋聲明。

TODO 代碼未完成。

HACK 代碼走了一個捷徑，應注明原因

FIXME 代碼有問題，應盡快修復

REVIEW 代碼的改動需要評審

var person = null;

if (condition) {

  // 做一些事情
  doSomeThing(); // 做一些事情
}

/*
  * 這是創建一個對象
  * 第二行
*/
var p = new Person();


/**
@method merge
@param {Object} 被合并的對象
@return {Object} 一個新的對象
**/
function doSomeThing(obj) {
  return Object.assign(obj,{asd:123});
}

// REVIEW: 有更好的寫法嗎？
if(document.all){

}

在語句和表達式一章，書中主要是寫關于大括號對齊方式等，以下兩點讓我影響特別深刻：

循環中盡可能避免使用 continue，使用條件判斷替代（可讀性更好）。

for in 循環只是用來遍歷對象的，不要用來遍歷數組。如果不需要遍歷原型鏈上的對象，可以使用 hasOwnProperty。

定義變量

合并 var 語句，讓代碼更短。

函數內部的變量定義應作為函數內的第一條語句。

for 語句初始化部分不應該有變量聲明，應提前到外面。

立即執行的函數需要被一眼看出來，可以將函數用一堆圓括號包裹起來。

嚴格模式不要加在全局，只應加在需要用到的函數作用域內，避免影響其他庫。

禁止使用 eval，new Function，setTimeOut，setInterval 的字符串形式。

三元運算符僅僅用在賦值語句上，不要成為 if else 的替代品。

提示
String 類型可以調用 String 包裝器的方法，是因為語句的背后，JS 引擎創建了 String 類型的新實例，緊跟著就銷毀了，所以給 String 類型上添加屬性和方法是沒有用的。

在 WEB 開發中，用戶界面是由三個彼此隔離又相互作用的層定義的：HTML、CSS、JavaScript。由于這三個部分是相互作用的，應該盡量分開這幾個模塊，以增強代碼的可維護性。

將 JS 從 CSS 中抽離出來。

避免使用 CSS 表達式。

將 CSS 從 JS 中抽離出來。

避免使用 JS 直接操作 dom.style 屬性。

應該只需要操作 CSS 的 className 屬性。

將 JS 從 HTML 中抽離出來。

避免使用 DOM0 級事件處理函數。 例如：

使用自定義事件處理函數。

將 HTML 從 JS 中抽離出來。

避免 JS 使用寫死的 HTML 字符串，去 innerHTML 插入代碼。

div.innerHTML = "
你好
";

JS 可以使用一下幾種方式來操作 HTML：

請求服務器，返回一段 HTML 文本，然后 innerHTML。

簡單客戶端模板，寫一個頁面不可見的模板，用變量的值去填充模板后，插入到頁面中來。

復雜客戶端模板，使用 Handlebars，創建模板，渲染數據。

我們都知道，在全局作用域下定義的變量和方法，都會掛載到 window 對象上，隨著對象越掛越多，項目也就越來越難以維護了。創建全局變量還會導致以下幾個問題：

命名沖突

代碼脆弱性

如果大量函數都引用了全局變量，而一旦某個地方不小心改變了值，所有使用的地方就完了。

難以測試

開發環境，測試環境，線上環境，都需要引入一套不同的全局變量，不方便維護。

單全局變量

只使用一個對象定義在全局變量上，其他的對象都作為這個對象的屬性和方法。

引用命名空間概念：

調用 namespace() 來聲明開發者將要使用的命名空間，即：將對象掛載到哪個對象下，如果不存在，就創建一個對象。

AMD 模塊化

定義一個 define 方法，將模塊名，依賴，都傳進去，在工廠方法里就能使用所依賴的模塊了。

// AMD 模塊定義
define("module-name",["dep1","dep2"],function(dep1,dep2){});

使用 RequireJS 更好地引入模塊。

RequireJS 增加了另一個全局函數 require()，專門用來加載指定的依賴和執行回調函數。

require(["my-book"], function(books){
  console.log(books);
});

零全局變量

如果你的腳本非常短，并且不需要和其他代碼產生交互，可以使用一個自執行函數來實現模塊化。

在編寫事件處理程序時，我們應該遵守一下幾點：

隔離應用邏輯。將應用邏輯從所有的事件處理程序中抽離出來。

不要分發事件對象。只傳遞需要的數據，給應用邏輯就行了。

讓事件處理程序成為接觸到 Event 對象的唯一函數。其他需要用到的，就從事件處理程序中傳遞。

實際應用場景是這樣的：

click me

推薦使用 typeof 來檢測原始類型的值。typeof 本身是一個表達式，所以推薦使用無括號的寫法。

JS 檢測自定義類時，最好的做法是使用 instanceof，這也是唯一的方法。

function Person(){}

var p = new Person():

console.log(p instanceof Person);

instanceof 也可以檢測引用對象的值。但可能會檢測到原型對象上。

var now = new Date();

console.log(now instanceof Date); // true
console.log(now instanceof Object); // true

typeof 是檢測 JS 檢測函數的最佳選擇。但 IE8 及其以前的瀏覽器對 DOM 上的方法實現方式有問題。

// IE 8 會存在問題
typeof document.getElementById    // object

使用 Object.prototype.toString.call(value) === "[object Array]" 檢測數組效果很不錯，在 ES6 中可以通過 Array.isArray 來實現。

檢測屬性使用以下兩個操作符：

in 運算符（會檢測原型鏈上的屬性）

hasOwnProperty

在實際的項目中可以遇到這種問題，本來只需要更改一些靜態數據，但由于不小心改到了其他業務代碼，導致部分業務代碼報錯。所以，把需要配置的靜態數據抽離出來是非常利于維護的。一般按照以下幾點將數據抽離出來：

URL

展示給用戶的字符串

重復的值

設置信息

任何可能發生變更的值

我們可以將抽離出來的配置數據放在以下幾個地方：

抽離數據到一個 JSON 文件中。（通過請求去獲?。?/p>

抽離封裝到一個 JSONP 文件中。（通過 script 標簽獲?。?/p>

使用純 javascript。（直接讀?。?/p> 拋出自定義錯誤

我們在開發項目時，遇到錯誤其實并不可怕，可怕的將這些錯誤帶到線上環境中去。為此，在程序的一些關鍵地方，使用自定義錯誤，可以讓我們在上線前提前發現問題，避免出錯的影響變大。編寫自定義錯誤可以遵守一下幾點：

總是在錯誤信息中包含函數名稱，以及函數失敗的原因。

只在該拋出錯誤的地方拋出錯誤，不必要過度的進行錯誤預判，拋出錯誤。

如果使用 try catch ，catch 里不能為空，應該對錯誤做一些處理。

對于自定義錯誤，最好是繼承 Error 錯誤類型，瀏覽器會給 Error 對象附加一些額外的信息。

function MyError(message){
  this.message = message;
}
MyError.prototype = new Error();

在我們編寫代碼的時候，會用到很多其他對象，一些是存在于上下文作用域中、一些是存在于其他庫里等等，這些對象都不是我們自己定義的。對于這些對象，我們要做到完全不去改動。其他對象主要包括：

JS 原生對象

DOM 對象

瀏覽器對象模型，BOM 對象

類庫的對象

即使是目前項目中的對象，只要不是你寫的，也不應該隨便修改。

不要覆蓋方法

不新增方法

例如：Prototype 庫，是在源生 JS 上擴展一些方法，但擴展的方法可能以后被新的規范所使用，Prototype 庫不得不立即修改以支持新的規范。

不刪除方法

如果是必須要修改其他對象，可以通過繼承的方式來克隆一個之前的對象，然后再進行擴展。

基于對象的繼承（常規的繼承）

基于類型的繼承（如繼承 Error 類型）

Polyfills 的優點是：如果瀏覽器提供原生實現，可以非常輕松的移除他們。如果瀏覽器沒有實現，就使用現有的方法，巧妙地實現，實現過程可能會不精確。

防止擴展 Object.preventExtensions() 不可擴展

密封對象 Object.seal() 不能刪除已存在屬性，不可擴展

凍結對象 Object.freeze() 不能修改已存在的屬性，不能刪除已存在屬性，不可擴展

1、user-agent 方式（可以被篡改）。

2、使用特性檢測。為特定瀏覽器的特性進行測試，并僅當特性存在時即可應用特性檢測。例如：

// 早期瀏覽器不支持 getElementById
if(document.getElementById){
  var dom = document.getElementById("xx")
} else if(document.all){
  var dom = document.all("xx")
}

特性檢測的流程：

探測標準的方法。

探測不同瀏覽器的特定方法。

都不存在時，提供一個合乎邏輯的備用方法。

推斷是假設并非事實。例如：這里根據 getElementsByTagName 去推斷 getElementById，顯然是不合理的。

if(document.getElementsByTagName){
  var dom = document.getElementById("xx")
}

通過 document.all 判斷就是 IE 瀏覽器了，這是“自作聰明”的，因為其他瀏覽器也可能存在 document.all。

if(document.all){
  console.log("This is IE");
}

以下列舉了書中介紹的自動化配置過程，很實用，現在的項目都可以使用這些思想來配置持續集成?？上У氖?，現在看來書中的信息比較滯后（因為寫的早），很多介紹的庫已經過時了，這里就不詳細介紹了。

ant 構建工具

校驗語法錯誤

文件合并和加工

文件精簡和壓縮

文檔化

自動化測試

PhantomJS

組裝到一起

jekins

這本書看著很快，三天時間就看完了，但書中的編碼規范，編程實踐部分還是學到了不少東西?，F在寫代碼會常常冒出幾個問題：注釋該怎么寫？類型判斷要怎么才最好？數據代碼是否抽離？