如何提升团队代码质量

目标

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的情况持续增加