背景

• 团队里的code review 最初是我发起的，但是做了两三次下来后感觉效果都不是很好，借此重新阅读了网上关于代码审查的一些观点进行整理，同时持续在后续团队中做出最佳实践

• 团队中目前主要借助于阿里巴巴的规约扫描工具以及 SonarQube 插件

常见争议

• 项目都来不及做了，还做什么代码审查

  • 在我们团队中通常是每月一次，团队成员轮流来做

  • 不审查不测试造成的损失和成本更大

• 太费时间，通常是改一些格式，注释，命名之类不痛不痒的问题

  • 技术和业务缺一不可，少了其中一个都无法做出比较好的审查。可以适当将业务和技术分开审查，对于业务不熟悉的可就着代码和设计文档一同食用

• 团队的习惯就是不做代码审查

  • 尝试和leader或项目经理将好处论一论

• 不利于团建，因为观点不同在代码审查中争吵

  • 控制一定强度的争吵未必是坏事，争论过程中得到分析，思考，权衡，归纳表达等综合能力的锻炼机会

好处

• 个人和团队提升的最佳途径之一

• 团队关系建设和扩大双方影响力的有效方式

  • 对于做的漂亮的地方要赞扬

• 识别出设计的缺陷，找到安全，性能，依赖，兼容性等测试不易发现的问题

• 设立团队质量标杆

小技巧

• 每次变更包含的代码量要小

• 团队中牛人发挥作用

• 变更的质量要超过当前代码库的平均水平

  • 建设性意见和次要意见

• 新员工代码，骨架代码的审查需要更为严格

• 及时表达肯定，委婉表达意见

  • 对代码不对人
  • 对于一些次要问题，我会标注picky,没有什么大不了的如果坚持不改，也不会说服你
  • 使用也许，可能等不确定的语气词缓和表达观点的语气
  • 间接表达否定，使用疑问。为什么要这么配
  • 放上栗子，讨论链接辅佐自己的观点
  • 先肯定，再否定，但是话锋一转

• 审查时第一遍抓主要问题，第二遍看次要问题

  • 先大致搞清楚代码机制，有大的建设性问题可以提出来
  • 大问题优先解决有层次

工具

• 代码质量检查SonarQube

  • idea配套插件 sonarlint

  • www.cnblogs.com/throwable/p…

  • 本地试着下载跑了一个起来，感觉还是比较方便的

• GitLab CI/CD

未来展望

• 接入 CI/CD完成自动化
• 未完待续