在工做中如何优化前端代码？

此为知乎问答，我把个人答案稍做整理放到这里来了。

---

原则

首先说一个最重要的优化原则：代码优化是天天都要进行的，而不是一两个月作一次大优化，那时作就已经晚了。另外因为优化是天天作的，因此你不须要一次的就过分优化，保持小步快跑便可。

这个原则为何重要？由于不少程序员会在写代码的时候说「先不优化了，等不忙的时候再优化」，而后……就没有而后了。

基本上「烂代码」就是由于「不忙的时候再优化」形成的。

别给本身写烂代码找理由

若是只要天天优化一点点代码，就能保持你的程序健康，你，能作到吗？

据我观察，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深刻浅出》课程中有所涉及，课程讲义在此。