目标

  1. 进步代码质量
  2. 统一编码标准和风格
  3. 常识分享
  4. 防止代码腐烂
  5. 降低bug数量，提早查看出线上危险

一、接入SonarQube，

  1. SonarQube关于js部分的规则
    • rules.sonarsource.com/javascript/
  2. sonar的主要效果
    • CR大部分情况只会关注提交部分代码，所以需求一个东西能够从大局查看潜在的代码缺点，这其间SonarQube是一个不错的选择
    • sonar能够展现源码中重复严峻的当地，人肉CR很难做到，除非对这个项目代码深入了解
    • sonar能够作为辅佐CR东西，仅用于记载问题，不阻塞发布流程
    • 由于CR只针关于新增代码，所以不会照料到老代码的质量。sonar能够辅佐修正老项目代码的潜在缺点，进步老项目的代码质量
  3. 怎么运用
    • SonarQube看板
    • 定时记载sonar的问题计算信息

二、添加CR环节

CR 自身的收益

  1. 统一编码风格
  2. 添加代码标准的主动性（⼼理暗示别⼈会review，所以会留意标准）
  3. 代码复查，进步质量（尽早发现bug和规划中存在的问题）
  4. 代码分享，常识同享（例如一些好用的库或许处理方案能经过CR在组内快速广播开）
  5. 新人培育（CR流程能够作为新人培训的一部分，让新人能够敏捷接入项目）

CR 标准

  1. 一切需求发布⽣产的代码提交都要得到CR，至少需求指定一个人appove
  2. 一切的comment都需求处理之后才能够合并到master
  3. 应用能够设置 Review 主张需全部处理，关于非必需修正的主张能够进行打标或阐明
  4. MR的补白信息要详细阐明本次MR的功用点，让reviewer能容易了解作者意图
  5. reviewer不能指定自己
  6. 优先指定熟悉项目的相关人员

CR 进程

  1. 冒烟测验经过之后，提交MR到develop分支，并把MR链接发到群里并艾特reviewer，简要阐明此次提交/修正的内容（也可经过机器人
  2. 鼓舞斗胆comment，有不了解的当地，或许觉得不合适的当地都直接表达出来
  3. 作者对每个comment也要做出反馈，无论是展开讨论仍是简略的给个 OK 都是有用的反馈
  4. 杂乱的、许多的代码提交能够采用线下开会集体cr以进步功率
  5. 作者处理完一切comment，代码也进行修正之后，要在群里艾特通知一下reviewer
  6. reviewer确认没问题，点approve, 然后由作者来点merge

CR Gitlab装备

  1. webhook装备
  2. approvals设置

CR 原则

  1. 如果改变到达能够进步体系全体代码质量的程度，就能够让它们经过，即使它们可能还不完美
  2. 没有完美的代码，只需更好的代码。不要求代码完成每个细节都完美，应该做好修正时刻和重要性之间的权衡
  3. 遵从根底的代码标准指南，任何与标准不一致的当地都归于个人偏好，比方变量命名标准是驼峰，代码完成是下划线命名。但如果某项代码款式在指南中未提及，那就承受作者的款式

关于Comment

  1. 一般预期挑的越多越好，但代码是人写的，许多情况下会让作者感到不适，所以在comment的时分也尽量留意一下措辞，有一些在标准之外的偏个人主观的东西，一般以主张的方法给出
  2. 关于原则性的问题，仍是要坚守质量标准的
  3. 发现了一些好的代码好的规划，也请给予对方以肯定和赞美，这样有助于Review有用的进行

reviewer需求留意的点

  1. 逻辑上

    • 代码规划
    • 功用完成
    • 边界条件
    • 性能危险

  2. 代码质量

    • 编码标准
    • 可读性：逻辑清晰、易了解，避免运用奇淫巧技、过度拆分
    • 杂乱度：是否有重复可简化的杂乱逻辑，代码杂乱度是否过高，功用完成尽量要简练

  3. 参阅 CR常见问题

  4. 原则：代码是写给人看的，除非这份代码仅运用一次，不再需求保护。基于此原则review，只需作者提交的代码让你感觉到接手后保护困难，那都应该comment提出自己的主意

CR 心态

  1. Author
    • 自己对代码的质量负责，因而应当怀着感恩的心去看待坚持仔细帮你 Review 代码的同事，由于并不是一切人都有时刻和精力来帮着进步代码质量
    • 不要依赖于reviewer，不要说什么”review的时分你怎么没看出来”这种话，就好像出了线上bug不要怪测验没有测出来，reviewer只是提供了一些主张，不是做质量把关的
    • 对comment不要有抵触情绪，有自己觉得不合理的当地，能够恰当的回复拒绝，或许阐明一下自己这么做的原因
    • 代码好坏这件事情上自身就带有很大的个人偏好色彩在里面，每个commont都看做是一次思想交流就好了
  2. Reviewer
    • 坚持学习者的心态，review既是帮助别人进步代码质量的进程，也是学习别人，进步自己代码能力和交流能力的进程，既要发现潜在质量问题，也要尽力发现一些值得学习的亮点，这样对自己也是一个很大的帮助
    • 代码review的时分不用有什么心里负担，有什么疑问的、不清楚的当地或许有什么自己的主意，能够直接提出来。有不少人 在写Comment的时分会犹疑，担心自己提出的问题或主张比较“蠢”

CR 疑问

  1. 组员参加度和活跃性不够高，无法有用对比小A和小B和小C在CR上的奉献
    • 激励措施，鼓舞全员活跃CR
    • 定时计算comment数量，挑选好的comment，和一些坏的代码展现并讨论
  2. 关于一些重要且杂乱的功用代码是否需求定时开会宣讲，多人review
  3. 发布前发现问题多，改动太大，影响项目方案

三、CR常见问题（包括标准/风格指南）

  1. CR常见问题 文档
  2. CR常见问题仅供reviewer做参阅, 分严峻/中等/主张三个等级
    • 严峻:可能会形成bug
    • 中等:形成后续保护困难
    • 主张:代码有优化空间或许代码风格、格局问题，可是不影响运用和迭代
  3. 依据项目紧急程度和对质量的要求，不同等级的问题可酌情处理
  4. 标准要轻量，先抛出严峻问题，不过火追求细枝末节，依据后续CR的情况继续添加