套路化开发——高效工作才能开心摸鱼
前言
本文只是告诉你如何又快又好地开发代码，极致追求性能请看大佬们的性能优化，追求风格统一请看大厂的代码规范。
在框架和库都已经决定好，且已经有成堆的老代码的情况下（这往往也是我们大多数时候的开发场景），如何高效地完成需求，然后愉快地摸鱼呢？本人的答案是，套路化开发。
这个套路有三个前置条件：
- 熟悉库
- 熟悉开发工具
- 熟悉业务代码
1. 前置条件
1.1 熟悉库
作为一名调包侠，深谙不重复造轮子的道理，也就是DRY（Don`t Repeat Yourself）。所以在平时积累常用代码，或者熟悉如lodash之类的库，在需要时写出来，可以帮助你在开发时少走弯路，减少代码冗余，少写几行bug。（lodash官网）常用的工具函数有：格式化时间，防抖节流，类型判断等。
1.2 熟悉开发工具
本人习惯使用的开发工具是VSCode，在熟悉开发工具后效率起码提升50%（VSCode常用指令）个人常用的操作有：跨单词移动光标，多行同时编辑，快速复制/移动单行或多行代码等。
1.3 熟悉业务代码
只有熟悉业务代码了业务代码才能知道哪里有老代码可以借鉴，或者复用。
2. 套路化开发
好了，终于进入正题了。不同开发团队的软件开发模式不同，瀑布、迭代、螺旋、敏捷，本文只从一头摸鱼攻城狮的角度，阐述个人在这些模式中如何高效开发代码。
套路按三步走:
- 明确需求
- 开发代码
- 清除BUG
2.1 明确需求
需求是不确定的，所以我们需要将其转化为明确的要求，包括：1.按规则要求的、2.明确提出的、3.按习惯默认的。
不明确需求会导致无意义的返工，误解的程度越大，南辕北辙的距离就越远，换言之，要加班。在敏捷开发中，开发人员需要反串BA（业务需求分析师）来讲需求，就是为了避免误解，个人建议在理解需求的同时先实打实的写好伪代码的方案，然后分析技术的难点和需求的不合理之处，及时反馈。
2.2 开发代码
计划赶不上变化，所以从一头摸鱼攻城狮的角度来看，一套好的代码必定是写完之后很好读，读完之后很好改，改完之后很好用的代码，因为这意味着bug少，也意味着很好改，换言之，不加班。
2.2.1 好读
往往我们在开发的过程中，总是会时不时冒出这样的想法：这辣鸡代码哪个Super Boy写的，读起来真恶心。而好读的代码有两个标准：1.逻辑简单清晰、2.有充分的指引。当代码量足够多的时候，这两点就决定了你的代码究竟是迷宫，还是超市。换言之，KISS（Keep it simple and stupid）。
2.2.1.1 及时return
有时我们会写这样的代码
if (a === 1) {
if(b > 0) {
...
}
}
及时return让你的代码不至于嵌套过深，比如改成如下代码，看起来就简洁多了。
if (a !== 1) {return}
if ( b <= 0) {return}
...
2.2.1.2 降低圈复杂度
圈复杂度可以理解为代码中if、else、switch、for、while等判断和嵌套的语句数量，尽量降低圈复杂度，能提高可读性。圈复杂度低的代码不一定好，但是圈复杂度高的代码一定不好。比如switch...case的语句，其实可以使用对象或数组来替代：
switch(c){
case 'd':
console.log(1);
break;
case 'e':
console.log(3);
break;
}
可以改成：
const f = {d:1,e:3};
console.log(f[c]);
2.2.1.3 函数代码小于50行
过大的函数不易读，也不易于引擎优化，建议提取出一些工具函数，即使不能复用，也能整理代码。
2.2.1.4 函数功能单一
就像你涮火锅调调料一样，只有每种调料尽可能单纯，才可以随意组合搭配，如果一种调料风味过于复杂，反而不好搭，函数也是如此，尽可能功能单一，不仅容易复用，容易读，也容易维护。
2.2.1.5 入口函数
建议创建一个init函数作为入口函数，然后将每个步骤的代码封装成一个个函数，这样代码逻辑会比较清晰。
2.2.1.6 见名知意
在给标识符（即函数名，变量名，函数参数或者对象属性）命名时尽量使用英文，使用动词加名词的形式，长一点没关系，重要的是看名字就知道用来干嘛的。
2.2.1.7 及时注释
多写注释，个人建议可以先写伪代码，然后在开发过程中就可以将这些伪代码作为注释使用。
2.2.2 好改
其实基本上一段代码好读就很好改了，主要需要注意的是尽可能不要hard code，使用变量替代hard code，还有复用函数而不是复制粘贴改一改，这样可以在需要改动时只需要改一处而非多处，否则费时费力不说，还容易出bug。
2.2.3 好用
怎样算一段好用的代码，测试说了算，可以自己进行白盒测试（也就是跑一跑代码，检验逻辑是否正常）或者黑盒测试（模拟用户，随手乱点）。最好能拿到测试的测试用例，防止测试不通过，打回返工，可以一遍完成的事情那就一遍完成，不然留下的坑会在未来的某个时候害你加班。
2.3 清除BUG
谁也无法保证自己的代码没有BUG，因此在写完一段代码后，可以先清除一下常见BUG。
初始化：保证函数（或全局变量）每次起始条件相同才能有相同的输出。
考虑边界条件：考虑在开头或者结尾之类的边界条件。
兼容性：换不同浏览器试试。
容错：不要相信后端会一直返回正确代码，适当容错。
整理代码：去除无用代码，合并重复代码。
去重：去除重复执行的操作，比如使用防抖节流函数。
