JS进阶 - 重构
代码优化原则
易读性优先
如果不是性能瓶颈,就不要为了性能而改写代码
复杂性守恒酬:无论你怎么写代码,复杂性都是不会梢失的
推论:如果逻辑很复杂,那么代码看起来就应该是复杂的。如果逻辑很简单,代码看起来就应该是简单的。
命名
程序员三大难题
- 变量命名
- 缓存失效
- 循环边界
可见变量命名的重要性
基本原则
注意词性
普通变量/属性(名词)
1
2
3
4
5
6
7
8var person = {
name: 'Frank'
}
var student = {
grade: 3,
class: 2
}bool 变量/属性用【形容词】【be动词】【情态动词】【hasX】
1
2
3
4
5
6var person = {
dead: false, // 形容词,没必要用 is
canSpeak: true, // 情态动词,can should will need
isVip: true // be 动词 is was
hasChildren: true // hasX
}普通函数/方法用【动词】开头
1
2
3
4
5var person = {
run(>{}, //不及物动词
drinkWater(){},//及物动词
eat(foo), //及物动词加参数(参数是名词)
}回调、钩子函数用【介词】开头,或用【动词的现在完成时态】
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23var person = {
beforeDie(){},
afterDie(){},
//或者
willDie(){}
dead(){} //此处和 bool 冲突,不同时暴露 bool dead 和 dead() 就行
}
button.addEventListener('click', onButtonClick)
var component = {
beforeCreate(){},
created(){},
beforeMount(){},
mounted(){},
beforeUpdate(){},
updated(){},
activated(){},
deactivated(){},
beforeDestroy(){},
destroyed(){},
errorCaptured(){}
}容易混淆的地方加前缀
1
2
3
4
5
6
7divl.classList.add('active') // DOM 对象
div2.addclass(’active’)// jQuery 对象
不如改成
domDivl 或 elDivl.classList.add(.active.)
$div2.addclass('active')属性访问器函数可以用名词
1
2
3
4$div.text() //其实是 $div.getText()
$div.text('hi') //其实是 $div.setText('hi')
注意一致性
介词一致性
如果你使用了 before + after,那么就在代码的所有地方都坚持使用
如果你使用了 before +完成时,那么就坚持使用
如果你改来改去,就「不一致J 了,不一致将导致「不可预测」
顺序一致性
比如
updateContainerWidth
和updateHeightOfContainer
的顺序就令人很别扭表里一致性
函数名必须完美体现函数的功能,既不能多也不能少。
1
2
3
4
5function getSongs(){
return $.get('/songs).then((response){
div.innerText = response.songs
})
}就违背了表里一致性,getSongs表示获取歌曲,并没有暗示这个函数会更新页面,但是实际上函数更新了 div,这就是表里不一, 正确的写法是
要么纠正函数名
1
2
3
4
5function getSongsAndUpdateDiv(){
return $.get('/songs).then((response){
div.innerText = response.songs
})
}要么写成两个函数
1
2
3
4
5
6
7
8
9
10
11function getSongs(){
return $get('/songs)
}
function updateDiv(songs){
div.innerText = response.songs
}
getSongs().then((response)=>{
updateDiv(resopnse.songs)
})时间一致性
有可能随着代码的变迁,一个变量的含义已经不同于它一开始的含义了,这个时候你需要及时改掉这个变量的名字。
这一条是最难做到的,因为写代码容易,改代码难。如果这个代码组织得不好,很可能会出现牵一发而动全身的情况(如全局变量 就很难改)
改代码
如果你的代码有单元铡试,那么改起来就很放心。如果没有单元铡试,就需要用「小步快跑」的策略来修改。
小步快跑的意思是说,每次只修改一点点,铡试通过后,再修改一点点,再铡试,再修改一点点……如此反复。
那么如何修改一点点呢?《重构》这本书介绍了很多方法,但是讲得挺啰嗦的,如果你有时间可以看看。
我这里只说两个经久不衰的方法。
一、 使用函数来改代码
步骤:
将一坨代码放到一个函数里
将代码依赖的外部变量作为参数
将代码的输出作为函数的返回值
给函数取一个合适的名字
调用这个函数并传入参数
这个函数里的代码如果起过5行,则依然有优化的空间,请回到第1步
二、 使用对象来改代码
如果使用了函数改造法改造后,发现有太多的小函数,则可以使用对象讲这个函数串起来。
记得「this是函数和对象的桥梁」吗,我们会用this来串联这个对象和所有函数。
最终代码:http://jsjirengu.eom/mimazaboke/l/edit7htmljs,output
一些固定的套路
表驱动编程(《代码大全》里说的)
所有——对应的关系都可以用表来做
自说明代码(以API参数为例)
把别人关心的东西放在显眼的位置
bad smell (坏味道)
有些代码可以用,但是很「臭」
哪些代码是有坏味道的
- 表里不一的代码
- 过时的注释
- 逻辑很简单,但是看起来很复杂的代码
- 相似的代码
- 重复的代码
- 总是一起出现的代码
破窗效应
此理论认为环境中的不良现象如果被放任存在,会诱使人们仿效,甚至变本加厉。一幢有少许破窗的建筑为例,如果那些窗不被修理 好,可能将会有破坏者破坏更多的窗户。最终他们甚至会闯入建筑内,如果发现无人居住,也许就在那里定居或者纵火.一面墙,如果 出现一些徐聰没有被清洗掉,很快的,墙上就布满了乱七八糟、不堪入目的东西;_条人行道有些许纸屑,不久后就会有更多垃圾,最 终人们会视若理所当然地将垃圾顺手丢弃在地上.这个现象,就是犯罪心理学中的破窗效应.