代码评审流程

目的

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

如何开展

1. 需求开发完成之后按照 《上线前自测清单》完成自测，直至优化清单中所有问题。
2. 以多种方式进行《Code Review》，以《上线前自测清单》《技术规范手册》内容展开检查
   • 分组或结对
     • 以项目小组展开（项目组成员）
     • 结对以至少两人为一小组展开（导师、新学员）
   • 集体
     • 每周周会集体 review 代码，每次 review 核心代码，预期每周集体 review 1-3 同学代码
     • 各自讲解自己的模块，复杂业务最好有流程图
3. 需求上线前 2-3 天 应当完成《上线前自测清单》《Code Review》 《上线前自测评分》
   1. 上线前自测清单 自主完成
   2. Code Review 集体例会或结对完成
   3. 上线前自测评分 自主完成
   4. 项目组组长、导师、团队Leader完成自测评分审核
4. 按照月度将 《上线前自测评分》表格记录 邮件发送领导及项目组负责人
5. 等待项目组及客户反馈，以及收集评审过程中的其他问题

   上线前自测清单

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

上线前自测评分

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

• 视觉还原
  • 9-10分：视觉还原一致，遵循视觉规范，尺寸，大小，空间，色彩，交互具备一致性
  • 6-8 分：视觉还原整体性尚可，存在一些尺寸间距，图片质量，色差等小问题
  • 0-5 分：完全没有按照视觉稿进行开发，视觉完全不一致
• 代码规范
  • 9-10 分：项目结构清晰，代码简洁，模块独立，组件合理，代码逻辑严谨，功能无遗漏
  • 6-8 分：模块中度耦合，代码相对简洁，无逻辑错误，功能无遗漏
  • 0-5 分：模块耦合度较高，代码逻辑错误，功能遗漏
• 可读性
  • 9-10 分：严格的代码规范，代码逻辑易理解，注释清晰
  • 6-8 分：存在阅读障碍的逻辑代码，注释模糊
  • 0-5 分：逻辑代码混乱复杂，代码书写复杂，命名不规范，理解起来极其困难困难

    上线前自评表格

    【线上地址】前端团队-上线前自测评分记录（7月份）
    https://docs.qq.com/sheet/DUVhvaU1tdmJiTGZO

相关工具

代码规范检测工具

针对于新项目统一使用 ESLint 作为代码规范检测工具，每次 git commit 会判断代码是否符合规范，只有符合规范的才能被提交。
git hooks – pre commit

视觉走查辅助工具 Visual Inspecto

Visual Inspector插件(视觉查看器插件)是一款非常优秀好用的chrome视觉查看器插件。Visual Inspector插件功能强大，简单易用，可以帮助开发者们更便捷的查看页面的字体、颜色、盒子模型、及元素间的间距标注等参数，视觉化展示，比F12工具更易观看，是视觉走查必备辅助工具之一。