重構不是對之前代碼的全盤否定，而是應用更好的體式格局，寫出更好，更有保護性代碼。不停的尋求與進修，才有更多的進步。

1.媒介

做前端開闢有一段時刻了，在這段時刻內里，關於本身的請求，不僅僅是項目能完成，功用一般運用這一層面上。還全力的研討怎樣寫出文雅的代碼，機能更好，保護性更強的代碼，淺顯一點就是重構。這篇文章算是我一個小紀錄，在此分享一下。該文章重要針對引見，例子也簡樸，深切龐雜的例子等今後有適宜的實例再舉行寫作分享。假如人人對怎樣寫出文雅的代碼，可保護的代碼，有本身的意見，或許有什麼重構的氣力，迎接指導批評。

關於重構，預備寫一個系列的文章，不定時更新，重要針對以下計劃：邏輯雜沓重構，星散職責重構，增添擴大性重構，簡化運用重構，代碼復用重構。个中會交叉以下準繩：單一職責準繩，起碼學問準繩，開放-封閉準繩。假如人人對重構有什麼好的主意，或許有什麼好的實例，迎接留言批評，留下珍貴的發起。

2.什麼是重構

起首，重構不是重寫。重構也許的意義是在不影響項目的功用運用條件下，運用一系列的重構體式格局，轉變項目的內部組織。進步項目內部的可讀性，可保護性。

不管是什麼項目，都有一個從簡樸到龐雜的一個迭代歷程。在這個歷程內里，在不影響項目的運用狀況下，須要不停的對代碼舉行優化，堅持或許增添代碼的可讀性，可保護性。如許一來，就能夠防止在團隊合作開闢上須要大批的溝通，交換。才到場項目的開闢中。

3.為何重構

衣服髒了就洗，破了就補，分歧穿就扔。

跟着營業需求的不停增添，變動，捨棄，項目的代碼也難免會湧現瑕疵，這就會影響代碼的可讀性，可保護性，以至影響項目的機能。而重構的目的，就是為了處置懲罰這些瑕疵，保證代碼質量和機能。然則條件是不能影響項目的運用。

至於重構的緣由，本身總結了一下，也許有以下幾點

1. 函數邏輯組織雜沓，或由於沒解釋緣由，連原代碼寫作者都很難理清當中的邏輯。
2. 函數無擴大性可言，碰到新的變化，不能天真的處置懲罰。
3. 由於對象強耦合或許營業邏輯的緣由，致使營業邏輯的代碼龐大，保護的時刻排查難題。
4. 反覆代碼太多，沒有復用性。
5. 跟着手藝的生長，代碼能夠也須要運用新特徵舉行修正。
6. 跟着進修的深切，關於之前的代碼，是不是有着更好的一個處置懲罰計劃。
7. 由於代碼的寫法，雖然功用一般運用，然則機能斲喪較多，須要換計劃舉行優化

4.什麼時候重構

在適宜的時刻，在適宜的事變

在我的明白中，重構能夠說是貫串整一個項目的開闢和保護周期，能夠看成重構就是開闢的一部分。淺顯講，在開闢的任什麼時候刻，只需看到代碼有彆扭，激發了強迫症，就能夠斟酌重構了。只是，重構之前先參考下面幾點。

• 起首，重構是須要花時刻去做的一件事。花的時刻能夠比之前的開闢時刻還要多。
• 其次，重構是為了把代碼優化，條件是不能影響項目的運用。
• 末了，重構的難度大小不一，能夠只是輕微修改，能夠難度比之前開闢還要難。

基於上面的幾點，須要人人去評價是不是要舉行重構。評價的目的，能夠參考下面幾點

• 數目: 須要重構的代碼是不是過量。
• 質量: 可讀性，可保護性，代碼邏輯龐雜度，等題目，對代碼的質量影響是不是到了一個難以忍受的田地。
• 時刻: 是不是有富餘的時刻舉行重構和測試。
• 效果: 假如重構了代碼，獲得哪些改良，比方代碼質量進步了，機能提升了，更好的支撐後續功用等。

5.怎樣重構

選定目的，針對性反擊

怎樣重構，這個就是具體狀況，具體分析了。犹如“為何重構一樣”。發明代碼有什麼題目就針對什麼狀況舉行革新。

重構也是寫代碼，然則不止於寫，更在於整頓和優化。假如說寫代碼須要一個‘進修–相識-闇練’的歷程，那末重構就須要一個‘進修-感悟-打破-闇練’的歷程。

針對重構的狀況，下面簡樸的用幾個例子舉行申明

5-1.函數無擴大性

以下面一個例子，在我一個庫的个中一個 API

//檢測字符串
//checkType('165226226326','mobile')
//result：false
let checkType=function(str, type) {
    switch (type) {
        case 'email':
            return /^[\w-]+(\.[\w-]+)*@[\w-]+(\.[\w-]+)+$/.test(str);
        case 'mobile':
            return /^1[3|4|5|7|8][0-9]{9}$/.test(str);
        case 'tel':
            return /^(0\d{2,3}-\d{7,8})(-\d{1,4})?$/.test(str);
        case 'number':
            return /^[0-9]$/.test(str);
        case 'english':
            return /^[a-zA-Z]+$/.test(str);
        case 'text':
            return /^\w+$/.test(str);
        case 'chinese':
            return /^[\u4E00-\u9FA5]+$/.test(str);
        case 'lower':
            return /^[a-z]+$/.test(str);
        case 'upper':
            return /^[A-Z]+$/.test(str);
        default:
            return true;
    }
}

這個 API 看着沒什麼缺點，能檢測經常使用的一些數據。然則有以下兩個題目。

1.然則假如想到增添其他劃定規矩的呢？就得在函數內里增添 case 。增添一個劃定規矩就修正一次！如許違背了開放-封閉準繩（對擴大開放，對修正封閉）。而且如許也會致使全部 API 變得痴肥，難保護。

2.另有一個題目就是，比方A頁面須要增添一個金額的校驗，B頁面須要一個日期的校驗，然則金額的校驗只在A頁面須要，日期的校驗只在B頁面須要。假如一向增添 case 。就是致使A頁面把只在B頁面須要的校驗劃定規矩也增添進去，形成不必要的開支。B頁面也同理。

發起的體式格局是給這個 API 增添一個擴大的接口

let checkType=(function(){
    let rules={
        email(str){
            return /^[\w-]+(\.[\w-]+)*@[\w-]+(\.[\w-]+)+$/.test(str);
        },
        mobile(str){
            return /^1[3|4|5|7|8][0-9]{9}$/.test(str);
        },
        tel(str){
            return /^(0\d{2,3}-\d{7,8})(-\d{1,4})?$/.test(str);
        },
        number(str){
            return /^[0-9]$/.test(str);
        },
        english(str){
            return /^[a-zA-Z]+$/.test(str);
        },
        text(str){
            return /^\w+$/.test(str);
        },
        chinese(str){
            return /^[\u4E00-\u9FA5]+$/.test(str);
        },
        lower(str){
            return /^[a-z]+$/.test(str);
        },
        upper(str){
            return /^[A-Z]+$/.test(str);
        }
    };
    //暴露接口
    return {
        //校驗
        check(str, type){
            return rules[type]?rules[type](str):false;
        },
        //增添劃定規矩
        addRule(type,fn){
            rules[type]=fn;
        }
    }
})();

//挪用體式格局
//運用mobile校驗劃定規矩
console.log(checkType.check('188170239','mobile'));
//增添金額校驗劃定規矩
checkType.addRule('money',function (str) {
    return /^[0-9]+(.[0-9]{2})?$/.test(str)
});
//運用金額校驗劃定規矩
console.log(checkType.check('18.36','money'));

上面的代碼，是多了一些，然則明白起來也沒怎樣費力，而且拓展性也有了。

上面這個革新實際上是運用了戰略形式（把一系列的算法舉行封裝，使算法代碼和邏輯代碼能夠互相自力，而且不會影響算法的運用）舉行革新的。戰略形式的觀點明白起來有點繞，然則人人看着代碼，應當不繞。

這裏展開講一點，在功用上來講，經由過程重構，給函數增添擴大性，這裏完成了。然則假如上面的 checkType是一個開源項目的 API ，重構之前挪用體式格局是：checkType('165226226326','phone') 。重構以後挪用體式格局是： checkType.check('188170239','phone') ;或許 checkType.addRule() ;。假如開源項目的作者依據上面的體式格局重構，那末之前運用了開源項目的 checkType 這個 API 的開闢者，就能夠悲劇了，由於只需開闢者一更新這個項目版本，就有題目。由於上面的重構沒有做向下兼容。

假如要向下兼容，實在也不難。加一個推斷罷了。

let checkType=(function(){
    let rules={
        email(str){
            return /^[\w-]+(\.[\w-]+)*@[\w-]+(\.[\w-]+)+$/.test(str);
        },
        mobile(str){
            return /^1[3|4|5|7|8][0-9]{9}$/.test(str);
        },
        tel(str){
            return /^(0\d{2,3}-\d{7,8})(-\d{1,4})?$/.test(str);
        },
        number(str){
            return /^[0-9]$/.test(str);
        },
        english(str){
            return /^[a-zA-Z]+$/.test(str);
        },
        text(str){
            return /^\w+$/.test(str);
        },
        chinese(str){
            return /^[\u4E00-\u9FA5]+$/.test(str);
        },
        lower(str){
            return /^[a-z]+$/.test(str);
        },
        upper(str){
            return /^[A-Z]+$/.test(str);
        }
    };
    //暴露接口
    return function (str,type){
        //假如type是函數，就擴大rules，不然就是考證數據
        if(type.constructor===Function){
            rules[str]=type;
        }
        else{
            return rules[type]?rules[type](str):false;
        }
    }
})();

console.log(checkType('188170239','mobile'));

checkType('money',function (str) {
    return /^[0-9]+(.[0-9]{2})?$/.test(str)
});
//運用金額校驗劃定規矩
console.log(checkType('18.36','money'));

如許運轉能一般，也有擴大性性，然則關於代碼潔癖的來講，如許寫法不文雅。由於 checkType 違背了函數單一準繩。一個函數擔任過量的職責能夠會致使今後不可估量的題目，運用方面也很讓人迷惑。

面臨如許的狀況，就個人而言，相識的做法是：保存 checkType ，不做任何修正，在項目內里增添一個新的 API ，比方 checkTypOfString ，把重構的代碼寫到 checkTypOfString 內里。經由過程各種體式格局指導開闢者少舊 checkType ，多用 checkTypOfString 。以後的項目迭代內里，適宜的時刻燒毀 checkType 。

5-2.函數違背單一準繩

函數違背單一準繩最大一個效果就是會致使邏輯雜沓。假如一個函數負擔了太多的職責，無妨試下：函數單一準繩 — 一個函數只做一件事。

以下例子

//現有一批的錄入門生信息，然則數據有反覆，須要把數據舉行去重。然後把為空的信息，改成保密。
let students=[
    {
        id:1,
        name:'等待',
        sex:'男',
        age:'',
    },
    {
        id:2,
        name:'浪跡天涯',
        sex:'男',
        age:''
    },
    {
        id:1,
        name:'等待',
        sex:'',
        age:''
    },
    {
        id:3,
        name:'鴻雁',
        sex:'',
        age:'20'
    }
];

function handle(arr) {
    //數組去重
    let _arr=[],_arrIds=[];
    for(let i=0;i<arr.length;i++){
        if(_arrIds.indexOf(arr[i].id)===-1){
            _arrIds.push(arr[i].id);
            _arr.push(arr[i]);
        }
    }
    //遍歷替代
    _arr.map(item=>{
        for(let key in item){
            if(item[key]===''){
                item[key]='保密';
            }
        }
    });
    return _arr;
}
console.log(handle(students))

運轉效果沒有題目，然則人人想一下，假如今後，假如改了需求，比方，門生信息不會再有反覆的紀錄，請求把去重的函數去掉。如許一來，就是全部函數都要改了。還影響到下面的操縱流程。相當於了改了需求，全部要領全跪。城門失火殃及池魚。

下面運用單一準繩組織一下

let handle={
    removeRepeat(arr){
        //數組去重
        let _arr=[],_arrIds=[];
        for(let i=0;i<arr.length;i++){
            if(_arrIds.indexOf(arr[i].id)===-1){
                _arrIds.push(arr[i].id);
                _arr.push(arr[i]);
            }
        }
        return _arr;
    },
    setInfo(arr){
        arr.map(item=>{
            for(let key in item){
                if(item[key]===''){
                    item[key]='保密';
                }
            }
        });
        return arr;
    }
};
students=handle.removeRepeat(students);
students=handle.setInfo(students);
console.log(students);

效果一樣，然則需求改下，比方不須要去重，把代碼解釋或許直接刪除就好。如許相當於把函數的職責星散了，而且職責之前互不影響。中心去除誰人步驟不會影響下一步。

//students=handle.removeRepeat(students);
students=handle.setInfo(students);
console.log(students);

5-3.函數寫法優化

這類狀況就是，關於之前的函數，在不影響運用的狀況下，如今有着更好的完成體式格局。就運用更好的處置懲罰計劃，替代之前的處置懲罰計劃。

比方下面的需求，需求是群里一個朋儕發出來的，厥後激發的一些議論。給出一個20180408000000字符串，formatDate函數要處置懲罰並返回2018-04-08 00:00:00。

之前的解法

let _dete='20180408000000'
function formatStr(str){
    return str.replace(/(\d{4})(\d{2})(\d{2})(\d{2})(\d{2})(\d{2})/, "$1-$2-$3 $4:$5:$6")
}
formatStr(_dete);
//"2018-04-08 00:00:00"

厥後研討了如許的解法。這個體式格局就是依據x的位置舉行替代添補數據，不難明白

let _dete='20180408000000'
function formatStr(str,type){
    let _type=type||"xxxx-xx-xx xx:xx:xx";
    for(let i = 0; i < str.length; i++){
        _type = _type.replace('x', str[i]);
    }
    return _type;
}
formatStr(_dete);
result:"2018-04-08 00:00:00"

在以後的幾天，在掘金一篇文章（那些文雅靈性的JS代碼片斷，謝謝供應的珍貴體式格局）的批評內里發明更好的完成體式格局，下面依據上面的需求本身舉行革新。

let _dete='20180408000000'
function formatStr(str,type){
    let i = 0,_type = type||"xxxx-xx-xx xx:xx:xx";
    return _type .replace(/x/g, () => str[i++])
}
formatStr(_dete);
result:"2018-04-08 00:00:00"

5-4.代碼復用

上面幾個例子都是js的，說下與html沾邊一點的兩個例子–vue數據襯着。

下面代碼中，
payChannelEn2Cn
addZero
formatDateTime函數都是在vue的
methods內里。人人注重。

之前寫法

<span v-if="cashType==='cash'">現金</span>
<span v-else-if="cashType==='check'">支票</span>
<span v-else-if="cashType==='draft'">匯票</span>
<span v-else-if="cashType==='zfb'">付出寶</span>
<span v-else-if="cashType==='wx_pay'">微信付出</span>
<span v-else-if="cashType==='bank_trans'">銀行轉賬</span>
<span v-else-if="cashType==='pre_pay'">預付款</span>

如許寫的題目在於，起首是代碼多，第二是假如項目有10個處所如許襯着數據，假如襯着的需求變了。比方銀行轉賬的值從 bank_trans 改成 bank ，那末就得在項目內里修正10次。時刻本錢太大。
厥後就運用了下面的寫法，算是一個小重構吧

<span>{{payChannelEn2Cn(cashType)}}</span>

payChannelEn2Cn 函數，輸出效果

payChannelEn2Cn(tag){
    let _obj = {
        'cash': '現金',
        'check': '支票',
        'draft': '匯票',
        'zfb': '付出寶',
        'wx_pay': '微信付出',
        'bank_trans': '銀行轉賬',
        'pre_pay': '預付款'
    };
    return _obj[tag];
}

另有一個例子就是時刻戳轉時刻的寫法。道理一樣，只是代碼差別。下面是本來的代碼。

<span>{{new Date(payTime).toLocaleDateString().replace(/\//g, '-')}} 
{{addZero(new Date(payTime).getHours())}}:
{{addZero(new Date(payTime).getMinutes())}}:
{{addZero(new Date(payTime).getSeconds())}}</span>

addZero時刻補零函數

Example:3->03
addZero(i){
    if (i < 10) {
        i = "0" + i;
    }
    return i;
}

題目也和上面的一樣，這裏就不多說了，就寫重構后的代碼

<span>{{formatDateTime(payTime)}} </span>

formatDateTime函數，格式化字符串

formatDateTime(dateTime){
    return `${new Date(payTime).toLocaleDateString().replace(/\//g, '-')} ${this.addZero(new Date(payTime).getHours())}:${this.addZero(new Date(payTime).getMinutes())}:${this.addZero(new Date(payTime).getSeconds())}`;
}

能夠很多人看到這裏，以為重構很簡樸，如許想是對的，重構就是這麼簡樸。然則重構也難，由於重構平步青雲，須要一個逐漸的歷程，以至能夠說重構就是一次次的小修改，逐漸形成一個質變的歷程。怎樣保證每一次的修改都是有意義的改良代碼；怎樣保證每一次的修改都不會影響到項目的一般運用；假如發明某次修改沒有意義，或許修改了反而讓代碼更蹩腳的時刻，能夠隨時住手或回滾代碼，這些才是重構的難點。

6.小結

關於重構就說到這裏了，該文章重如果引見重構，例子方面都是很簡樸的一些例子。目的是為了好些明白重構的一些觀點。關於重構，能夠很龐雜，能夠很簡樸。怎樣重構也是具體狀況，具體分析，重構也沒有規範的答案。今後，假如有好的例子，我會第一時刻分享，給人人具體狀況，具體分析的報告：為何重構，怎樣重構。

末了，假如人人對文章有什麼發起，意見，迎接交換，互相進修，共同進步。

————————-華美的分割線——————–

想相識更多，關注關注我的微信民眾號：等待書閣