在工作中如何优化前端代码

原则

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

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

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

别给自己写烂代码找理由

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

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

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

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

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

过手就变好

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

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

接下来就是技巧。

第一步:不要写烂代码

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

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

如何写出无法维护的代码 - 酷 壳

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

  1. 烂变量名
  2. 烂注释
  3. 烂设计
  4. 不写测试(所有没有单元测试的代码都是烂代码,快点学习单元测试!)

基本上所有新人天天都在写烂变量名、烂注释和烂设计,而且还不写单元测试。

而且他们还不知道自己代码多烂!

所以第一步就是明白一个真相:你80%的代码都是烂代码。

你只需要把这些代码改得不那么烂,就是优秀的代码了……

再说一次:第一步至关重要,搞清楚什么样的代码是烂代码。

第二步:避免重复

也就是 Don’t Repeat Yourself 原则。

如果你发现有两行代码重复出现了好几次,你就应该把这两行代码封装成一个函数,放在一个恰当的地方,然后调用这个函数。

第三步:表驱动编程

如果你的代码有很多 if … else … 结构,你不知道怎么优化,你就应该使用表驱动编程。

优化前:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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
}
}

优化后:

1
2
3
4
5
6
7
8
9
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]
}
复制代码

优化前:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
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'
}
}
复制代码

优化后:

1
2
3
4
5
6
7
8
9
10
11
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。

第五步:坚持每天优化

「每天优化」才叫重构,「每年优化」那叫重写。

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

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

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

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

坚持原创技术分享,您的支持将鼓励我继续创作!