Code Review

目的

• 保证团队编码风格一致
  • 自己的代码要给别人看，开发过程中需要潜意识的注意代码规，以及逻辑严谨性。
• 保证项目质量，扼杀潜在风险
  • 虽然功能完成后自己会自测，但难免会遗漏掉一些边界点，或者受思维限制的一些点。
• 相互提升
  • 多学习别人代码，看高手是如何写出严谨、简洁、优美的代码，和自己做对照，取齐精髓，去其糟粕！
• 便捷交叉维护
  • 通过交叉 Code Review 过程，了解不同业务，方便后期交叉维护，无需花更多时间上手。

如何开展

• 结对
  • 至少两人为一小组
• 集体
  • 每周周会集体 review 代码，每次 review 核心代码，预期每周集体 review 三位同学代码
  • 各自讲解自己的模块，复杂业务最好有流程图
• git hooks – pre commit
  • 新项目统一使用 ESLint 作为代码规范检测工具，每次 git commit 会判断代码是否符合规范，只有符合规范的才能被提交

自测 check list

功能完成之后要进行自测，具体可以从以下方面切入：

自查细则		是否通过	未通过原因/现象
常规检查	代码是否能正常运行？
	控制台是否有明显的报错？
	代码有没有达到预期需求效果？
	代码逻辑是否简单易懂？
	代码书写是否符合规范？
	是否尽可能组件化了？
	有没有重复造轮子？
	去掉大段被注释的代码？ （如果注释代码是可用的，那就先提交未删除注释的代码到 Git 上，然后再提交删除了注释的代码，以后能回滚就可以）
	按钮是否控制了单次点击？
	定时器是否随生命周期消除？
安全检查	引入他人（公司内部或者其他外部机构）依赖包，是否存在不可用和版本升级导致功能不可用的风险？
	所有请求是否都使用了 https，包括图片链接，对 App 应用嵌入的页面，是否提供了 https 协议链接？
	代码注释或者文案中是否包含了敏感词汇？
文档检查	是否有符合规范的注释？注释是否描述准确？对方法参数或者名词是否进行了解释？
	第三方库使用是否有完善文档？
	Readme 文档是否书写规范？是否对项目有准确描述？
性能检查	页面加载是否超过了 3s？超过 3s 的原因是什么？有没有友好的提示？
	代码有没有明显影响性能的逻辑和计算？
	组件层级是否可控？
	组件通信是否正常？
	页面嵌套是否简单？

评分标准

总分 30 分，24 分以上是允许被 merge 到 master 的代码，低于 24 分需要进行优化。

• 需求
  • 9-10 分：项目结构清晰，组件合理，代码逻辑严谨，功能无遗漏
  • 6-8 分：无逻辑错误，功能无遗漏
  • 0-5 分：代码逻辑错误，功能遗漏
• 代码
  • 9-10 分：代码简洁，合理注释，模块独立
  • 6-8 分：模块中度耦合，代码相对简洁
  • 0-5 分：模块耦合度较高，代码注释不清晰，代码书写复杂，命名不规范
• 可读性
  • 9-10 分：严格的代码规范，代码逻辑易理解，注释清晰
  • 6-8 分：存在阅读障碍的逻辑代码，注释模糊
  • 0-5 分：逻辑代码混乱复杂，理解起来极其空难

（完）