https://blog.csdn.net/uxyheaven/article/details/49773619

最初来到这个新组建的团队是木有code review的. 头说, 这个月你来搞吧.

当我第一次知道必须得搞review的时候, 其实我是拒绝的! 因为我觉得…呀…你不能叫我马上搞立马搞, 第一, 我要试一下, 我又不想说…团队之前就没有这个习惯. 我搞了以后, 那个耽误每天的工作时间啊. 结果同事一定会骂我, 给他们增加额外的工作量. 我说先让我尝试尝试. 现在呢…每天都在review!每天都在review呢…我还推广到了其他团队!来!来!来!大家试试看!

觉得困难, 开展不起来, 想拒绝的原因有很多:

• 团队成员写完需求就不管了, 没有code review意识
• 技术氛围不强
• 水平参差不齐
• 没有合适的工具
• …

但是总的来说就是一条, 木有code review. 如果已经有了, 无论是真的在搞, 还是形式主义, 主持一下都是不难的.

从零到一, 从无到有总是困难的, 咱开始了若干次尝试之路:

第一次尝试

最初的版本是其他团队的写的, 到我们团队接手的时候, 啥都木有. 什么逗号等号左右不空格, 类名首字母小写, 方法名首字母大写; 依赖乱七八糟; 在view里写业务, 在view里发网络请求. 看到这样的代码我当时心里是崩溃的.

我先尝试一个人帮整个团队review. 零散看了几天, 问题代码贴了几十张ppt, 槽点太多, 看起来很感人. 后来自己放弃了.

结论

Code Review 一个人看所有人的代码是不可取的.

第二次尝试

结对编程可以看做是一种敏捷化的Code Review. 直接结对会被头劈死. 于是我想着采用新的结对编程方式.

两位程序员新成结对小组, 每人一台电脑, 坐在临近的工位上, 两人合作完成一组功能(可以是两个或多个独立的模块)的设计, 代码实现. 但对已某一个模块来说设计和代码是分开的, 一个人负责设计, 另一个人负责写代码, 对于其他模块则反之.

当我在团队里寻找可以结对的伙伴的时候, 发现木有可以设计模块, 项目进度又差不多, 可以结对的小伙伴.

结论

Code Review的模式需要接地气.

第三次尝试

第三次尝试, 我想用一个游戏的方法去开展review

• 每次的review主持轮流当, 由大伙推举当前找得bug最少的同学来主持.
• 每轮开始的时候,先贴出代码来, 由下面的同学说问题.(大伙这个时候关注下哪位同学次次都木有发现问题)
• 最后由主持的同学将所有的问题列出来.
• 进入下一轮
• 如果经常是下面的同学说的比主持人多,主持人第二天继续.
• 主持的同学,每日最少准备6张问题ppt断.
• 指出的问题由主持人来指定一个修改的同学修改.
• 第二天的主持人负责把当天得bug录入jira, 并且负责跟踪这些修复.

太理想化了, 根本开展不起来.

结论

不要自己觉得好就是好, Code Review是团队的事情, 方案定了得拿出去溜溜.

第四次尝试

无奈之下, 我去请教我的头, 如何去开这个头. 头就给了两个字: 强压.

于是小伙伴们便在我的淫威之下开展了第一次的code review. 我用的是之前第一次整理出的ppt. 效果竟然好的意外. 小伙伴们互相吐槽被我指出来的渣渣代码, 气氛很是欢乐.

不过关键问题还是没有一个统一的标准去改. 于是咱紧接着就安排了一场代码规范的分享. 再接下来的一次review, 大货吐槽的点就相对集中了.

结论

Code Review初期需要有标准. 让小伙伴们知道如何去review.

第五次尝试

由于之前的氛围很好, 有小伙伴A提议拿出他负责的模块来集体review. 有主动的, 当然不能拒绝. 后面几天安排的都是review他的模块了. 顺带还做了一次他的模块的设计分享.

在有天的review中, 有个小伙伴B表示这样现场重构不是他擅长的. 我们: 那你擅长啥? 小伙伴B: 我擅长xxx. 我: 那下周你来给大货分享下吧. 小伙伴B: 好, 我准备一下.

结果小伙伴B深藏不漏, 连续分享了一整个系列.

结论

闻道有先后, 术业有专攻, 不要低估你的小伙伴们. 给他们展示自己的机会.

第六次尝试

我被挂的任务是code review, 所以偶尔还是会看看小伙伴们代码的. 有天突然发现有个小伙伴C, 在重构优化代码了. 咱顺势和他说了一些编程方面的思想和技巧, 告诉他还可以这么重构, 用查表发代替条件语句, 用多态代替提条件语句, 用runtime生成方法名, 用runtime 执行方法. 于是他也出来一个技术分享. 可惜的是关于编程思想的分享讨论起来就木有那么激烈了, 这个只能慢慢来了. 不过当咱吃完饭快8点回到公司的时候, 发现有两个小伙伴DE在写demo, 在讨论之前C的技术分享.

结论

不能急于求成, 一股脑的灌; 编程的思想需要慢慢悟, .

第七次尝试

有次review, 我有事提前走了. 但是呢, 本是半个小时分享大伙觉得还不尽兴, 又延长了二十分钟. 之前有几场分享, 也都不是我主持的. 后续的review我将尝试进一步淡化我的主持. 让我们的review可以自组织的进行下去.

结论

Code Review需要达到理想的状态 - 不需要我也能自如地运转, 不然最后就会轮为政治任务.

第八次尝试

到了第八次尝试,基本已经定型. 感谢公司提供gitlab代码托管平台. 我们再第一时间将团队多个项目迁移到了新平台上去, 然后开发流程改成了gitflow, 当一个功能开发完成后, 会发起Merge Request, 大伙在这个时候便可以开始code review了,互相吐槽的言语和片段也都被记录了下来, 当收集齐了两个赞的代码, 才允许合并进来. 整个过程感觉良好.

结论

Code Review需要有工具, 需要有不reivew不让合并的规矩.

建议

如何做出从零开始code review呢, 我的建议是:

• tech leader 强压所有人开始 code review, 这是最重要的一步
• 安排一次编码规范的技术分享
• 前期经常回顾, 这次的code review开展的怎样, 有哪些地方可以改善
• 对于积极的同学表示鼓励, 支持现场重构代码
• 每天不光可以review代码, 也可以安排整场的技术分享