重构-代码优化技巧.md

代码优化原则

1. 易读性优先
2. 如果不是性能瓶颈，就不要为了性能改写代码
3. 复杂性守恒原则：无论你怎么写代码，复杂性都是不会消失的

推论：如果逻辑复杂，那么代码看起来也是复杂的

命名

程序员3大难题

1. 变量命名
2. 缓存失效
3. 循环边界

命名规范的基本原则

1. 注意词性

• 普通变量/属性用 【名词】

var person = {
        name:'Frank'
    }
    var student ={
        grade:3,
        class:2
    }

• bool变量、属性用【形容词】或者【be动词】或者【情态动词】或者【hasX】

var person ={
        dead: false, //如果是形容词，前面没有必要加is
        canSpeak: true, //情态动词有can，should，will，need等，情态动词后面接动词
        isVip: true, //be动词有is，was等，后面一般接名词
        hasChildren: true, //has 加名词
    }

• 普通函数、方法用【动词】开头

var person ={
    run(){},//不及物动词
    drinkWater(){},//及物动词
    eat(foo){},//机务动词加参数
}

• 回调，钩子函数用【介词】开头，或者用【动词的现在完成时态】

var person ={
    beforeDie(){},
    afterDie(){},
    // 或者
    willDie(){},
    dead(){}//这里跟bool冲突，你只要不同时暴露bool dead和函数dead就行，怕冲突就用上面的afterDie
}
button.addEventListener('click',onButtonClick)

var component ={
    beforeCreate(){},
    created(){},
    beforeMount(){},
    mounted(){},
    beforeUpdate(){},
    updated(){},
    activated(){},
    deactivated(){},
    beforeDestroy(){},
    destroyed(){},
    errorCaptured(){}
}

• 容易混淆的地方加前缀

div1.classList.add('active') // DOM对象
div2.addClass('active') // jQuery对象
不如改成
domDiv 或elDiv1.classList.add('active')
$div2.addClass('active')

• 属性访问器函数可以用名词

$div.text() //  $div.getText()
$div.text('hi') // $div.setText('hi')

2. 注意一致性

• 介词一致性

如果你使用了before+after ,那么就在代码所有地方都坚持使用

如果你使用了before+完成时，就坚持使用

如果改来改去，就不一致，不一致导致不可预测

• 顺序一致性

比如updateContainerWidth和updateHeightOfContainer的顺序就令人很别扭，同样引发不可预测

• 表里一致性

函数名必须完美体现函数的功能，既不多也不少

function getSongs() {
    return $.get('/songs').then((response){
        div.innerText = response.songs
    })
}

// 违背了表里一致行，getSongs表示获取歌曲，并没有暗示函数会更新页面，正确处理

（1）要么纠正函数名
function getSongsAndUpdateDiv(){
    return $.get('/songs').then((response){
        div.innerText = response.songs
    })
}

(2)要么写成两个函数

function getSongs() {
    return $.get('/songs')
}

function updateDiv(songs){
    div.innerText = response.songs
}

getSongs().then((response){
    updateDiv(response.songs)
})

• 时间一致性

有可能随着代码的变迁，一个变量的含义已经不同于他一开始的含义，就需要及时改掉这个变量的名字。 这条最难做到，因为写代码容易，改代码难。

改代码

如果有单元测试，改起来就放心。如果没有单元测试，就要用【小步快跑】

每次只修改一点点，测试通过后，再修改一点点，再测试，再修改一点点。。。。。。如此反复

重构讲了很多，其中最好的两个方法：

一，使用函数来改代码

步骤：

1. 将一坨代码放在函数里面
2. 将代码依赖的外部变量作为参数
3. 将代码的输出作为函数的返回值
4. 给函数去一个合适的名字
5. 调用这个函数并传入参数
6. 这个函数里的代码如果超过5行，则依然有优化的空间，请回到第一步

二，使用对象来改代码

如果使用了函数改造法，发现有太多小函数，则可以使用对象将这个函数串起来， this是函数和对象的桥梁

具体看最终代码

一些固定的套路

1. 表驱动编程 所有一一对应的关系都可以用表来做
2. 自说明代码（以API参数为例） 把别人关心的东西放在显眼的位置

哪些代码有 bad smell

1. 表里不一的代码
2. 过时的注释
3. 逻辑很简单，但看起来很复杂的代码
4. 重复的代码
5. 相似的代码
6. 总是一起出现的代码

破窗效应

环境中不良现象如果放任存在，会诱使人们效仿