iOS从零开始 Code Review

http://www.cocoachina.com/ios/20151117/14208.html

这篇帖子不是通篇介绍Code Review的方法论, 而是前大段记录了我们团队怎么从没有这个习惯到每天都进行review的过程, 后小段给出了我的一些建议. 希望能对诸位的团队有所帮助.

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

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

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

• 团队成员写完需求就不管了, 没有code review意识

• 技术氛围不强

• 水平参差不齐

• 没有合适的工具

• …

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

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

第一次尝试

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

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

结论

Code Review 一个人扛N个人的代码是不可取的.

第二次尝试

结对编程可以看做是一种敏捷化的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需要达到理想的状态 - 不需要我也能自如地运转, 不然最后就会轮为政治任务.

后记

随着团队的人数增多, 集体review这种方式也会做出调整, 我们会引入一些code review的方法论和工具. 万事开头难, 既然已经开了这个头, 我相信后续的调整也不是什么难事.

建议

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

• tech leader 强压所有人开始 code review, 这是最重要的一步

• 安排一次编码规范的技术分享

• 前期经常回顾, 这次的code review开展的怎样, 有哪些地方可以改善

• 对于积极的同学表示鼓励, 支持现场重构代码

• 每天不光可以review代码, 也可以安排整场的技术分享