• 提高代码质量，及早发现潜在缺陷，降低修改/弥补缺陷的成本
• 促进团队内部知识共享，提高团队整体水平
• 评审过程对于评审人员来说，也是一种思路重构的过程，帮助更多的人理解系统
• 是一个传递知识的手段，可以让其它并不熟悉代码的人知道作者的意图和想法，从而可以在以后轻松维护代码
• 可以被用来确认自己的设计和实现是一个清楚和简单的
• 鼓励相互学习对方的长处和优点

1. 指定规范和标准

​ 1.审查代码

​ 2.发现问题，反馈原作者，讨论可行性

​ 3.清晰准确的记录优化点(Issue，pr)

​ 4.实施修改并提交

​ 5.重新评审该代码，确认通过或重复流程

​ 6.关闭(Issue，pr)

​ 1.会议讨论优化点和收获

​ 2.做好自我总结

1.经常，随时进行CodeReview，但是上线前不要进行太大的改动。

2.尽可能让不同的人Review你的代码，不同的人有不同的思路，但也不要超过3个，以免人多嘴杂适得其反。

3.无论是代码作者，还是评审者，都需要一种积极向上的正面的态度，注意说话口吻，不能以指责，嘲笑的口吻抨击他人，我们评论的是代码，不是针对人。作者需要能够虚心接受别人的建议，因为别人的建议是为了让你做得更好；禁止说：“you can you up，要不你来写？”。评审者也需要以一种积极的正面的态度向作者提意见，尽量不说说：“你这里有问题，你这写的什么垃圾代码...”，很容易爆发冲突。应该这样说是：“hello，这段逻辑这么写是不是会更高？”

4.学会享受Code Review，这里是一个团队，大家互相学习，互相帮助，互相进步。

Code Review主要检查代码中是否存在以下方面问题：

• 1.正确性检查

  • 命名规范：
    • 代码的类名，变量名，函数名等必须严格遵循命名规范
    • 命名是否清晰准确的描述了子程序（命名空间，类，变量，函数）
  • 注释规范：
    • 注释是否足够清晰，准确，简洁的描述每个子程序
    • 类：每个类必须有描述性注释，说明类的Desc。工具类更要清晰的说明干什么？和怎么用？
    • 函数：每个函数必须有描述性注释，说明函数的Desc
    • 变量：静态变量和常量，必须有注释。普通类的全局变量，不一定非要全部加注释，应尽量从变量命名中体现注释
  • 日志规范：
    • 日志要正确分清和使用Error，Warning和Debug，禁止乱用。
    • 常驻的日志都要有用，不要留太多无用的测试日志。
    • 减少或合并不必要的日志。

• 2.安全性检查

  • 代码是否采取措施避免运行时错误（如数组边界溢出、被零除、值越界、堆栈溢出等）
  • 代码中的实现技术是否便于测试
  • 内存是否有溢出

• 3.可维护性检查（复用性和扩展性）

  • 单一原则：模块，类，函数等，应该保持单一原则，只做一件事。
  • DRY（Do not Repeat Yourself）原则：同一代码不应该重复两次以上
  • 考虑代码继承结构的合理性，考虑代码组合结构的合理性
  • 考虑可重用的服务，功能和组件
  • 考虑通用函数和类
  • 考虑扩展性时，是否可以对现有代码进行最小的更改
  • 代码涉及到的常量是否易于修改(如使用配置表、定义为类常量、使用专门的常量类等)
  • 第三方库的扩展，一定要单独写扩展类，禁止直接修改源码

• 4.性能

  • 使用合适的数据类型，例如StringBuilder，通用集合类
  • 运行时卡顿，考虑延迟加载，异步和并行处理
  • 考虑会话/应用程序数据缓存，避免重复IO
  • 资源是否被重复加载，资源是否需要释放
  • 是否频繁的使用（尤其禁止在Update使用）GetComponent，FindChild，Instantiate，as等方法，考虑缓存
  • 检查页面是否有过高的drawcall和overdraw，检查图集是否合理
  • 大量的：字母，数字，帧动画 等，考虑使用一张Atlas图集
  • 考虑减少图片内存，比如图片是否可以复用，九宫格，优化图片的格式
  • 函数内大量频繁的额创建 临时变量，考虑是否可以改成全局变量
  • 警惕for和foreach的使用，尤其是ilruntime中