Offer 驾到，掘友接招！我正在参与2022春招系列活动-经验复盘，点击查看 活动详情。
最近在主导公司级code review平台的设计和开发（后面有机会也分享下整个平台的设计思路和过程吧），正好对团队内的代码review的比较多，分享一些大家很容易犯的问题。
1、数组相关的方法掌握不牢
**map()** 方法创建一个新数组，其结果是该数组中的每个元素都调用一个提供的函数后返回的结果。数组的map是用来遍历元素且对其中的元素处理后返回一个新数组的，而这里是当成了普通的遍历数组的用法。
虽然从结果上来看这段代码没有问题，但是我们写代码还是应该遵循每个方法本质的作用，最小化单一职责。像some、every、filter等方法都有遍历数组的功能，如果我们仅仅是为了遍历它，forEach才是最贴近，最匹配的方法
2、活用类型判断的方法
当我们想要判断一个变量不是undefined或者null或者空字符串''的时候，不需要通过类似a!=null && typeof(a)!=undefined && a!=''的方法，既不美观又不优雅。
我们可以使用!!将变量或者表达式强制转换成布尔类型，示例：
!!null = false
!!undefined = false
!!'' = false
!!{} = true
3、活用ES6
这个和第一条有些类似，经常看到有的同学为了找到数组中某个对应元素而将整个数组遍历去做匹配，其实我们可以直接使用find()方法返回数组中满足提供的测试函数的第一个元素的值，否则返回undefined
首先forEach不会终止，它会将整个数组都遍历一遍，而find是在找到第一个满足测试函数的值后直接返回第一个元素不会再进行无意义的遍历。
上面列出了两种可能性，即当一定能找到对应的元素时可以直接给editBtnShow赋值，若存在可能找不到的情况下find方法会返回undefined，如果我们直接使用可选链进行判断，直接赋值会造成给editBtnShow赋值为true，所以我们不能使用可选链，只能再次判断
4、谨防dom元素取值
当我们去获取dom元素的某个属性的时候，最好能加上可选链操作符以防万一。
业务代码其实会有非常多的可能性，导致Dom元素还没有加载出来就执行到了这个方法，这样肯定会报错，为了代码的健壮性和防止可能出现的情况，我是更建议加上判断的。
5、页面逻辑解耦
我们经常会遇到一种场景，就是从列表页跳转到列表项的详情页面或者编辑页面。
因为在列表页已经获取了这个列表项的所有信息了，所以很多人可能会觉得既然已经拿到了，那不如直接传到下一个页面避免多次调用接口，是不是对性能更友好？
是的，原先我也是这么以为的。直到测试给了我沉重的一击：我在详情/编辑页点击刷新后怎么数据全丢了？肯定是有bug。然后我果断把单给拒了，并给出理由：设计如此，不要没事点刷新！
直到换了个新的测试，又提出了同样的问题。当多个测试都觉得有问题了，那就是真的有问题了。但总不能把上个页面的数据存缓存吧，那挺蠢的。
这里我们就要重视页面功能的解耦了，可以在列表页通过query传递id字段，在详情/编辑页中通过id去获取这个列表项的所有信息并进行相应的处理。
注意： 路由的query参数如果传递的是对象，在页面刷新后对象的值是会丢失的，所以只能用作传递字符串，而params传递的任何参数在页面刷新后都会丢失
6、命名问题
类名的定义有很多业内成熟的比如BEM，但是我认为，只要保持团队内统一的规范都是好规范，我们在命名的过程中一定要具象化，像这个icon、name一眼过去没有获得有用信息，这样对后续维护带来的是天坑
7、数组的拷贝
拷贝问题是老生常谈了，如果要对一个响应式对象进行操作而不影响它本身的值，我们经常会需要使用到深拷贝，而通过JSON.parse(JSON.stringfy(obj))转换的方法虽然快速，但不可避免的会出现当对象不存在时导致的报错，是不利于代码的健壮性的，而使用ES6的[...arr]重新解构赋值又只是浅拷贝，会对原生对象产生影响。
深拷贝有很多实现再次就不赘述了，我提一个前不久刚出的浏览器原生的深拷贝api。可能是看我们为了深拷贝用了各种复杂的手段，HTML规范看不下去了，所以出了个深拷贝的标准提案structuredClone，详情可以去参考"structuredClone" | Can I use... Support tables for HTML5, CSS3, etc
8、减少对响应式变量的操作
众所周知，响应式数据之所以是响应式，离不开对它的时刻监听，而这种监听不可避免的会产生额外开销，一改变一开销，所以我们要尽可能地减少对响应式数据的操作。当遇到有复杂逻辑处理的情况时，可以先定义一个变量用来处理相关逻辑，最后再赋值给响应式变量
9、长字符串拼接尽量使用模板字符串
是否删除插件【${pluginInfo.plugin_display_name}】
长字符串拼接如果一直使用+号不美观也不直接，所以可以使用模板字符串
10、尽量少使用if/else
在某些情况下，if/else会使代码更直观，可读性更强。但同样会增加重复的代码，增加代码的嵌套层级，优秀的程序员向来是不会写重复代码的，我们要合理地利用封装和抽象，做个优雅的代码人。
代码规范问题除了一些常见的语法问题之外，还跟团队开发风格息息相关。有些时候可读性大于>简洁性，有时候却截然相反，没有更好更坏之分，就看各自使用的场景和取舍了。
