# 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
- 未用防抖节流
- 动画减少回流与重绘
- 关键业务未加注释
- 等等