這個(gè)文集的系列是關(guān)于《JavaScript設(shè)計(jì)模式于開發(fā)實(shí)踐》一書，建議大家在厭倦業(yè)務(wù)代碼的時(shí)候可以看看，受益匪淺。
從第一章看到第十三章，津津有味，但是過目就忘，畢竟這樣的例子在實(shí)際應(yīng)用中還需要靈活變通。就好比學(xué)習(xí)高數(shù)，你學(xué)會(huì)了一個(gè)方程式的解題方法和過程，但是同樣的問題放到實(shí)際的物理模型中，未必能馬上發(fā)現(xiàn)其中的解法。
多次閱讀，在思考問題時(shí)慢慢代入設(shè)計(jì)模式的思維，在重構(gòu)時(shí)遵循其中的法則，這就是大神們常說的“你應(yīng)該這樣做”。為什么突然就停下來寫這節(jié)職責(zé)鏈模式呢？歸功于下面這段代碼（題目和代碼均從書中摘?。?。
假設(shè)我們負(fù)責(zé)一個(gè)售賣手機(jī)的電商網(wǎng)站，經(jīng)過分別交納500元定金和200元定金的兩輪預(yù)定后（訂單在此時(shí)生成），現(xiàn)在已經(jīng)到了正式購買的階段。
公司針對支付過定金的用戶有一定的優(yōu)惠政策。在正式購買后，已經(jīng)支付過500元定金的用戶會(huì)收到100元的商城優(yōu)惠券，200元定金的用戶可以收到50元的優(yōu)惠券，而之前沒有支付定金的用戶只能進(jìn)入普通購買模式，也就是沒有優(yōu)惠券，而且?guī)齑嬗邢薜那闆r下不一定保證能買到。
這里簡略地描述一下...
orderType: 訂單類型 | 1 => 500元定金用戶, 2 => 200元定金用戶, 3 => 普通購買用戶
pay: 是否已經(jīng)支付定金。（如果用戶下過500/200元定金訂單但是沒有支付，降級為普通購買模式）
stock: 表示當(dāng)前用于普通購買地手機(jī)庫存數(shù)量，已經(jīng)支付過定金地用戶不受限制
//代碼實(shí)現(xiàn)
var oder = function( orderType, pay, stock) {
if( orderType === 1 ) { // 500元定金購買模式
if ( pay === true ) {
console.log('500元定金預(yù)購，得到100元優(yōu)惠券');
}else {
if ( stock > 0 ) {
console.log('普通購買， 無優(yōu)惠券');
}else {
console.log('手機(jī)庫存不足');
}
}
}
else if ( orderType === 2 ) { // 200元定金購買模式
if ( pay === true ) {
console.log('200元定金預(yù)購，得到50元優(yōu)惠券');
}else {
if ( stock > 0 ) {
console.log('普通購買， 無優(yōu)惠券');
}else {
console.log('手機(jī)庫存不足');
}
}
}
else if ( orderType === 3 ) { // 200元定金購買模式
if ( stock > 0 ) {
console.log('普通購買， 無優(yōu)惠券');
}else {
console.log('手機(jī)庫存不足');
}
}
};
order(1, true, 500); //輸出： 500元定金預(yù)購，得到100元優(yōu)惠券
作者評論這段代碼： 恐怕只有最“新手”地程序員才會(huì)寫出這樣的代碼。
于是我很尷尬地想： 哈哈，算我一個(gè)。
實(shí)習(xí)期間，我面臨的實(shí)際情況稍復(fù)雜一點(diǎn)，簡單描述一下：
一個(gè)產(chǎn)品管理系統(tǒng)，第一層分支便是 不同系列的產(chǎn)品 ，第二層分支是 不同角色 ，第三層分支便是對應(yīng)的action（這層相當(dāng)于上面的log，可以不列入在內(nèi)）。
那么在沒有真正熟悉整個(gè)流程的情況下，我常常會(huì)寫出else-if許多分支，這些分支往往一開始沒有那么多（一般一開始只有2鐘情況，3個(gè)的時(shí)候一般會(huì)考慮功能的封裝等等狀況了），往往項(xiàng)目往前走，會(huì)臨時(shí)地加入一些狀況，else-if分支開始爆炸，每寫一行代碼就像在牛糞上種花，你都不愿意回頭欣賞這些“花”。
整個(gè)過程就像溫水里的青蛙，你能怪產(chǎn)品燒的水么？產(chǎn)品說，我也沒蓋鍋蓋呀，你自己沒意識(shí)到要及時(shí)跳出來么？
思考
1.如果接到新需求，如何意識(shí)到代碼需要重構(gòu)？
2.如果需要重構(gòu)，如何有前瞻性的將代碼重構(gòu)好？
曾經(jīng)讀過一句話： 代碼只能重構(gòu)一次。
作為一個(gè)不合格的程序員，我花過大把的時(shí)間重構(gòu)，深知其中的痛苦。
level5的時(shí)候， 我會(huì)嘗試2遍重構(gòu)
- 代碼整理+注釋整理
- 功能分離
level6的時(shí)候， 我看透了代碼重構(gòu)是模式上的變化，于是我不再去改動(dòng)一些功能性代碼，例如交互事件
- 解耦代碼、處理違反封閉-開放原則的代碼
level7的時(shí)候，我還沒做到。我不改了，因?yàn)檫@只會(huì)讓你厭惡你最喜歡的東西。
最后，真心推薦這本書《JavaScript設(shè)計(jì)模式與開發(fā)實(shí)踐》，拯救業(yè)務(wù)代碼中天天抱怨的你。
