其实在写这篇文章之前, 对 code review 已经有了基本的了解, 不过没有深入下去, 一方面懒, 一方面也是想到领导层可能并不重视, 没有实践的余地最近开会, 领导首次提出了要进行 code review 的要求, 趁此机会深入研究一下, 这也是本文由来本文概述了 code review 实施需要考量的问题, 并未涉及技术上的细节, 静待后期更新技术方面不说废话了, 马上开始
本文内容分 7 个部分:
1 code review 概念
2 为什么要 code review
3 code review 工作范畴
4 团队成员对 code review 应该有什么样的态度
5 高效执行 code review 面临的挑战
6 实践方案
7 code review 工具推荐
第一部分: code review 概念
Code Review 是指在软件开发过程中, 对源代码进行检查, 提前发现 bug, 提高软件质量的同时提高开发人员自身水平, 与正式的代码审核相比, Code Review 是一种轻量级的代码评审, 投入低, 若能有效持续的执行, 会对项目与成员起到积极的效果
PS:Code Review 虽然浪费时间, 但是从长远角度看还是值得的毕竟一开始就写好, 比以后花大量时间维护与重写划算, 除非负责人没打算长时间维护它, 只是一次性短期的
第二部分: 为什么要 code review
1. 能提高代码的整体质量, 提前发现 bug, 换句话说决定了代码的一个质量基准 (benchmark), 木桶效应中的那块最短板有多高
ps: 一个项目就像有很多窗户的房子, 当有人打碎一扇窗户而没人管时, 会有人打碎更多的窗户, 一个项目随着时间的推移, 慢慢变成了一堆垃圾, 无法维护下去, 只能全部重来
2. 提高了团队成员对他人代码的熟悉程度, 对整个项目的现状也有清晰的认识, 在需要接替任务, 在同事基础上继续维护项目时, 有助于快速进入感觉
3. 从成员角度看, 有助于养成良好习惯, 代码书写更加规范, 整洁随着习惯的养成, 后期将会逐渐转化为文化与技术的交流, 会对技术还是境界都有一定的提升从团队来看, 有助于形成积极的技术氛围, 融洽的关系
第三部分: code review 工作范畴
1 检查代码是否整洁, 命名是否规范合理及语法问题
ps: 多一个空格, 少一个空行这种格式问题, 尽量通过自动化工具完成, 不要浪费他人宝贵的时间, 主要是检查命名是否明白易懂
2 检查逻辑是否正确, 清晰
3 检查是否有可改进的地方, 更高效的方法算法
4 架构是否灵活, 合理
注意: code review 需要时间, 精力, 不要将人力资源大量浪费在基本的格式检查上, 应使用自动化工具 code review 应注重知识的分享, 以及自动工具检测不到的问题上, 让彼此成长
第四部分: 团队成员对 code review 应该有什么样的态度
1 Code Review 不是批斗会, 评审者不能以错误缺陷打击成员的积极性
2 作者应该以学习的态度虚心接受评审员的建议, 遇到分歧可以讨论
3 评审员职责是发现问题, 跟踪改进, 不是替作者修改作者同意后应该按建议自行修改
4 作者不要过分依赖于审核, 要在提交前自己先检查, 避免浪费他人的时间
第 5 部分: 高效执行 code review 面临的挑战
许多事情其实并不复杂, 是人的复杂性让原本的简单变得异常复杂! Code Review 虽好, 但是并非适合所有团队, 而且执行中也会遇到诸多挑战, 若是做的不好, 甚至会有反效果
下面列举一些执行中会遇到的挑战, 可以评估自己的团队是否适合进行 code review:
1 领导不认可, 觉得没必要在这种事情上浪费时间
此时团队成员是坚持不下去的, 毕竟 codereview 需要时间去做, 另外需要同事之间互相指出错误, 对方不接受的你观点, 你完全没办法当 codereview 变成一件吃力不讨好的事, 没有人愿意坚持
2 团队的首要任务是快速迭代, 前期的混乱可以忍受, 没时间审核
这类情况也不适合 codereview 确实有些公司的功能更新太快, 而且新的功能随时可能被砍掉, 过早的优化都是无意义的
3 成员刚开始会很难适应, 只写了一点, 结果给了十来个意见, 肯定会很受挫, 刚开始, 提交一次, 需要进行多次修改才能通过
4 提交后审核人员一直没有进行审核, 或者是提交了意见, 作者一直没修改, 这会严重阻碍进度, 这个问题可以通过合理的制度与规划避免, 不是致命的
5 团队成员没有提高自身技能与素养的意愿
当然大部分人还是很积极的, 具有极客精神, 希望更上一层楼但是只想维持现状的人也非常多对于倾向于维持现状的人, 他们只是想按时完成老板的任务, 其他的东西很难引起兴趣, 也没有动力坚持下去这对 codereview 的持续也是毁灭性打击, 因为 codereview 主要是主官意愿, 没有强制要求 (成员懒得动或消极应付, 你没辙, 你没权扣他工资, 更没权开了他, 此时整个活动只能作罢, 这种人有一个就足够了)
6 团队中有部分成员水准太低, 而有些知识素养是没办法速成的, 强制 code review 那就是拔苗助长, 适得其反
举个例子, 曾经遇到一个情况, 成员中有人英语不太好, 代码中大量使用汉语拼音, 更让人纳闷的是他不会也懒得上网查一下, 汉语拼音当变量名, 方法名, 可以说不能更 low 了这种情况也是非常困难的, 你能一下提高他的英语水平吗?(显然不能, 学校学了多少年都这样, 开个玩笑, 你等他学好了, 项目可能已经没了) 对于这种情况, 只能怪招聘的时候把关不够当然人事有自己的考量, 比如预算控制, 这也不是团队成员能够控制的
7 团队中有不少是佛系成员, codere view 时得过且过
比如 codereview 由团队中两个骨干负责, 需要经过两个人的共同认可才行, 但是其中一个骨干成员是佛系成员 (别人怎么做, 他都行, 无所谓), 这时另一位骨干提出意见就会有问题, 因为别的成员会认为你这人是不是故意找茬, 凑合一下不行? 另一个审核员都过了, 就你有意见?
身边大量存在佛系成员, 这对 code review 是致命的因为这样不仅不能有效与持续的执行下去, 而且会导致团队成员间不和更要命的是, 所有老板希望员工和睦一团, 最好安静地把事情搞好, 你老是提出意见, 老与同事撕, 老板会觉得你这人是不是人品不行? 就你不合群? 你的负责, 换来的是批评甚至离职
所以最后大家都妥协了, 默默的把所有问题都留着, 大家相安无事, 直到项目黄了, 或者老板认真解决一下, 然后继续恶性循环 (听着是不是有点像古代的每个王朝, 大臣们都知道为什么衰落, 就是不说而已, 颓势不可阻挡, 有那么几个忠臣说了, 结果死的很惨, 比干剖心, 岳飞缢首)
总结: 还是那句话, 是人的复杂让本来简单的事情变得异常复杂如何通过成员间讨论设计出所有成员都认同的规则, 形成所有人认同的价值观对事情的可持续发展至关重要
不得不说前人还是当代都有不少借鉴的案例, 比如抗战时期我党在军队中成立的政委制度, 比如阿里巴巴网上传说的招聘闻味官, 做的事情都是要将成员的精神凝聚在一起, 或者提前将不具有相同价值观的人排除 github 开源社区如何选择项目维护成员, 让项目良性可持续发展
第六部分: 实践方案
1 通过成员间讨论, 确定所有人认可的代码规范, git 使用规范, 代码审核原则
2 确定审核人员, 方式很多, 下面列举几种:
2.1 至少有一名经验较他人丰富的骨干成员当主审, 以及不限数量的其他成员作为可选审核员代码通过需要至少一个主审同意, 所有审核员都可以对代码发表意见
2.2 直接由技术 leader 或小组 leader 审核
2.3 结对编程, 团队中每两个人组成一队互相审核, 每天就是互怼一段时间后交换伙伴知乎上看到, thoughtworks 采用结对模式, 一个人写一个看你写一个叫做导航者, 一个叫做司机随时发问, 你这个地方写的不好, 应该怎么样不过这样感觉很耗人力的, 两人变成一人了
ps: 个人比较倾向于第一种方法
3 确定审核时机
提交后需要及时审核, 否则会耽误作者时间但是审核员也有其他事情, 不能随时马上执行
提交的代码量不要太大, 不要堆积几天甚至一周的代码, 这对审核员来说工作量太大, 而且一次修改很多问题也让人很受挫折
个人认为比较好的解决办法是每天集中在一个时间段审核, 比如下午 5 点开始, 成员需要在 5 点之前提交一天的代码, 然后由其他成员开始审核, 讨论, 并修改
当然在若有急需的审核, 也可马上进行, 规矩并非一成不变
4 激励机制
对 code review 中积极帮助他人, 分享大量知识, 及时发现重大 bug 的成员进行奖励
奖励方式很多, 包括但不限下面这些:
1 现金奖励
2 休假奖励
3 提升项目管理权限
等等
第七部分: code review 工具推荐
GitLab
GitLab,GitHub 这些仓库托管平台如今也具有 code review 功能, 基本可以满足需求
Gerrit
比较流行的 code review 工具, 是谷歌用来管理 Android 项目的工具
SonarQube
代码质量管理平台, 具有完善的功能, 适合对代码质量要求很高的团队
来源: http://www.jianshu.com/p/2d7768b967b7