重构 - 代码优化技巧 绝地灬酷狼 2021-07-05 01:47 446阅读 0赞 这次课讲的是「如何提高代码的可读性」,跟前端关系不大,是写代码的普遍技巧。 注意我们讲得不是「如何提高代码的性能」。 ## 代码优化基本原则 ## 1. 易读性优先 2. 如果不是性能瓶颈,就不要为了性能而改写代码 3. 复杂性守恒原则:无论你怎么写代码,复杂性都是不会消失的 推论:如果逻辑很复杂,那么代码看起来就应该是复杂的。如果逻辑很简单,代码看起来就应该是简单的。 ## 命名 ## 程序员三大难题 1. 变量命名 2. 缓存失效 3. 循环边界 可见变量命名的重要性。 网上有很多命名规范,大家可以参考。本节课只讲基本原则。 ### 一、注意词性 ### * 普通变量/属性用「名词」 var person = { name: 'Frank' } var student = { grade: 3, class: 2 } * bool变量/属性用「形容词」或者「be动词」或者「情态动词」或者「hasX」 var person = { dead: false, // 如果是形容词,前面就没必要加 is,比如isDead 就很废话 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 对象 不如改成 domDiv1 或 elDiv1.classList.add('active') $div2.addClass('active') 属性访问器函数可以用名词 $div.text() // 其实是 $div.getText() $div.text('hi') // 其实是 $div.setText('hi') ### 二、注意一致性 ### * 介词一致性 如果你使用了 `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) }) * 时间一致性 有可能随着代码的变迁,一个变量的含义已经不同于它一开始的含义了,这个时候你需要及时改掉这个变量的名字。 这一条是最难做到的,因为写代码容易,改代码难。如果这个代码组织得不好,很可能会出现牵一发而动全身的情况(如全局变量就很难改) ## 改代码 ## 如果你的代码有单元测试,那么改起来就很放心。如果没有单元测试,就需要用「小步快跑」的策略来修改。 小步快跑的意思是说,每次只修改一点点,测试通过后,再修改一点点,再测试,再修改一点点……如此反复。 那么如何修改一点点呢?《重构》这本书介绍了很多方法,但是讲得有点抽象的,如果你有时间可以看看。 我这里只说两个经久不衰的方法。 ### 一、使用函数来改代码 ### 步骤: 1. 将一坨代码放到一个函数里 2. 将代码依赖的外部变量作为参数 3. 将代码的输出作为函数的返回值 4. 给函数取一个合适的名字 5. 调用这个函数并传入参数 6. 这个函数里的代码如果超过 5 行,则依然有优化的空间,请回到第 1 步 ### 二、使用对象来改代码 ### 如果使用了函数改造法改造后,发现有太多的小函数,则可以使用对象将这些函数串起来。 记得我们讲过「`this` 是函数和对象的桥梁」吗,我们会用 `this` 来串联这个对象和所有函数。 ## 一些固定的套路 ## 1. 表驱动编程(《代码大全》里说的) 所有一一对应的关系都可以用表来做 1. 自说明代码(以 API 参数为例) 把别人关心的东西放在显眼的位置 ## bad smell(坏味道) ## 有些代码可以用,但是很「臭」。 哪些代码是有坏味道的 1. 表里不一的代码 2. 过时的注释 3. 逻辑很简单,但是看起来很复杂的代码 4. 重复的代码 5. 相似的代码 6. 总是一起出现的代码 ## 破窗效应 ## > 此理论认为环境中的不良现象如果被放任存在,会诱使人们仿效,甚至变本加厉。一幢有少许破窗的建筑为例,如果那些窗不被修理好,可能将会有破坏者破坏更多的窗户。最终他们甚至会闯入建筑内,如果发现无人居住,也许就在那里定居或者纵火。一面墙,如果出现一些涂鸦没有被清洗掉,很快的,墙上就布满了乱七八糟、不堪入目的东西;一条人行道有些许纸屑,不久后就会有更多垃圾,最终人们会视若理所当然地将垃圾顺手丢弃在地上。这个现象,就是犯罪心理学中的破窗效应。 程序员要做到:只要是经过你手的代码,都会比之前好一点。
还没有评论,来说两句吧...