RT,我觉得我们团队需要做一点 code review 的事情,希望团队成员的代码写的更好一些,算是给他们一点压力。
本身我的主职不是做 rails 开发,但是我对 rails 还是很感兴趣的,也算入门了。只是对做 rails 的 code review 还感觉信心不足,但是对于 OS X/iOS C/C++ 项目的 code review 没问题。现在的问题是团队有一些项目是 rails 的项目,其他的 rails 的成员我觉得也不足以完成 rails 的 code review 这个任务,所以想请大神支支招。
不止 rails,如果大神们还有一些其他平台的 code review 经验,也非常欢迎讨论。
谢谢!
#8 楼 @raven 我记得 teahour 的采访里讲,他们团队是互相看的,一个人的代码要另外两个人看。但是那些都是形式。
讲讲我的思路: 首先,业务逻辑的 code,需求 ticket 要拆分成技术点,每个技术点如何实现写到 issue 里,这样,写的人和分配到 issue 的人,都清楚要干什么。 然后就是按照技术点去 review 是否符合要求。这个工作很耗时但是从团队协作和质量控制上,这个时间是要投入的。 至于测试,这个可以有专人维护(如果人力够的话,我是建议专人维护的,这样可以保证测试用例的连贯和测试覆盖程度高),如果个人维护,review 先从测试开始,再看代码,方便理解如何实现的。
review 测试我更看重的是逻辑覆盖程度。当然,具体情况具体分析。
如果是 rails view 的改动,因为单元测试意义不大,view 的测试在回归测试时重点检查。
我非常看重 code review 这个环节,可以让团队更行动一致。也可以阻挡一下需求对 code 的直接影响。毕竟太多人的坏习惯是跟着需求做,最后一团乱麻。当然啦,赶工的除外。。。。赶工的东西一定要找时间重构的。
code review 包括两种,一个是高级评审,一个同行评审 高级评审是高手对菜鸟的,一般由技术经理来进行,重点是看这个工程师写的代码是否合格。 同行评审是技术人员之间的,重点是代码的交流,代码互通,风格互通。 当然评审本身的目标,找 bug、提高代码质量还是不少的
#13 楼 @ZombieCoder 我觉得,对于评审的人也是自身学习的过程,协同开发,每个人都要从别人那了解各自的思路,思路太独特,就要用业务流程和设计规范来约束下。 我认为 manager 的很重要的事情就是设计开发思路。约束开发行为。
#12 楼 @liwei78 谢谢!有一点我不太明白的是:技术点需要写到 issue 里面去?另外对于“按照技术点去 review 是否符合要求”,受教了,我一般 review 都是通过应用表现出现的功能是否符合要求,以前没太管技术点的实现情况。 @ZombieCoder 看来对于 rails 的 review 我们团队目前适合同行评审。谢谢!
一天,客户说,我们订书的系统,对于 VIP 用户,订购满 30 元免运费。快加上这个功能,我们明天用。
那么技术团队怎么应战????
首先这个需求,PM 必须拆解,比如 1,我们改动那个 model,2,我们改动那个 controller 的那个方法,增加哪个判断,3,这次改动对应的流程有调整,按照 xxx 流程图补充测试,4,我要跟客户确认:如果它买了一个冰箱,再买了 1 本书,还免运费么?
至于代码细节大家也都编程,或许都能想到了,不过像 4 里面的问题,如果在 coding 的时候才发现,再去找客户,恐怕就来不及了。还有,对于一个不了解需求的“新”人或者刚睡醒的“老”人,拿到拆分好的 issue 是很幸福的,完成快,测试人员也不会打回 issue。
要知道在华为,issue 被退回两次是要被调岗或者停职的。。。。。。
#16 楼 @liwei78 例子很直观,谢谢!issue 被退回 2 次就调岗或者停止,这叫我情何以堪呐。。。 @yedingding 谢谢!快读看了下,我想问的是介不介意我把你的这篇文章拿出来讨论一下,然后按照我们的情况适当修改一下?
#19 楼 @yedingding 听过的,很受用。是这期:http://teahour.fm/2013/10/21/talking-remote-work-with-allen-wei.html。想远程工作的话必听。
#18 楼 @liwei78 @yedingding 谢谢! @liwei78 很多时候程序员们都会有些“癖好”,这一般都是高手的习惯,他们会认为代码能正确工作并不是 100% Ok,而是让他觉得所有代码他 (他们那一类人) 看来都是 Ok 的才是真的 Ok,而他们把这些“癖好”,汇编成一些基本的规范让人们去学习,不可否认的是往往 (不一定是 100%) 他们说的是对的,对于项目来说是有利的。 @yedingding 只听过,没看过这本书。我内心认为我上面的理解就是这本书所要讲述的问题。不过有有时间我还是会读一下,来确认一下我的看法,哈哈!
#24 楼 @Blues 这种有决定意义的人很重要的,团队里非常需要这种人,有点小问题也就无所谓了。呵呵。。 #25 楼 @yedingding 我也是精神洁癖,我受不了没有流程图,没有测试的东西摆在我面前。我倾向于小而精的产品。
#26 楼 @liwei78 对啊,这个人确实关键,如果找不对这样的人,对于团队来说是个灾难啊,所以目前最好的办法就是自己成长为那样的人。流程图感觉不是那么重要,一般都是给出一个 mockup,然后大家就知道流程了,感觉 mockup 就替代了流程图了。 @yedingding 个人认为 100% 的覆盖率过于困难了,但是一个项目长久下去,其实还是在朝着 100% 的覆盖率前进,只是它是一个缓慢的过程而已。
#28 楼 @liwei78 用 Pragmatic.ly 啊,为什么需要流程图?变成 code 的话,来 RubyConf 听我们团队的 Roy 讲《Discovering Better Object Oriented Design with Tests》