从Code Review 谈如何做技术

从Code Review 谈如何做技术

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

这两天,在微博上表达了一下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 ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
好烂啊有点差凑合看看还不错很精彩 (124 人打了分,平均分: 4.85 )
Loading...

从Code Review 谈如何做技术》的相关评论

  1. 你说的Amazon教育开发人员去“拷问”需求,我很有感触。作为一个新人,我把自己的姿态放的很低,很多的工作都是默默去干,也不问为什么;结果是,做完了都对自己做的东西不是很清楚,明明需求中有些不太好的东西,感觉不对,也没提出来,后来苦果子还是自己吃。所以,尤其看了这篇博客后,我更有勇气去评估需求,不合理的不做,有瑕疵的早点修改,因为我是想成为一名工程师,不是一个牲口。
    在卓越程序员的道路上,有你这样一位优秀的学长领路,甚幸!

  2. 我只想说图片有点:compulsory. 木哈哈。我觉得如果大家都是做技术的,在自己有观点时,把它说出来,写出来是挺锻炼人的,特别是能坚持这件事。之前看到[codinghorror](http://codinghorror.com)博主Jeff Atwoods(Stackoverflow创始人之一)博文集结的中文译文,觉得其博文的质量以及博主的坚持实在难能可贵。不管是给别人看还是给自己看,不管别人喷还是不喷。写博文是提高以及锻炼自己能力非常有效而且是值得推荐的一件事。它有篇文章也是讲Code review和peer review的,阐述其重要性。但是大千世界,无奇不有。就像布鲁克斯说的一样,there is no silver bullet。大家都是文明人,人身及语言攻击就算鸟。讨论讨论人生,喝喝小酒;讨论讨论技术,喝喝小酒:不是挺好的么。

  3. 其实非常的像review,只是大家的工作都没怎么关联,做的是不同的项目,自己的项目同事不清楚,同事的项目自己也不清楚,如果review的话,还得再去理解别人的逻辑,非常的不妥。甚至使用的框架也不一样,可能自己都不会。。。外包的工作,说多了都是泪

  4. 必须要有这种意识和观念,“吾日三省吾身”。简单来说,就是时常总结并萃取。虽然上帝会发笑,但我们还是要多思考。否则就是退化为牲口了。

  5. 其实这世上总有有志于做普通泥瓦匠的人,也有想做工程师的人。基于上线的那些都是小房子,不是大工程。review的工时花出去有点浪费了。我只是这样认为而已。

  6. 我现在的公司就从偏技术转向了偏业务,review几乎都不做了,很多情况下i0nstall脚本都无法执行就commit,但是没办法,kpi里只有按时交付,其他的坑以后再填(谁爱填谁填)

  7. cannot agree more… Hao Zi, good work!
    1)可编译,2)可运行,3)可测试,4)可读,5)可维护,6)可重用

  8. 赞!
    “因为我的KPI和年终奖based on how many works I’ve done!而不是How perfect they are ! ”
    大多数人都是这样。
    Code Review 不只是对代码的Review, 其实工作中任何事情都需要!
    短短人生,疲于奔波! 做了很多,可是没有几件深刻的。

  9. “说这个故事,我不是为了得瑟,而是因为有些人在微博上抨击我是一个道貌岸然的只会谈概念讲道理的装逼犯”,跟网上的人认真你就输了,网上的什么人都有,羡慕,嫉妒,高贵,冷艳,故作深沉。。。。何必认真呢。。

  10. Code Review肯定重要,毋庸置疑!实际上review重要的何止Code?Quote,需求,schedule,Design哪个不重要?
    就自己公司而言,前两年竞争不算激烈,每个都review,开发人员从需求开始就参与review,整个项目完成后,质量确实很高,自己也进步不少。但是现在项目忙了后,review都只能安排成offline,没空review了。毕竟商业市场,做出来比做的好优先级要高,真心立志做行业百年老店的老板不多!有追求的人,只好match schedule的情况下,自己找时间review自己以前做的,或者别人的东西。当然,对我们的高级架构师来说,他非常看重review,因为在完成设计之后,他的工作就是把握质量。

  11. 仔细看完文章和评论,综合起来考虑,说说我的看法。
    首先,我觉得CodeReview是非常有意的,我觉得这是毋庸置疑的。
    其次,很多朋友抱怨项目工期紧或者业务需求多变(其实都可归结为时间紧),所以没时间做CodeReview,从而得出结论CodeReview不那么重要了。其实我觉得这里有个误区,因为时间紧所以不坐CodeReivew,这只是说明CodeReview对于完成一个项目的开发工作不是必要条件,但不等于说它不重要,项目时间更紧张的时候,连测试都能砍掉,这能说明测试也不重要吗? 很多人可能是把“必要”和“重要”划等号了。
    第三,我觉得相对于说服开发人员明白CodeReview重要性,更重要的是说服boss,让他们明白CodeReview的重要性!他们若是深刻理解了CodeReview的重要性和能带来的收益后,我相信不想做CodeReview的开发人员也得做CodeReview的工作了。

  12. 支持陈皓,CodeReview我很少见人关注过,楼主被大量人喷我觉得是很正常的事情, 在现在的it技术环境中,关注CodeReview的才是异类, 做开发的时间越长,我发现我越难跟别人合作,因为我觉得很数人的代码太丑了,无奈我权利不够,否则我会让他们选,要么好好写,要么走人。
    同是开发人员,个人的追求也是不同的,对于追求进步的人,自己都会不停的做CodeReview,重构,研究怎么把代码写的更优雅, 更多人只是为了完成功能, 老手也有,功能是做出来了, 但结构太烂,让人没法看, 全局变量满天飞, 哪块程序功能都贼强大,上天入地,无所不能。 我要是有权利,就找一帮老实的小弟,听话的干,不听话的别干;没有权利,我就自己多写吧,自己做的比较放心,呵呵。

  13. 其实说白了,就是,你愿意进入良性循环,还是愿意进入恶性循环的问题。
    代码review–>认清问题–>重构–>提升能力–>提升效率–>减少项目时间
    不代码review–>积累问题–>问题爆发+新需求–>没时间提高……

  14. 不能同意更多,支持, 很多人不把自己当工匠累得要死不知道在瞎忙什么,很多人瞎提需求抱怨技术人员却不知道自己的本职工作有没有做好,太多太多,现实就是残酷的

  15. 支持浩哥。
    去年曾聆听过浩哥的教导,很受用。知道自己基础不好,但喜欢钻研技术,所以不管多累,都坚持每天看书,晚上看技术,早上看英文。
    自己也一直坚持请同事review自己的代码,虽然有时候会有让我面红而赤。
    Code Review的重要性其实大家都清楚,主要问题在执行方面。
    至于有关业务的其他因素,有时候我们这些虾兵蟹将只能发表意见,老板也只是听听,该怎么办还要求原样执行。例如我们现在干的事儿就是老板十几天前定的,要做一个教育方面的即时聊天App,并且要求使用邮箱作为通信协议,每条信息就是一封邮件。大家听了都觉得不靠谱,但是还得干。

  16. 支持皓哥,支持cr
    但是对国内这种浮燥的开发模式很无语,开发人员没有话语权,管理层急功近利,项目开发过程中只有当下,没有长远……所谓质量在这样的环境里都只是一句空谈~~~

  17. 感通深受, 但觉得要review的不只是code

    design, test case, test code同样需要review.

    而且这种review不是基于what, 和how层面的, 这两个层面因该是程序员的现在注释或者文档里的

    真正需要review的是why层面的东西. 是 can? is?层面的东西. 这比公司天天强调autotest, tdd强多了. 一个好的设计可以减少很多无谓的test case. 这些东西都是切实能提高项目质量的

  18. 说的很好,但开发人员是没有话语权的,领导SB无解在大公司已经成为通病。
    “对自己负责就是,用脚投票,如果妥协得受不了了就离开吧。”这句最有价值。

  19. 耗子叔,感觉你没有完全放下,其他人的做为你没必要再乎也没必要在文章里面提到。技术贴应该纯粹

  20. 文章写的不错。
    有两点达成了共识:
    1. 自己保持高标准要求,虽然有妥协。
    2. 要教育产品经理引导客户,拒绝无明确意义的需求。

  21. “对自己负责就是,用脚投票,如果妥协得受不了了就离开吧。”和“当你忙得跟牲口一样,你应该停下来,问一下自己,自己成为牲口的原因,是不是就是因为自己做事时候像就牲口一样思考?”
    妈的,说的太对了!看完我都觉得自己是牲口!

  22. 业务变化太快,导致技术负债越来越多,最后代码无法维护是这个行业的常见case。以前做手游的时候,为了上线,而且知道代码用过一次后就废弃了,到处乱堆。两年下来发现每次追加新的机能越来越难,太多的处理分歧,废旧代码参杂其中,导致新组员无法开发,于是大家说公司后面招的人能力不行,还是我们老员工好用

  23. 楼主很详细的回应了批评你的观点(2),很希望能看到针对(1)(3)(4)的处理方法

  24. 如果写的代码质量高,CodeReview是不需要太多时间的.没想到阿里是这样的.
    那些大牛,架构师和研发经理们难道说服高层将CodeReview这一工作加入到开发流程的能力都没有吗?

  25. 发现有一段漏打了一个字,建议更正:
    “所以,为了堆出这么多网页就停地去堆,做的东西是很多”
    看起来像是少打了一个“不”字

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*