摘要：高內(nèi)聚不應該將沒有任何聯(lián)系的東西堆到一起。高內(nèi)聚是值得要的，因為它意味著類可以更好地執(zhí)行一項工作。高內(nèi)聚有助于緩解高耦合，高耦合是需要高內(nèi)聚的標志。對于開發(fā)者來說，高內(nèi)聚通常比低耦合更有幫助，盡管兩者通?？梢砸黄鹜瓿?。

作為一個剛寫代碼不久的小菜鳥，工作的半年多讓我越發(fā)意識到提高代碼質(zhì)量的重要性。從前只會關(guān)注實現(xiàn)功能，慢慢的開始關(guān)注性能，現(xiàn)階段則發(fā)現(xiàn)其實還有很多細節(jié)也是（如可讀性、易用性、可維護性、一致性）提高代碼質(zhì)量的關(guān)鍵。“實現(xiàn)功能”跟“優(yōu)雅地實現(xiàn)功能”是兩碼事。

注：大部分內(nèi)容歸納自網(wǎng)絡，將多篇文章的觀點匯總加工了一下，也融合了一些個人的見解。

單一職責原則

易用性原則

可讀性原則

復雜性守恒原則：無論你怎么寫代碼，復雜性都是不會消失的

注：如果邏輯很復雜，那么代碼看起來就應該是復雜的。如果邏輯很簡單，代碼看起來就應該是簡單的。

面向?qū)ο笪宕笤O計模式基本原則之一。即一部分代碼只應該用于某一個特定功能，不應與其他功能耦合在一起。

假設你的一個function同時實現(xiàn)了功能a和功能b，之后需求變更，你需要修改功能a，但是因為這兩個功能都在一個function里，你就不得不再去確認是否會影響到功能b。這就造成了不必要的成本。

如下我總結(jié)了三個拆分代碼的原則：

當你為你的方法命名時不得不加上“and”時，就該考慮考慮是不是要把這個方法拆分一下了。

當你的一個function超過一百行時，一定要進行拆分了。

注：這里的100可能有點多，只是對我個人而言，100算是我的極限，總之就是絕對不要將一個函數(shù)寫的太長。

我們開發(fā)中大部分操作可以總結(jié)為“命令”和“查詢”，如寫cookie、修改data、發(fā)送post請求都可以叫“命令”，而讀取cookie、ajax獲取數(shù)據(jù)則認為是“查詢”操作。

函數(shù)式編程中講究“數(shù)據(jù)不可變”，即：

只有純的沒有副作用的函數(shù)，才是合格的函數(shù)。
副作用：指當調(diào)用函數(shù)時，除了返回函數(shù)值之外，還對主調(diào)用函數(shù)產(chǎn)生附加的影響。例如修改全局變量（函數(shù)外的變量）或修改參數(shù)。

好處是使得開發(fā)更加簡單，可回溯，測試友好，減少了任何可能的副作用。

將“命令”與“查詢”拆分實際上就是函數(shù)式編程思想的部分體現(xiàn)，參考如下代碼：

function getFirstName() {
    var firstName = document.querySelector("#firstName").value;
    firstName = firstName.toLowerCase();
    setCookie("firstName", firstName);
    if (firstName === null) {
        return "";
    }
    return firstName;
}
 
var activeFirstName = getFirstName();

通過名字來看，該方法是用于獲取first name的，但實際上它還設置了cookie，這是我們沒有預料的。對于一個“查詢”方法，它不應該有任何修改方法外變量的行為，即“副作用”。更好的寫法如下：

function getFirstName() {
    var firstName = document.querySelector("#firstName").value
    if (firstName === null) {
        return "";
    }
    return firstName;
}
 
setCookie("firstName", getFirstName().toLowerCase());

一目了然，getFirstName只返回firstName，而設置cookie操作在它之外進行。

這里的簡單，主要歸結(jié)為function的一些設計原則，有如下幾點：調(diào)用簡單、易理解、減少記憶成本、參數(shù)處理。

如下，僅僅想實現(xiàn)修改dom顏色、寬度等屬性，原生代碼如下：

document.querySelector("#id").style.color = "red"
document.querySelector("#id").style.width = "123px"
document.querySelector("#id").style.height = "456px"

而封裝過后：

function a(selector, color, width, height) {
  document.querySelector(selector).style.color = color
  document.querySelector(selector).style.width = width
  document.querySelector(selector).style.height = height
}
a("#a", "red")

瞬間變得簡單可用了 ~

但該方法還存在一個問題，那就是命名太抽象了。。。除了開發(fā)者自己以外不可能有人在不看源碼的情況下一眼看出這個方法a是干嘛的。那么咱再把這個方法名改寫得更易理解一點：

function letSomeElementChange(selector, color, width, height) {
  document.querySelector(selector).style.color = color
  document.querySelector(selector).style.width = width
  document.querySelector(selector).style.height = height
}

這樣我們就能一目了然該方法的作用 ~ 不過仍有可優(yōu)化的地方。這么長的方法名誰記得住，要減少記憶成本啊，再改個名：

function setElement(selector, color, width, height) {
  document.querySelector(selector).style.color = color
  document.querySelector(selector).style.width = width
  document.querySelector(selector).style.height = height
}

OK，目前這個方法已經(jīng)滿足它的職責并且很好用了，但還覺得怪怪的。這一坨參數(shù)太礙眼。。。

function setElement(selector, opt) {
  const { color, width, height } = opt
  color && document.querySelector(selector).style.color = color
  width && document.querySelector(selector).style.width = width
  height && document.querySelector(selector).style.height = height
}

把多個參數(shù)合并一下，并在內(nèi)部做兼容處理，這個方法便易用多了。即使不傳第二個參數(shù)也不會有任何副作用。

假如有這樣一個方法，獲取歌曲列表，并將其設置到div的innerText中：

function getSongs() {
  return $.get("/songs).then((response) {
      div.innerText = response.songs
  })
}

這就違背了方法的表里一致性，也違背了上文的單一職責原則中命令、查詢拆分原則，因為它不僅獲取了歌單，同時還修改了innerText，要讓其更合理：

要么換個名字

要么拆分為兩個方法

耦合是衡量一個程序單元對其他程序單元的依賴程度。耦合（或高耦合）是應該極力避免的。如果你發(fā)現(xiàn)自己正在復制和粘貼代碼并進行小的更改，或者重寫代碼，因為其他地方發(fā)生了更改，這就是高耦合的體現(xiàn)。

耦合會嚴重影響代碼的復用性及可擴展性，讓后人維護時不得不修改甚至重寫這部分代碼，不僅浪費時間還會導致倉儲中又多出一塊類似的代碼，很容易讓人迷惑。

同時，修改耦合度高的代碼時經(jīng)常會牽一發(fā)而動全身，如果修改時沒有理清這些耦合關(guān)系，那么帶來的后果可能會是災難性的，特別是對于需求變化較多以及多人協(xié)作開發(fā)維護的項目，修改一個地方會引起本來已經(jīng)運行穩(wěn)定的模塊錯誤，嚴重時會導致惡性循環(huán)，問題永遠改不完，開發(fā)和測試都在各種問題之間奔波勞累，最后導致項目延期，用戶滿意度降低，成本也增加了，這對用戶和開發(fā)商影響都是很惡劣的，各種風險也就不言而喻了。

不應該將沒有任何聯(lián)系的東西堆到一起。

內(nèi)聚是一個類中變量與方法連接強度的尺度。高內(nèi)聚是值得要的，因為它意味著類可以更好地執(zhí)行一項工作。低內(nèi)聚是不好的，因為它表明類中的元素之間很少相關(guān)。每個方法也應該高內(nèi)聚，大多數(shù)的方法只執(zhí)行一個功能，不要在方法中添加‘額外’的指令，這樣會導致方法執(zhí)行更多的函數(shù)，同時也違反了上文的單一職責原則。

低內(nèi)聚的體現(xiàn)：如果屬性沒有被類中的多個方法使用，這可能是低內(nèi)聚的標志。同樣，如果方法在幾種不同的情況下不能被重用，或者如果一個方法根本不被使用，這也可能是低內(nèi)聚的一個標志。

高內(nèi)聚有助于緩解高耦合，高耦合是需要高內(nèi)聚的標志。但是，如果兩個問題同時存在，應當選擇內(nèi)聚的方式。對于開發(fā)者來說，高內(nèi)聚通常比低耦合更有幫助，盡管兩者通?？梢砸黄鹜瓿?。

可預見的錯誤：諸如ajax回調(diào)、函數(shù)參數(shù)，這類問題很好解決，只需在開發(fā)時多考慮一步，對各種極端情況做好兼容即可。

不可預見的錯誤：類似兼容性問題，這類問題無法在開發(fā)時準確預見的錯誤，可以準備好拋錯，console.error/log/warn，最后你還可以為自己的程序留些后路: try...catch。

命名應該保證別人通過名稱一眼就能知道這個變量保存的是什么，或者這個方法是用來做什么的。

普通變量、屬性用名詞如下：

var person = {
  name: "Frank"
}
var student = {
  grade: 3,
  class: 2
}

bool變量、屬性用（形容詞）或者（be動詞）或者（情態(tài)動詞）或者（hasX），如下：

var person = {
  dead: false, // 如果是形容詞，前面就沒必要加 is，比如isDead 就很廢話
  canSpeak: true, //情態(tài)動詞有 can、should、will、need 等，情態(tài)動詞后面接動詞
  isVip: true, // be 動詞有 is、was 等，后面一般接名詞
  hasChildren: true, // has 加名詞
}

普通函數(shù)、方法用（動詞）開頭：

var person = {
  run(){}, // 不及物動詞
  drinkWater(){}, // 及物動詞
  eat(foo){}, // 及物動詞加參數(shù)（參數(shù)是名詞）
}

回調(diào)、鉤子函數(shù)：

var person = {
  beforeDie(){},
  afterDie(){},
  // 或者
  willDie(){}
  dead(){} // 這里跟 bool 沖突，你只要不同時暴露 bool dead 和函數(shù) dead 就行，怕沖突就用上面的 afterDie
}
button.addEventListener("click", onButtonClick)
var component = {
  beforeCreate(){},
  created(){},
  beforeMount(){}
}

命名一致性

順序一致性：比如 updateContainerWidth 和 updateHeightOfContainer 的順序就令人很別扭

時間一致性：有可能隨著代碼的變遷，一個變量的含義已經(jīng)不同于它一開始的含義了，這個時候你需要及時改掉這個變量的名字。

這一條是最難做到的，因為寫代碼容易，改代碼難。如果這個代碼組織得不好，很可能會出現(xiàn)牽一發(fā)而動全身的情況（如全局變量就很難改）

不需要多花哨，只要把作用、用法描述清楚即可。方法的標準注釋應該如下：

/**
 * [function_name description]
 * @param  {[type]} argument [description]
 * @return {[type]}          [description]
 */
function function_name(argument) {
  // body...
}

將方法的參數(shù)與返回值都寫清楚，我目前用的IDE是sublime，使用Docblockr插件可以自動生成格式化注釋，很方便。

項目中我們經(jīng)常能夠遇這類代碼，它們?nèi)钥捎?，但是很“臭”，國外管這類代碼有一個統(tǒng)稱，即“bad smell”。如下這類代碼可以說是很“臭”了：

表里不一的代碼

過時的注釋

邏輯很簡單，但是看起來很復雜的代碼

重復的代碼

相似的代碼

總是一起出現(xiàn)的代碼

未使用的依賴

不同風格的代碼

正確命名：class必須用“-”寫法，不要用駝峰和下劃線。

正確嵌套：正常情況下一定要將class嵌套閉合，否則就相當于添加到全局，如果有重復命名的class就會受影響。

拒絕copy：如果想復用已有的樣式，直接在原有class上用“,”語法分割，就能應用，不要再copy一份樣式，會讓兩份樣式都被應用，就要考慮樣式覆蓋的問題，很不友好。

濫用class：沒有必要加的class不要加，每個class的添加都應該有明確理由。濫用class的話可能會導致樣式覆蓋，不該應用這個樣式的地方用了這個樣式。

慎用 !important，會強行覆蓋所有同屬性樣式，一旦使用后會讓代碼難以維護，開發(fā)過程中絕對不要依賴該方法。如下總結(jié)了一些使用 !important的經(jīng)驗：

一定要優(yōu)化考慮使用樣式規(guī)則的優(yōu)先級來解決問題而不是 !important

只有在需要覆蓋全站或外部 css（例如引用的 ExtJs 或者 YUI ）的特定頁面中使用 !important

解決緊急線上問題可以使用，但之后也要盡快用可維護的方式將代碼替換回來

永遠不要在全站范圍的 css 上使用 !important

永遠不要在你的插件中使用 !important

此理論認為環(huán)境中的不良現(xiàn)象如果被放任存在，會誘使人們仿效，甚至變本加厲。一幢有少許破窗的建筑為例，如果那些窗不被修理好，可能將會有破壞者破壞更多的窗戶。最終他們甚至會闖入建筑內(nèi)，如果發(fā)現(xiàn)無人居住，也許就在那里定居或者縱火。一面墻，如果出現(xiàn)一些涂鴉沒有被清洗掉，很快的，墻上就布滿了亂七八糟、不堪入目的東西；一條人行道有些許紙屑，不久后就會有更多垃圾，最終人們會視若理所當然地將垃圾順手丟棄在地上。這個現(xiàn)象，就是犯罪心理學中的破窗效應，在編程領(lǐng)域同樣存在。

要做到：只要是經(jīng)過你手的代碼，都會比之前好一點。

參考文章：

javascript的api設計原則

Coding with Clarity

Don"t leave broken windows

從JS對象開始，談一談“不可變數(shù)據(jù)”和函數(shù)式編程

重構(gòu) - 代碼優(yōu)化技巧

如何和何時使用CSS的!important

css優(yōu)先級