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

江辰

共 2462字,需浏览 5分钟

 ·

2021-12-30 18:21

原则

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


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


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

别给自己写烂代码找理由

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

据我观察,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。


第五步:坚持每天优化

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


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


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


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


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




浏览 24
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报