可否举例说明你在工作中是如何优化前端代码的?

原则

首先说一个最重要的优化原则:代码优化是每天都要进行的,而不是一两个月做一次大优化,那时做就已经晚了。另外由于优化是每天做的,所以你不需要一次的就过度优化,保持小步快跑即可。

这个原则为什么重要?因为很多程序员会在写代码的时候说「先不优化了,等不忙的时候再优化」,然后……就没有然后了。

基本上「烂代码」就是因为「不忙的时候再优化」造成的。

别给自己写烂代码找理由

如果只要每天优化一点点代码,就能保持你的程序健康,你,能做到吗?

据我观察,90% 的程序员做不到。他们每天都会在心里找出如下理由来写出烂代码,或者对现有的烂代码视而不见:

  1. 这个项目我只维护几个月,没必要把代码写那么好,反正有人接盘。
  2. 这个项目是从别人手里接下的,代码真烂,要怪就怪之前的人,不是我的错,我胡乱加一些代码就行了,能用就行。
  3. 这是一个短期项目,没必要把代码写那么好
  4. 这是一个长期项目,明年再优化代码,现在能用就行

所以你看,不管我告诉他们多少优化代码的技巧,他们根本就不会去用的,这才是问题所在。

很多程序员抱怨公司代码烂,却从来不去尝试解决问题。(就像很多程序员抱怨培训班教出来的人水平差,自己却不写新人教程一样)

过手就变好

如果你不想变成上面那样的程序员,你只坚定一个信念:只要是经过我的手的代码,质量就会比原来好一点。

那么你很快就能把代码写好了。你可能急于听到把代码写好的技巧,但是我告诉你,技巧真的不重要,这个信念才是最重要的。

接下来就是技巧。

第一步:不要写烂代码

方方你是傻了吗,问的是「如何优化代码」,你的答案居然是「不要写烂代码」?!

没错,把代码写好的第一步就是不要写烂代码,也就是你要知道「什么样的代码是烂代码」:

如何写出无法维护的代码 - 酷 壳 - CoolShell coolshell.cn/articles/4758.html

上面这篇教程非常好,把市面上的烂代码基本都总结出来了,大概有这么几类:

  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。

第五步:坚持每天优化

我在课上说过,「每天优化」才叫重构,「每年优化」那叫重写。

优化的重点是「越来越好」,重点不是「一次写好」。

一旦你放松对自己代码的要求,你的代码就会迅速变成烂代码,而且很难恢复。

每当需求变化的时候,你都要重新审视你的整个系统,哪里有问题你就改那里,不允许「先临时改一下以后再优化」,你的代码就可以保持健康和活力。

可惜,大部分人做不到。就算我自己也会在需求太多的时候放松对代码的要求。


上一篇:使用打印流优化数据输出 | 带你学《Java语言高级特性》之六十五


下一篇:漫游配置文件修改为强制配置文件|ntuser.dat ntuser.man