首页 > 技术管理, 流程方法 > 从Code Review 谈如何做技术

从Code Review 谈如何做技术

2014年4月12日 发表评论 阅读评论 70,403 人阅读    

(这篇文章缘由我的微博,我想多说一些,有些杂乱,想到哪写到哪)

这两天,在微博上表达了一下Code Review的重要性。因为翻看了阿里内部的Review Board上的记录,从上面发现Code Review做得好的是一些比较偏技术的团队,而偏业务的技术团队基本上没有看到Code Review的记录。当然,这并不能说没有记录他们就没有做Code Review,于是,我就问了一下以前在业务团队做过的同事有没有Code Review,他告诉我不但没有Code Review,而且他认为Code Review没用,因为:

1)工期压得太紧,时间连coding都不够,以上线为目的,

2)需求老变,代码的生命周期太短。所以,写好的代码没有任何意义,烂就烂吧,反正与绩效无关。

我心里非常不认同这样的观点,我觉得我是程序员,我是工程师,就像医生一样,不是把病人医好就好了,还要对病人的长期健康负责。对于常见病,要很快地医好病人很简单,下猛药,大量使用抗生素,好得飞快。但大家都知道,这明显是“饮鸩止渴”、“竭泽而渔”的做法。医生需要有责任心和医德,我也觉得程序员工程师也要有相应的责任心和相应的修养。东西交给我我必需要负责,我觉得这种负责和修养不是”做出来“就了事了,而是要到“做漂亮”这个级别,这就是“山寨”和“工业”的差别。而只以“做出来”为目的标准,我只能以为,这样的做法只不过是“按部就班”的堆砌代码罢了,和劳动密集型的“装配生产线”和“砌砖头”没有什么差别,在这种环境里呆着还不如离开。

老实说,因为去年我在业务团队的时候,我的团队也没有做Code Review,原因是多样的。其中一个重要原因是,我刚来阿里,所以,需要做的是在适应阿里的文化,任何公司都有自己的风格和特点,任何公司的做法都有他的理由和成因,对于我这样的一个初来者,首要的是要适应和观察,不要对团队做太多的改动,跟从、理解和信任是融入的关键。(注:在建北京团队和不要专职的测试人员上我都受到了一些阻力),所以跟着团队走没有玩Code Review。干了一年后,觉得我妥协了很多我以前所坚持的东西,觉得自己的标准在降低,想一想后背拔凉拔凉的,所以我决定坚持,而且还要坚持高标准。

对于Code Review很重要的这个观点,在微博上抛出来后,被一些阿里的工程师,架构师/专家,甚至资深架构师批评,我在和他们回复和讨论的过程中,居然发现有个“因为对方用户的设置”我无法回复了(我被拉黑了,还有一些直接就是冷讽和骂人了,微博中我就直接删除了)。这些批评我的阿里工程师/架构师的观点总结一下如下:(顺便说一下,阿里内还是有很多团队坚持做Code Review的

1)到业务团队体会一下,倒逼工期的项目有多少?订好交付日期后再要求提前1个月的有多少?现在是做到已经不容易,更不谈做得漂亮!。

2)Code Review是一种教条,意义不大,有测试,只要不出错,就可以了。

3)目标都是改进质量,有限的投入总希望能有最大的产出,不同沉湎改进质量的方式不一样,业务应用开发忙的跟狗一样,而且业务逻辑变化快,通用性差,codereviw的成本要比底层高。

4)现在的主要矛盾是倒排出来的工期和不靠谱的程序员之间的矛盾,我认为cr不是解决这个问题的银弹。不从实际情况出发光打正义的嘴炮实在太过于自慰了 。

我们可以看到,上面观点其实和Code Review没有太多关系,其实是在抱怨另外的问题。这些观点其实是技术团队和业务团队的矛盾,但不知道为什么强加给了我的“Code Review很重要”的这个观点,然后这些观点反过来冲击“Code Reivew”,并说“Code Review无用”。这种讨论问题的方式在很常见,你说A,我说B,本来A、B是两件事,但就是要混为一谈,然后似是而非的用B来证明你的A观点是错的。(也许,这些工程师/架构师心存怨气,需要一个发泄的通道)

我觉得,很多时候,人思考问题思考不清楚,很大一部分原因是因为把很多问题混为一谈,连我自己有些时候都会这样。引以为戒。

即然被混为一谈,那我就来拆分一下,也是下面这三个问题:

  • Code Review有没有用的问题。
  • Code Review做不起来的问题。
  • 业务变化快,速度快的问题,技术疲于跟命。

Code Review

你Google一下Code Reivew这个关键词,你就会发现Code Review的好处基本上是不存在争议的,有很多很多的文章和博文都在说Code Review的重要性,怎么做会更好,而且很多公司在面试过程中会加入“Code Review”的问题。打开Wikipedia的词条你会看到这样的描述——

卡珀斯·琼斯(Capers Jones)分析了超过12,000个软件开发项目,其中使用正式代码审查的项目,发现潜在缺陷率约在60-65%之间,若是非正式的代码审查,发现潜在缺陷率不到50%。大部份的测试,发现的潜在缺陷率会在30%左右。

对于一些关键的软件(例如安全关键系统的嵌入式软件),一般的代码审查速度约是一小时150行程序码,一小时审查数百行程序码的审查速度太快,可能无法找到程序中的问题。代码审查一般可以找到及移除约65%的错误,最高可以到85%。

也有研究针对代码审查找到的缺陷类型进行分析。代码审查找到的缺陷中,有75%是和计算机安全隐患有关。对于产品生命周期很长的软件公司而言,代码审查是很有效的工具。

Code Review的好处我觉得不用多说了,主要是让你的代码可以更好的组织起来,有更易读,有更高的维护性,同时可以达到知识共享,找到bug只是其中的副产品。这个东西已经不新鲜了,你上网可以找到很多文章,我就不多说了。就像你写程序要判断错误一样,Code Review也是最基本的常识性的东西。

我从2002年开始就浸泡在严格的Code Review中,我的个人成长和Code Review有很大的关系,如果我的成长过程中没有经历过Code Review这个事,我完全不敢想像。

我个人认为代码有这几种级别:1)可编译,2)可运行,3)可测试,4)可读,5)可维护,6)可重用。通过自动化测试的代码只能达到第3)级,而通过Code Review的代码少会在第4)级甚至更高。关于Code Review,你可以参看本站的《Code Review中的几个提示

可见,Code Review直接关系到了你的工程能力!

Code Review 的问题

有下面几个情况会让你的Code Review没有效果。

首当其冲的是——“人员能力不足”,我经历过这样的情况,Code Review的过程中,大家大眼瞪小眼,没有什么好的想法,不知道什么是好的代码,什么是不好的代码。导致Code Review大多数都在代码风格上。今天,我告诉你,代码风格这种事,是每个程序员自查的事情,不应该浪费大家的时间。对此,我有两个建议:1)你团队的人招错了,该换血了。2)让你团队的人花时候阅读一下《代码大全》这本书(当然,还要读很多基础知识的书)。

次当其冲的是——“结果更重要”,也就是说,做出来更重要,做漂亮不重要。因为我的KPI和年终奖based on how many works I’ve done!而不是How perfect they are ! 这让我想到那些天天在用Spring MVC 做CRUD网页的工程师,我承认,他们很熟练。大量的重复劳动。其实,仔细想一下好多东西是可以框架化,模板化,或是自动生成的。所以,为了堆出这么多网页就停地去堆,做的东西是很多,但是没有任何成长。急功近利,也许,你做得多,拿到了不错的年终奖,但是你失去的也多,失去了成为一个卓越工程师的机会。你本来可以让你的月薪在1-2年后翻1-2倍的,但一年后你只拿到了为数不多的年终奖。

然后是——“人员的态度问题”,一方面就是懒,不想精益求精,只要干完活交差了事。对此,你更要大力开展Code Review了,让这种人写出来的代码曝光在更多人面前,让他为质量不好的代码蒙羞。另一方面,有人会觉得那是别人的模块,我不懂,也没时间 去懂,不懂他的业务怎么做Code Review? 我只想说,如果你的团队里这样的“各个自扫门前雪”的事越多,那么这个团队也就越没主动性,没有主动性也就越不可能是个好团队,做的东西也不可能好。而对于个人来说,也就越不可能有成长。

接下来是——“需求变化的问题”,有人认识,需求变得快,代码的生存周期比较短,不需要好的代码,反正过两天这些代码就会被废弃了。如果是一次性的东西,的确质量不需要太高,反正用了就扔。但是,我觉得多多少少要Review一下这个一次性的烂代码不会影响那些长期在用的代码吧,如果你的项目全部都是临时代码,那么你团队是不是也是一个临时团队?关于如果应对需求变化,你可以看看本站的《需求变化与IoC》《Unix的设计思想来应对多变的需求》的文章 ,从这些文章中,我相信你可以看到对于需求变化的代码质量需要的更高。

最后是——“时间不够问题”,如果是业务逼得紧,让你疲于奔命,那么这不是Code Review好不好问题,这是需求管理和项目管理的问题以及别的非技术的问题。下面我会说。

不管怎么样,上述Code Review的问题不应该成为“Code Review无意义”的理由或借口,这就好像“因噎废食”一样。干什么事都会有困难和问题的,有的人就这样退缩了,但有的人看得到利大于弊,还是去坚持,人与人的不同正在这个地方。这就是为什么运动会受伤,但还是会人去运动,而有人因为怕受伤就退缩了一样。

被业务逼得太紧

被业务逼得太紧,需求乱变,这其实和Code Review没有多大关系了。对此,我想先讲一个我的故事。

我去年在阿里的聚石塔,刚去的时候,聚石塔正在做一个很大的重构——对架构的大调整。因此压了很多业务需求,等这个项目花了2-3个月做完了后,一下子涌入了30-50个需求,还规定一个月完成,搞得团队疲于奔命。在累了两周后,我仔细分析了一下这些需求,发现很多需求是在重复做阿里云已经做过的东西,还有一些需求是因为聚石塔这个平台不规范没有标准所产生的问题。于是,我做了这么三件事:

1)重新定义聚石塔这个产品主要目标和范围,确定哪些该做,哪些不该做。

2)为聚石塔制定标准 ,让阿里云的API都长得基本一样,并制订云资源的接入标准。

3)推动重构阿里云的Portal系统,不再实现阿里云已经做过的东西,与阿里云紧密结合。

这些事情推动起来并不容易,聚石塔的业务方一开始也不理解,我和产品一起做业务方的工作,而阿里云也被我逼得很惨(在这里一并感谢,尤其阿里云的同学,老实说,和阿里云跨团队合作中是我这么多年来感觉最好的一次,相当赞)。通过这个事,聚石塔需求一下就有质的下降了。搞得还有几个工程师来和我说,你这么搞,聚石塔就没事可干了。姑且不说工程师对聚石塔的理解是怎么样的。 我只想说,我大量地减少了需求,尽最大可能联合了该联合的人,而不是自己闭门造车,并让产品的目标和方向更明确了。做了这些事情后,大家不但不用加班,而且还有时间充电去学技术,并为聚石塔思考未来的方向和发展。去年公司996的时候,我的团队还在965(搞得跟异教徒似的),而且还有很多时间去专研新的东西。

说这个故事,我不是为了得瑟,而是因为有些人在微博上抨击我是一个道貌岸然的只会谈概念讲道理的装逼犯。所以,我告诉大家我在聚石塔是怎么做的,我公开写在这里,你也可以向相关的同学去求证我说的是不是真的。也向你证明,我可能是个装逼犯,但绝不是只会谈概念讲道理的装逼犯。

被业务方逼得紧不要抱怨,你没有时间被逼得像牲口一样工作,这个时候,你需要的是暂停一下想一想,为什么会像牲口一样?而这正是让你变得聪明的机会。

我为你总结一下,

1)你有没有去Review业务部门给你的这么多的需求,哪些是合理的,哪些是不合理的。在Amazon,开发工程师都会被教育拿到需求后一定要问——“为什么要做?业务影响度有多大?有多少用户受益?”,回答不清这个问题,没有数据的支持,就不做。所以,产品经理要做很多数据挖拙和用户调研的工作,而不是拍拍脑袋,听极少数的用户抱怨就要开需求了。

2)产品经理也要管理和教育的。你要告诉你的产品经理:“你是一个好的产品经理,因为你不但对用户把握得很好,也会对软件工艺把握得很好。你不但会开出外在的功能性需求,也同样会开出内在的让软件系统更完善的非功能性需求。你不是在迁就用户,而是引导用户。你不会无限制地加功能,而是把握产品灵魂控制并简化功能。你会为自己要做的和不做东西的感到同样的自豪。”你要告诉你的产品经理:“做一个半成品不如做好半年产品”(更多这样的观点请参看《Rework摘录和感想》)

3)做事情是要讲效率的。Amazon里喜欢使用一种叫T-Shirt Size Estimation的评估方法来优先做投入小产出大的“Happy Case”。关于什么是效率,什么是T-Shirt Size Estimation,你可以看看《加班与效率》一文 。

4)需求总是会变化的,不要抱怨需求变化太快。你应该抱怨的是为什么我们没有把握好方向?老变?这个事就像踢足球一样,你要去的地方是球将要去的地方,而不是球现在的地方。你要知道球要去哪里,你就知道球之前是怎么动的,找到了运动轨迹后,你才知道球要去像何方。如果你都不知道球要去向何方,那你就是一只无头苍蝇一样,东一下西一下。

当你忙得跟牲口一样,你应该停下来,问一下自己,自己成为牲口的原因,是不是就是因为自己做事时候像就牲口一样思考?

其它

最后,我在给阿里今年新入职的毕业生的“技塑人生”的分享中,我给他们布置了5、6个Homework,分享几个给大家:

1)重构或写一个模块,把他做成真正的Elegant级别。

2)与大家分享一篇或几篇技术文章 ,并收获10-30个赞。

3)降低现有至少20%的重复工作或维护工作

4)拒绝或简化一个需求(需要项目中所有的Stakeholders都同意)

部署这些作业的原因,是我希望新入行的同学们对自己的工作坚持高的标准,我知道你们会因为骨感的现实而妥协,但是我希望你们就算在现实中妥协了也要在内心中坚持尽可能高的标准,不要习惯成自然,最后被社会这个大染缸给潜移默化了。因为你至少要对自己负责。对自己负责就是,用脚投票,如果妥协得受不了了就离开吧

芝兰生于空谷,不以无人而不芳!君子修身养道,不以穷困而改志!

谢谢听我唠叨。

(全文完)


欢迎关注CoolShell微信公众账号

(转载本站文章请注明作者和出处 酷 壳 – CoolShell.cn ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
好烂啊有点差凑合看看还不错很精彩 (115 人打了分,平均分: 4.84 )
Loading...
  1. 2014年7月22日19:05 | #1

    其实我觉得Code review真的还是有必要的,作为一个健壮的系统,以前的项目就是因为没有Code review,真的看着有些代码想吐

  2. enjolras
    2014年7月23日09:37 | #2

    再读了一遍,很有收获。
    不管大环境如何,得对自己负责。

  3. beitiandijun
    2014年7月31日09:09 | #3

    code review,痛并快乐着

  4. 2014年8月8日14:17 | #4

    很赞同,就我个人经验而言, 没有做好code review的项目 后期查bug时将花费相当大的时间,同时给人一种软件及其不稳定,说不定啥时候就有挂了的感觉。。。而做好了code review的项目,后期查bug都是很轻松的,同时,每解决一个bug就有一种软件变得更稳定的感觉。。。所以,还是做好code review吧。。。 希望刚入行的同学们,严要求自己。几年后,你会发现你受益很多的。。。

  5. listener
    2014年8月13日11:52 | #5

    无法表述,只能十万个支持

  6. 12
    2014年9月15日17:25 | #6

    code review 这个跟公司对他的认识和重视程度有莫大的关系,只是很多决策不懂不管不问而已

  7. 魔鬼肌肉人
    2014年9月22日17:22 | #7

    耗子哥 确实写的好。其实表达也是一门艺术,能正确表达自己的想法,并且让别人能够正确的理解 是如此的重要,交流和写代码都是如此。
    吾尝终日而思矣,不如须臾之所学。

  8. 复醉
    2014年11月9日20:03 | #8

    不能赞的更多了

  9. 2014年11月17日22:02 | #9

    很赞同,看到同事们写的一坨坨代码就觉得烦,就会控制不住跟他说,可是怕说多了他烦你。

  10. jsxgblcxp
    2014年11月27日11:34 | #10

    博主,”还要读很多基础知识的书“ 能给个列表和读书推荐顺序不?

  11. lua
    2014年12月26日19:59 | #11

    非常赞同您的观点,本人也很欣赏有追求的程序员。
    程序设计到一定高度,其实是一种艺术美感的享受,就像一幅完美的画和建筑一样。

    我觉得在中国,正是因为很多程序员过于浮躁很功利,所以到现在少有大师级的人物(比如说云风)出现。

  12. pk
    2015年1月29日15:33 | #12

    “对此,我有两个建议:1)你团队的人招错了,该换血了。2)让你团队的人花时候阅读一下《代码大全》这本书(当然,还要读很多基础知识的书)。”

    这里说的基础知识的书,可以列举一些吗?

    谢谢!

  13. 仙乐
    2015年3月11日09:17 | #13

    “为什么要做?业务影响度有多大?有多少用户受益?”其实有些很耗费工时的工作,是不是一开始的方向就错了呢,业务的真正目的是什么。

  14. daidai
    2015年3月30日13:47 | #14

    感同身受

  15. 大口丁
    2015年4月2日13:11 | #15

    “我希望新入行的同学们对自己的工作坚持高的标准,我知道你们会因为骨感的现实而妥协,但是我希望你们就算在现实中妥协了也要在内心中坚持尽可能高的标准,不要习惯成自然,最后被社会这个大染缸给潜移默化了。”

    去年毕业开始在阿里的业务线做iOS开发,来这边之后,发现在业务需求的压迫下大家写代码的节操真的是碎一地,更别说code review了。一直努力坚持把自己的代码写得比较elegant,努力抽时间学新知识,但是苦于没有人可以交流、没有人带路或同行,感觉自己成长比较慢,小p影响力也小,想改变环境基本不可能。挺压抑。

  16. 1+1=?
    2015年4月7日09:38 | #16

    说的挺好的。

  17. shonary
    2015年5月27日17:45 | #17

    看了上面文章后,觉得对于需求迭代比较快的团队来说,code review只能是提倡不是来强制的,需要培养氛围。虽然也认为code review很重要,但对作者一些观点还是不赞成的,代码质量与个人的基础、经验有关系,想通过code review来发生质的改变,几乎是不可能的。复杂的业务关系很多问题是很难从提交的代码里看出来的,相对来说代码语法、优化方法较容易发现,但这些相对于codereview花的时间各成本来说收效甚微。

  18. TracyZhang
    2015年6月11日11:53 | #18

    确实态度很重要,不管有多忙,有颗追求完美的心就能做出更好的事。求之上者得其中,求其中者得其下。共勉

  19. 小王
    2015年8月24日10:38 | #19

    关于可读性和CR有一个很重要的关系,太大段的code可读性大大低于几行的code,很多被要求CR的同僚会敷衍了事,ship it! git和p4明明是两个版本管理的软件,在CR上面会出现很不一样的故事。p4会比较容易导致一次check in一个大功能,CR草草了事。git就会拆开一个个小功能讲故事,而CR质量也会因为代码少,可读性增加而提高。

  20. 2015年8月28日20:03 | #20

    @大口丁
    同感,不过要看上级和管理吧。像博主这样的伯乐是很少见了吧。
    遇见了就是其幸大哉!

  21. 2015年10月14日15:40 | #21

    “竭泽而渔”,涸泽而渔,错别字;
    疲于跟命,疲于奔命,笔误,前后不一致;
    修身养道,修身养德?和“关于页面”不一致;

  22. 蛙蛙
    2015年11月4日14:32 | #22
  23. 杂货铺老板
    2015年12月12日09:54 | #23

    被业务方逼得紧不要抱怨,你没有时间被逼得像牲口一样工作,这个时候,你需要的是暂停一下想一想,为什么会像牲口一样?而这正是让你变得聪明的机会。

  24. Yimi
    2015年12月13日22:30 | #24

    读陈老师的博文总有不同的收获,谢谢!

  25. zhangzl
    2015年12月30日12:58 | #25

    到了 可读这个层次,我觉得就会自动有可维护性啊,为啥还要单列出来可维护呢?

  26. 风清扬
    2016年1月20日16:35 | #26

    顶皓哥,本人亲身经历,code review还是很有必要的。如果一个项目很庞大,不注重代码质量,后期很难维护。

评论分页
1 2 3 4 11432
  1. 2014年10月31日18:26 | #1
  2. 2015年3月5日20:06 | #2
  3. 2015年5月14日23:20 | #3
  4. 2015年5月24日08:43 | #4
  5. 2015年8月27日22:33 | #5