在工做中如何優化前端代碼？

此爲知乎問答，我把個人答案稍做整理放到這裏來了。

---

原則

首先說一個最重要的優化原則：代碼優化是天天都要進行的，而不是一兩個月作一次大優化，那時作就已經晚了。另外因爲優化是天天作的，因此你不須要一次的就過分優化，保持小步快跑便可。

這個原則爲何重要？由於不少程序員會在寫代碼的時候說「先不優化了，等不忙的時候再優化」，而後……就沒有而後了。

基本上「爛代碼」就是由於「不忙的時候再優化」形成的。

別給本身寫爛代碼找理由

若是隻要天天優化一點點代碼，就能保持你的程序健康，你，能作到嗎？

據我觀察，90% 的程序員作不到。他們天天都會在內心找出以下理由來寫出爛代碼，或者對現有的爛代碼視而不見：

1. 這個項目我只維護幾個月，不必把代碼寫那麼好，反正有人接盤。
2. 這個項目是從別人手裏接下的，代碼真爛，要怪就怪以前的人，不是個人錯，我胡亂加一些代碼就好了，能用就行。
3. 這是一個短時間項目，不必把代碼寫那麼好
4. 這是一個長期項目，明年再優化代碼，如今能用就行

因此你看，無論我告訴他們多少優化代碼的技巧，他們根本就不會去用的，這纔是問題所在。

不少程序員抱怨公司代碼爛，卻歷來不去嘗試解決問題。（就像不少程序員抱怨培訓班教出來的人水平差，本身卻不寫新人教程同樣）

過手就變好

若是你不想變成上面那樣的程序員，你只堅決一個信念：只要是通過個人手的代碼，質量就會比原來好一點。

那麼你很快就能把代碼寫好了。你可能急於聽到把代碼寫好的技巧，可是我告訴你，技巧真的不重要，這個信念纔是最重要的。

接下來就是技巧。

第一步：不要寫爛代碼

方方你是傻了嗎，問的是「如何優化代碼」，你的答案竟然是「不要寫爛代碼」？！

沒錯，把代碼寫好的第一步就是不要寫爛代碼，也就是你要知道「什麼樣的代碼是爛代碼」：

如何寫出沒法維護的代碼 - 酷 殼

上面這篇教程很是好，把市面上的爛代碼基本都總結出來了，大概有這麼幾類：

1. 爛變量名
2. 爛註釋
3. 爛設計
4. 不寫測試（全部沒有單元測試的代碼都是爛代碼，快點學習單元測試！）

基本上全部新人每天都在寫爛變量名、爛註釋和爛設計，並且還不寫單元測試。

並且他們還不知道本身代碼多爛！

因此第一步就是明白一個真相：你80%的代碼都是爛代碼。

你只須要把這些代碼改得不那麼爛，就是優秀的代碼了……

再說一次：第一步相當重要，搞清楚什麼樣的代碼是爛代碼。

第二步：避免重複

也就是 Don't Repeat Yourself 原則。若是你發現有兩行代碼重複出現了好幾回，你就應該把這兩行代碼封裝成一個函數，放在一個恰當的地方，而後調用這個函數。

第三步：表驅動編程

若是你的代碼有不少 if ... else ... 結構，你不知道怎麼優化，你就應該使用表驅動編程。

優化前：

howManyDays(year, month){
    if(month === 1 ||
        month === 3 ||
        month === 5 ||
        month === 7 ||
        month === 8 ||
        month === 10 ||
        month === 12
    ){
        return 31
    }else if(month === 2){
        return isLeapYear(year) ? 29 : 28
    }else{
        return 30
    }
}
複製代碼

優化後：

howManyDays(year, month){
    const table = {
        1: 31, 3: 31, 5: 31, 7: 31, 8: 31, 10: 31, 12:31,
        4: 30, 6:30, 9: 30, 11: 30,
        2: isLeapYear(year) ? 29 : 28
    }
    return table[month]
}
複製代碼

優化前：

function calculateGrade(score){
    if(score>=90){
        return 'A'
    }else if(score >= 80){
        return 'B'
    }else if(score >= 70){
        return 'C'
    }else if(score >= 60){
        return 'D'
    }else {
        return 'E'
    }
}
複製代碼

優化後：

function calculateGrade(score){
    const table = {
        100: 'A', 
        90: 'A',
        80: 'B',
        70: 'C',
        60: 'D',
        others: 'E'
    }
    return table[Math.floor(score/10)*10] || table['others']
}    
複製代碼

第四步：用套路

設計模式就是一些編程套路，Unix 編程原則也是一些編程套路。

瞭解全部的套路，而後遇到問題選擇正確的套路便可。

好比模塊通訊通常用事件模式或者命令模式；

好比解耦通常用中間層；

好比生命週期通常都支持鉤子或切面；

好比性能優化通常都是加緩存；

好比 API 設計必定要正交；

好比複雜數據系統通常使用命令查詢職責分離；

好比拿空間換時間拿時間換空間；

……

這一塊還挺複雜的，夠你糾結好久了，並且沒有通解。惟一的通解就是 tradeoff。

第五步：堅持天天優化

我在課上說過，「天天優化」才叫重構，「每一年優化」那叫重寫。

優化的重點是「愈來愈好」，重點不是「一次寫好」。

一旦你放鬆對本身代碼的要求，你的代碼就會迅速變成爛代碼，並且很難恢復。

每當需求變化的時候，你都要從新審視你的整個系統，哪裏有問題你就改那裏，不容許「先臨時改一下之後再優化」，你的代碼就能夠保持健康和活力。

惋惜，大部分人作不到。就算我本身也會在需求太多的時候放鬆對代碼的要求。

以上內容在個人《JS深刻淺出》課程中有所涉及，課程講義在此。