目标
- 进步代码质量
- 统一编码标准和风格
- 常识分享
- 防止代码腐烂
- 降低bug数量，提早查看出线上危险
一、接入SonarQube，
- SonarQube关于js部分的规则
- rules.sonarsource.com/javascript/
- sonar的主要效果
- CR大部分情况只会关注提交部分代码，所以需求一个东西能够从大局查看潜在的代码缺点，这其间SonarQube是一个不错的选择
- sonar能够展现源码中重复严峻的当地，人肉CR很难做到，除非对这个项目代码深入了解
- sonar能够作为辅佐CR东西，仅用于记载问题，不阻塞发布流程
- 由于CR只针关于新增代码，所以不会照料到老代码的质量。sonar能够辅佐修正老项目代码的潜在缺点，进步老项目的代码质量
- 怎么运用
- SonarQube看板
- 定时记载sonar的问题计算信息
二、添加CR环节
CR 自身的收益
- 统一编码风格
- 添加代码标准的主动性（⼼理暗示别⼈会review，所以会留意标准）
- 代码复查，进步质量（尽早发现bug和规划中存在的问题）
- 代码分享，常识同享（例如一些好用的库或许处理方案能经过CR在组内快速广播开）
- 新人培育（CR流程能够作为新人培训的一部分，让新人能够敏捷接入项目）
CR 标准
- 一切需求发布⽣产的代码提交都要得到CR，至少需求指定一个人appove
- 一切的comment都需求处理之后才能够合并到master
- 应用能够设置 Review 主张需全部处理，关于非必需修正的主张能够进行打标或阐明
- MR的补白信息要详细阐明本次MR的功用点，让reviewer能容易了解作者意图
- reviewer不能指定自己
- 优先指定熟悉项目的相关人员
CR 进程
- 冒烟测验经过之后，提交MR到develop分支，并把MR链接发到群里并艾特reviewer，简要阐明此次提交/修正的内容（也可经过机器人
- 鼓舞斗胆comment，有不了解的当地，或许觉得不合适的当地都直接表达出来
- 作者对每个comment也要做出反馈，无论是展开讨论仍是简略的给个 OK 都是有用的反馈
- 杂乱的、许多的代码提交能够采用线下开会集体cr以进步功率
- 作者处理完一切comment，代码也进行修正之后，要在群里艾特通知一下reviewer
- reviewer确认没问题，点
approve, 然后由作者来点merge
CR Gitlab装备
- webhook装备
- approvals设置
CR 原则
- 如果改变到达能够进步体系全体代码质量的程度，就能够让它们经过，即使它们可能还不完美
- 没有完美的代码，只需更好的代码。不要求代码完成每个细节都完美，应该做好修正时刻和重要性之间的权衡
- 遵从根底的代码标准指南，任何与标准不一致的当地都归于个人偏好，比方变量命名标准是驼峰，代码完成是下划线命名。但如果某项代码款式在指南中未提及，那就承受作者的款式
关于Comment
- 一般预期挑的越多越好，但代码是人写的，许多情况下会让作者感到不适，所以在comment的时分也尽量留意一下措辞，有一些在标准之外的偏个人主观的东西，一般以主张的方法给出
- 关于原则性的问题，仍是要坚守质量标准的
- 发现了一些好的代码好的规划，也请给予对方以肯定和赞美，这样有助于Review有用的进行
reviewer需求留意的点
-
逻辑上
- 代码规划
- 功用完成
- 边界条件
- 性能危险
-
代码质量
- 编码标准
- 可读性：逻辑清晰、易了解，避免运用奇淫巧技、过度拆分
- 杂乱度：是否有重复可简化的杂乱逻辑，代码杂乱度是否过高，功用完成尽量要简练
-
参阅
CR常见问题 -
原则：
代码是写给人看的，除非这份代码仅运用一次，不再需求保护。基于此原则review，只需作者提交的代码让你感觉到接手后保护困难，那都应该comment提出自己的主意
CR 心态
- Author
- 自己对代码的质量负责，因而应当怀着感恩的心去看待坚持仔细帮你 Review 代码的同事，由于并不是一切人都有时刻和精力来帮着进步代码质量
- 不要依赖于reviewer，不要说什么”review的时分你怎么没看出来”这种话，就好像出了线上bug不要怪测验没有测出来，reviewer只是提供了一些主张，不是做质量把关的
- 对comment不要有抵触情绪，有自己觉得不合理的当地，能够恰当的回复拒绝，或许阐明一下自己这么做的原因
- 代码好坏这件事情上自身就带有很大的个人偏好色彩在里面，每个commont都看做是一次思想交流就好了
- Reviewer
- 坚持学习者的心态，review既是帮助别人进步代码质量的进程，也是学习别人，进步自己代码能力和交流能力的进程，既要发现潜在质量问题，也要尽力发现一些值得学习的亮点，这样对自己也是一个很大的帮助
- 代码review的时分不用有什么心里负担，有什么疑问的、不清楚的当地或许有什么自己的主意，能够直接提出来。有不少人 在写Comment的时分会犹疑，担心自己提出的问题或主张比较“蠢”
CR 疑问
- 组员参加度和活跃性不够高，无法有用对比小A和小B和小C在CR上的奉献
- 激励措施，鼓舞全员活跃CR
- 定时计算comment数量，挑选好的comment，和一些坏的代码展现并讨论
- 关于一些重要且杂乱的功用代码是否需求定时开会宣讲，多人review
- 发布前发现问题多，改动太大，影响项目方案
三、CR常见问题（包括标准/风格指南）
- CR常见问题 文档
- CR常见问题仅供reviewer做参阅, 分严峻/中等/主张三个等级
- 严峻:可能会形成bug
- 中等:形成后续保护困难
- 主张:代码有优化空间或许代码风格、格局问题，可是不影响运用和迭代
- 依据项目紧急程度和对质量的要求，不同等级的问题可酌情处理
- 标准要轻量，先抛出严峻问题，不过火追求细枝末节，依据后续CR的情况继续添加
