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

原则

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

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

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

别给自己写烂代码找理由

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

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

这个项目我只维护几个月，没必要把代码写那么好，反正有人接盘。

这个项目是从别人手里接下的，代码真烂，要怪就怪之前的人，不是我的错，我胡乱加一些代码就行了，能用就行。

这是一个短期项目，没必要把代码写那么好

这是一个长期项目，明年再优化代码，现在能用就行

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

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

过手就变好

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

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

接下来就是技巧。

第一步：不要写烂代码

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

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

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

coolshell.cn/articles/4758.html

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

烂变量名

烂注释

烂设计

不写测试（所有没有单元测试的代码都是烂代码，快点学习单元测试！）

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

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

所以第一步就是明白一个真相：你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 } }

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

优化后：

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

优化前：

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

12

13

优化后：

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'] }

1

2

3

4

5

6

7

8

9

10

11

第四步：用套路

设计模式就是一些编程套路，Unix 编程原则也是一些编程套路。

了解所有的套路，然后遇到问题选择正确的套路即可。

比如模块通信一般用事件模式或者命令模式；

比如解耦一般用中间层；

比如生命周期一般都支持钩子或切面；

比如性能优化一般都是加缓存；

比如 API 设计一定要正交；

比如复杂数据系统一般使用命令查询职责分离；

比如拿空间换时间拿时间换空间；

……

这一块还挺复杂的，够你纠结很久了，而且没有通解。唯一的通解就是 tradeoff。

第五步：坚持每天优化

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

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

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

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

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

web前端 开发者

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。