代码优化的基本原则
易读性优先
如果不是性能瓶颈，就不要为了性能而改写代码
复杂性守恒原则
命名
程序员三大难题
变量命名 缓存失效 循环边界
原则:
注意词性
普通变量（名词）
bool 变量（形容词，be 动词，情态动词，has）
普通函数（动词）
回调/钩子函数（介词，动词的现在完成时）
容易混淆的加前缀（$xx）
属性访问器可以用名词（$div.text()）
注意一致性
介词一致性
如果你使用了 before + after，那么就在代码的所有地方都坚持使用
如果你使用了 before + 完成时，那么就坚持使用
如果你改来改去，就「不一致」了，不一致将导致「不可预测」
顺序一致性
比如 updateContainerWidth 和 updateHeightOfContainer 的顺序就令人很别扭，同样会引发「不可预测」
表里一致性
函数名必须完美体现函数的功能，既不能多也不能少。
比如
function getSongs(){
return $.get('/songs).then((response){
div.innerText = response.songs
})
}就违背了表里一致性，getSongs 表示获取歌曲，并没有暗示这个函数会更新页面，但是实际上函数更新了 div，这就是表里不一，正确的写法是
要么纠正函数名
function getSongsAndUpdateDiv(){
return $.get('/songs).then((response){
div.innerText = response.songs
})
}要么写成两个函数
function getSongs(){
return $.get('/songs)
}
function updateDiv(songs){
div.innerText = response.songs
}
getSongs().then((response)=>{
updateDiv(response.songs)
})时间一致性
有可能随着代码的变迁，一个变量的含义已经不同于它一开始的含义了，这个时候你需要及时改掉这个变量的名字。
这一条是最难做到的，因为写代码容易，改代码难。如果这个代码组织得不好，很可能会出现牵一发而动全身的情况（如全局变量就很难改）
改写代码
使用函数来改代码
步骤：
将一坨代码放到一个函数里
将代码依赖的外部变量作为参数
将代码的输出作为函数的返回值
给函数取一个合适的名字
调用这个函数并传入参数
这个函数里的代码如果超过 5 行，则依然有优化的空间，请回到第 1 步
使用对象来改代码
如果使用了函数改造法改造后，发现有太多的小函数，则可以使用对象讲这个函数串起来。
用 this 来串联这个对象和所有函数。
一些固定的套路
表驱动编程（《代码大全》里说的）
所有一一对应的关系都可以用哈希表({})来做
自说明代码（以 API 参数为例）
把别人关心的东西放在显眼的位置
哪些代码是有坏味道的
表里不一的代码
过时的注释
逻辑很简单，但是看起来很复杂的代码
重复的代码
相似的代码
总是一起出现的代码
