# Code Review
在前端开发中，Code Review 是非常重要的一个环节，可以有效地提高代码质量、减少错误和维护成本。
但在大部分团队中，认真去做Code Review的很少，有的只是用lint工具扫描一遍，有的可能直接就没有这个环节，代码质量只能依赖后续测试团队。这个固然有一部分是敏捷开发带来的弊端，大部分更是因为团队不去重视的结果。更多的原因是团队内推行Code Review后发现这是一个吃力不讨好的流程，耗费时间过长，讲解枯燥，维护成本过高，收益过小。
# Code Review的好处
实际上，Code Review可以为我们带来大量的好处：
- 提高代码质量：Code Review可以帮助开发者发现潜在的问题、漏洞和错误，以及提供更好的实现方式，从而提高代码质量。
- 减少维护成本：在Code Review过程中，可以发现代码中的问题和漏洞，并及时修改，避免了在上线后出现问题需要大量时间和精力进行维护的情况。
- 加强团队协作：Code Review可以促进团队内成员之间的交流和协作，提高团队整体的代码质量和开发效率。
- 提高代码可读性：Code Review可以帮助开发者发现代码可读性的问题，例如命名、注释、代码结构等方面，从而提高代码的可读性。
- 检查代码安全性：Code Review可以检查代码中的安全问题，例如XSS、CSRF、SQL注入等，从而提高代码的安全性。
# 如何Code Review？
大部分团队Code Review失败的原因都是因为不知道如何去做，每次review的时候，都是让开发者拿自己代码逐行去讲解，底下倾听者很快就陷入细枝末节的枯燥情绪中，变得困倦。
那么我们应该如何去正确的review呢？
- 确立开发规范，包含但不局限于代码规范，命名规范等
- 代码格式问题可在开发时通过自动化工具解决，不应放在日常Code Review中
- VsCode 格式化
- 标准的Eslint规则 + husky(本地pre-commit校验)
- 代码仓库CI流水线校验
- 遵循先设计，再编码的流程。review时对照前期评审好的设计，可节省大量时间
- 技术Leader或对应模块负责人，应在一起开会前将代码提前review。开会时直接指出具体问题
在我看来，Code Review 考验的更多是技术Leader的能力，在前期刚推行Code Review时，需要Leader牺牲自己的时间去挨个审查代码。后续随着团队习惯培养到一定成功后，可以让团队内互相Review，逐渐的将这个习惯保留下来，Code Review就算成功了。
# 重点关注问题点
常见需要Code Review的问题点：
- 重要模块整体review
- 滥用全局变量
- 命名规范
- 闭包内部变量未被销毁
- 计时器是否及时清理
- 监听事件是否有解绑
- 第三方库的销毁函数，在页面卸载时也需要调用，比如EventBus：
- v-if 指令导致的内存泄露
- 异步操作是否有异常处理
- 组件是否需要拆分
- TypeScript中滥用any
- 未用防抖节流
- 动画减少回流与重绘
- 关键业务未加注释
- 等等