文章目录


前言


Talk is cheap. Show me the code.

So, Let’s go!

一个注重技术规范和分享的团队，往往会做好Code review工作，在紧张的项目之余，为了后期的效率和技术上的提高，我们需要引入Code review。本文是第一次准备Code Review时查阅了大量相关资料，整理总结形成本文，后期的博客中会记录第一次Code review的实例,记一次CodeReview实例。希望对你有所帮助。


为什么要Code review？

  1. 提高代码整理质量，提前发现bug,不留技术债务，利于后期维护。

一个项目就像有很多窗户的房子，当有人打碎一扇窗户而没人管时，会有人打碎更多的窗户，一个项目随着时间的推移，慢慢变成了一堆垃圾，无法维护下去，只能全部重来。


  2. 提高了团队成员对他人代码的熟悉程度，对整个项目的现状也有清晰的认识，在需要接替任务，在同事基础上继续维护项目时，有助于快速进入感觉。
  3. 从成员角度看，有助于养成良好习惯，代码书写更加规范，整洁。随着习惯的养成，后期将会逐渐转化为文化与技术的交流，会对技术还是境界都有一定的提升。从团队来看，有助于形成积极的技术氛围，融洽的关系。

Code review 工作范畴


  2. 检查代码是否整洁，命名是否规范合理及语法问题。
    多一个空格，少一个空行这种格式问题，尽量通过自动化工具完成，不要浪费他人宝贵的时间，主要是检查命名是否明白易懂
  3. 检查逻辑是否正确，清晰
  4. 检查是否有可改进的地方，更高效的方法、算法。
  5. 架构是否灵活，合理。
    小结：让团队Code review前，先做好自查。比如，在Android团队开发中，先根据事先团队约定的开发规范自查。Code review前，团队得有一个Code review清单，类似这样的Android开发代码规范总结


团队成员对code review 应该有什么样的态度


  2. Code Review不是批斗会，评审者不能以错误、缺陷打击成员的积极性
  3. 作者应该以学习的态度虚心接受评审员的建议，遇到分歧可以讨论。
  4. 评审员职责是发现问题，跟踪改进，不是替作者修改。作者同意后应该按建议自行修改。
  5. 作者不要过分依赖于审核，要在提交前自己先检查，避免浪费他人的时间。
    小结：虚心使人进步，多思考别人的思考方式和不同的技术思路。

高效执行 code review 面临的挑战


  2. 上级领导不认可，认为浪费时间，团队很难执行下去，团队之间不接受批评建议也很难开展下去，团队技术氛围很重要。
  3. 时间紧任务重。先快速迭代完成任务，新功能可能随时被砍掉，不要过早优化。
  4. 团队成员没有提高自身技能与素养的意愿。需要有极客精神，对代码质量有自身要求，敢于尝试新鲜技术，希望更上一层楼。
  5. 不认同价值观
    是人的复杂让本来简单的事情变得异常复杂。如何通过成员间讨论设计出所有成员都认同的规则，形成所有人认同的价值观对事情的可持续发展至关重要。

实践方案


  2. 先确定代码规范，git使用规范，代码审核机制。
  3. 先按代码规范自查。
  4. 至少有一名经验较他人丰富的骨干成员当主审，以及不限数量的其他成员作为可选审核员。代码通过需要至少一个主审同意，所有审核员都可以对代码发表意见。
  5. 审核时机确定
    固定时间段或项目结束后进行。在项目中待优化的地方加上TODO, 有时间及时优化。
  6. 激励机制
    对code review 中积极帮助他人，分享大量知识，及时发现重大bug的成员进行奖励。

如何有效开展CodeReview活动？

也谈谈 CodeReview_代码规范

1、代码规范：明确Coding规则

如果一开始不定义好团队Coding标准，那在检视过程中就会存在两种情况：一种是各种不同的意见很难快速达成一致，影响review效率，另外一种是团队根本就不会重视代码规范的检视， 如果是前者还好，毕竟大家都还在关注什么写法是好的或对的这个问题，只要中途愿意建立起Coding规则，问题就能很快解决。而笔者跟进过的一个团队恰恰就出现了后者的情况：该团队由于前期没有明确Coding规则， 过程中大部分开发人员对规范类问题直接无视，CodeReview运作一段时间后代码中依然存在命名不规范，可读性较差等问题，直接影响了活动效果，这是我们非常不愿意看到的。

当然也有团队负责人说了，每天纠结于空格少了，行数字符多了等细节问题没意义啊，不想浪费这个时间，因此我们不需要代码规范。我个人不认同这个观点，因为代码规范并不只包括空格和字符等约束纬度，还包括了注释的要求，命名的规范，命名是否词能达意，代码结构安排等等影响代码可读性的因素， 如若这些方面连基本规则都没有，那一定会出现之前说的那两种情况（争议太多 or 完全忽视），效果可想而知。所以你可以根据自己的看法或需求做一定的规则定制，但不能没有Coding规则。

2、检视指南：消除困惑和迷茫

检视指南又名CodeReview-checklist。一个团队并不是所有人都是老司机，有很多同学是没有代码review经验的，他们往往不知道应该重点 check哪些点。

这个时候结合自身业务特点和团队之前踩过的坑，制定一个checklist是非常必要的:


  2. 什么写法可能导致性能低下？
  3. 哪个接口要慎用？
  4. 哪些设计方式需要规避？
  5. 什么习惯容易引发内存泄漏？
  6. 等等。。。

这样可以让经验不足者在不知道要review什么时，能有的放矢，过程中逐步积累起经验。

Code review 工具推荐

  • GitLab

GitLab,GitHub这些仓库托管平台如今也具有code review 功能，基本可以满足需求。


  • Gerrit
    Gerrit 是一个基于 web 的代码评审工具, 它基于 git 版本控制系统。Gerrit 旨在提供一个轻量级框架, 用于在代码入库之前对每个提交进行审阅。这是比较流行的code review 工具，是谷歌用来管理Android项目的工具。
    流程：
    （流程git review提交代码 -> 提交到Gerrit库 -> 触发Jenkins自动测试，测试通过Verified -> 人工审核Review，review通过 -> Gerrit执行Replication -> push Git remote）
  • SonarQube

代码质量管理平台，具有完善的功能，适合对代码质量要求很高的团队。

总结

Code review不是炫技，重在分享和规范代码，相信参与其中的人都有收获。当你看到此文时，相信你也走上了Code review的道路上了。

​