Code Review

Code Review（代码审查）是软件开发中的最佳实践之一，可以有效提高整体代码质量，及时发现代码中可能存在的问题。包括像Google、微软这些公司，Code Review都是基本要求，代码合并之前必须要有人审查通过才行。

然而对于大部分软件开发团队来说，认真做Code Review的很少，有的流于形式，有的可能根本就没有Code Review的环节，代码质量只依赖于事后的测试。

把Code Review作为开发流程的必选项而不是可选项

有些团队将代码审查作为代码流程的一部分，但只是一个可选项，没有Code Review也可以把代码合并到master。这样的结果就是想起来才会去做Code Review，去检查的时候已经有了太多的代码变更，审查起来非常困难，另外就算审查出问题，也很难得以修改。

把Code Review 作为开发流程的必选项后，不代表Code Review这件事就可以执行的很好，因为Code Review 的执行，很大部分程度上依赖于审查者的认真审查，以及被审查者的积极配合，两者缺一不可！如果仅仅只是当作一个流程制度，那么就可能会流于形式。最终结果就是看起来有Code Review，但没有人认真审查，随便看下就通过了，或者发现问题也不愿意修改。真要把Code Review这件事做好，必须让Code Review变成团队的一种文化，开发人员从心底接受这件事，并认真执行这件事。

遇到紧急情况，来不及代码审查怎么办？

虽然原则上，必须要Code Review才能合并，但有时候确实会存在一些紧急情况，比如说线上故障补丁紧急fix，标准做法是：这种情况下，在任务管理系统中创建一个Ticket，用来后续跟踪，确保后续补上Code Review，并对Code Review结果有后续的代码更新。
但是我们团队针对这种情况无需过于较真，这种情况只要线上没问题，Code Review可以不做。除此之外其他情况必须做Code Review。

CODE REVIEW流程，如下图：

代码在提交CODE REVIEW之前，自己先REVIEW和测试一遍

我在做代码审查的时候，有时候会发现一些非常明显的问题，有些甚至自己都没有测试过，就等着别人Code Review和测试帮助发现问题。这种依赖心理无论是对自己还是对团队都是很不负责任的。一个好的开发人员，代码在提交Code Review之前，肯定是要自己先Review一遍，把该写的自动化测试代码写上，自己把基本的测试用例跑一遍的。

code review 时机

提的PR要保证有足够的时间被review，提测前后，最晚提测后一天，自行选择时间。

PR检查内容

• PR 描述

1. PR的详细描述可以附带相关需求链接粘贴在PR描述中，方便代码审查者详细了解PR背景；
2. 如果所提PR，与其他的PR有相互依赖，需要在描述里说明清楚

• PR 内容

1.主逻辑与业务需求没有明显错误或者含糊不清，程序逻辑是否清晰,主次是否够分明（重点）

2.检查代码是否符合编码规范，包括组件命名，变量命名等

3.Vue生命周期按顺序排列，放在方法定义前面，无用生命周期删除掉

4.如果有自定义监听事件，必须在unmount中移除

5.避免重复代码工作，公共方法提取，公共组件提取

6.为了使代码可读性强，易于维护，PR中要在关键功能点或者容易造成困扰的地方增加注释

7.commit信息简要描述本次改动的主要功能。反面例子：fix bug

8.对于疑惑点，通过当面沟通，提升review效率

9.代码评审，也非常有必要评审代码是否存在安全性问题（重点）

• 输入校验：应该始终对任何来自外部的输入数据进行校验，以确保它们符合预期并且不会对系统造成伤害。校验应该包括检查数据的类型、大小和格式。
• 防范跨站脚本攻击（XSS）：在Web应用程序中，应该始终对输入的HTML、JavaScript和CSS进行校验，并转义特殊字符，以防止XSS攻击。
• 避免敏感信息泄露：敏感信息（如密码、密钥、会话ID等）应该在传输和存储时进行加密，以防止被未经授权的人访问。同时，应该避免在日志、调试信息或错误消息中泄露敏感信息。
• 防范跨站请求伪造（CSRF）： 应该为所有敏感操作（如更改密码、删除数据等）添加CSRF令牌，以防止未经授权的人员执行这些操作。
• 防范安全漏洞：应该使用安全性高的算法和协议（如HTTPS、TLS）来保护敏感数据的传输和存储，并定期对系统进行漏洞扫描和安全性审计。