从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. 读完文章,受教了。态度很重要,若自己没有向上的想法,那么别人怎么推也推不动。另外感想:1.当坚守的标准被拉低一次后,就会有第二次。2.碰到个固执的,讲道理讲不过其他人最后拿职位压人的搞需求的大leader,是件苦逼的事情。

  3. 很同意文中观点~可惜我们公司是搞硬件的,软件没有人懂,做软件的也就两三个人,想推review不知道从何入手,看了原来同事写的代码,怎一个烂字了得~

  4. 我之前在上海现场听过你的培训, 对于Code Review的工作,我个人一直也是坚持并认为是非常好的一件事情,可以学习和发现别人很多你不知道的东西。

    读了你这篇文章,我认为主要还是公司文化差异的问题,外企与国内企业在管理与制度,思想文化方面一致存在差异,很难改变。

  5. 刚工作第一个project code做了1个月,跟着staff code review大半个月,刚开始极其不适应,一轮下来学到很多,不管编程思想,风格 习惯 经验,受益良多!这就是“做出来”和“做得好”最大区别。给耗子哥+1

  6. 强烈支持,羡慕能有你这样的老大。我们团队里面就一个阿里跳过来的P7,天天就知道装高大上,吹牛,呼悠,什么都不懂。

  7. 程序员其实不应该跟工程师划等号,程序员更像是在创作,而不是像工程师一样有规则可循,不做code review就像是十几个人每人画一长溜,不让你看别人的作品,最后拼起来一样

  8. 写得很好,对于即将入职的我来说,是个启发。嗯,真的要努力!
    另,最后一段有个小笔误:elegent->elegant ^_^

  9. “当你忙得跟牲口一样,你应该停下来,问一下自己,自己成为牲口的原因,是不是就是因为自己做事时候像就牲口一样思考?”
    不能赞同更多。

  10. Rework这本书是程序员和产品经理都应该好好读的一本书 他里面的思想跟当下软件需求的趋势有很大出入 但却很实用事情要么不做要么做好 code review是做好的一个体现

  11. 多谢,简略一下:应不应该code review?应该。如果不能/没时间,那么解决这些问题,不能否决code review。
    另:
    “不同沉湎改进质量的方式不一样” -> “不同层面”?

  12. 一开始做某项目的时候问过有没有文档和 codereview,被告知不需要文档和 review,单元做好就行,震惊得一塌糊涂…

  13. 看了一些人的反驳,觉得很有意思:”软件是写出来的,不是说来说去“。这句话是说:1.作者没有写出好的软件?2.对一个相关事件看法的讨论,对于“软件”这个主体来说没有价值?3。codereview与好的软件的诞生没有多大相关性?

    稍微对此呵呵一下。虽然无论哪个平台,都会出现这种喜欢一句话来做总结,抖机灵。但是出现技术讨论中的时候,总会觉得反感。期待有人用数据以及分析来驳斥。

  14. “对于常见病,要很快地医好病人很简单,下猛药,大量使用抗生素,好得飞快。”

    这才是整篇文章里最正确最强大的一句话,耗子不做医生太可惜了!建议转行!

  15. 态度决定一切啊,但是我们总是会这样,那样的妥协。

    另外说下上面的 a , b 明显的同一个人,我就奇怪了,这么偏僻的地方还是有“喷子呢”,

  16. 效率提高太多,公司限制团队名额,减少了就业机会,加大了贫富悬殊,怎么破?

  17. 一直用狗耳朵关注你的博客,今天早上被震着了。
    文章说的的确有道理,但也仅限于有点道理:code review的确好,但是任何流程都是可以裁剪的;如果人家已经忙的脚后跟打后脑勺了,你这啰嗦就挺招人嫌了—-何不食肉糜?
    最关键的是,全篇我看到的不是code review该如何适应你那个同事的team,没有任何建议和意见帮人想办法,都是在虚弱的证明“我有道理”,哪怕你最后那个例子,更多的看起来也是权力和政治问题,而不是方案问题,须知环境不同同样的办法不一定适用,结果也不一定好。
    你通篇证明的不是code review,而是你自己。

  18. @Ken
    建议博主换个心态来沟通这个事情,帮同事想一些怎么让他们用上code review的切实的建议,过阵子根据反馈写个后续看看。
    另外最后那四个题目,1和3不说,那是开阔思维的题目;2和4如果在你同事那种团队里面,可能更需要的是完善的单元测试和继承测试代码,否则你改了百分之好几十的代码,review是无法保证真没问题的。

  19. 没时间review code的团队大部分是产品(需求)规划和技术规划的问题,业务什么的应该不是理由。
    —来自一家小公司,业务部门研发6年。

  20. 那我们team来说吧,可以支撑1个手机项目的人力,今年规划了6个手机项目,目前有3个手机在同时开发中
    code review?只能呵呵了,上面的领导规划了这么多手机项目,你不做是打算离职了么?

    code review当然好,有时间做必然做,只是,有时候真是没有时间。

  21. code review,在阿里是上线之前必须且重要的一条,目前都是发review board来大家线下看,而组织在一起,大家一起review的情况很少。有点感触,线下review的时候干扰因素很多,基本是很难发现一些bug,除非是明显的。对于发review的人来说,由于不是面对面的看他的代码,代码也不会有什么“面子”上的质量提升。为啥不组织在一起呢?还是文章里提到的,时间+项目。但是目前的经验来看,很多时候,后续查bug的时间原因大于review的时间,但是很多人目前还是意识不到这个带来的好处。

  22. 对很多冥顽不化的人,其实没必要跟他讲道理,佛法不度无缘之人。铺砖式的“开发”,必然长不了多久,没有进化能力,系统内部混乱不堪,让接手的人想骂娘,如果程序员让人业界和社会当作真正的工程师来尊重,而不是另外一种形式的民工,那你就就必须用你的作品证明自己,保证你的代码够优雅。阿里的业务发展还不错,说明阿里内部耗子大哥这样的真正值得尊敬的工程师还是主流

  23. 不能同意更多!好苦恼现在的研究生读的有什么意义,想把事情做漂亮,但是根本不买账,就是要求你尽快拿出东西出来忽悠用户,求指教,在这种情况下如何坚持自我的标准?

  24. 以前在日企工作的时候,程序开发最基本的三个环节,Coding、Code Review、Unit Test,这三个环节任何一个没有做,都算没有做完。以前也觉得Code Review是多余的,但是当你做多了Code Review的时候,会发现能从别人代码做学到很多自己不足的地方。特别是当你去Review技术比自己牛很多的人(一般Code Review都是交叉进行)会有很多的收获。

  25. 没有时间,基本都是设计决策出了问题:
    1、需求分析做的如何?
    如,只有HR才可以查看员工的详细资料,或者通过内存池提高程序的性能等这些都是不好的需求。对于前者,如果按照这个需求去开发软件,那天总经理也想看员工的详细资料,是不是还得找HR,或者去重新修改软件.
    2、对于某些决策,是否可以晚点再点决定,直到如果不做决定,大家就没法干活了的时候。
    对于那些全局性影响比较大的,可以早点做决定。但是很多看是全局性的,实际上可能不是全局性的。比如是用数据库A还是数据库B,是用操作系统A,还是操作系统B,写个适配层,不就解决了吗
    3、你的决策时基于什么来做的,社会,技术还是时间或者成本?做出这个决策后,如果以后改变它,有多难,有多大的选择余地。
    4、有没有考虑借鉴控制反转,依赖注入,eclipse插件或者是corba idl思想?再到小了,在逻辑上相似的代码,有没有考虑,利用代码生成代码,或者是散落在软件中各个部分重复的代码,有没有想过,利用元数据处理,或者利用宏去处理?你的模块,类,函数是否让它改变的原因只有一个?
    还有很多,所有一切都可能是让你忙的一塌糊涂的原因。
    一点题外话,最近去微软听了一个讲座,是关于软件领域的一个全自动化框架,从研发到生产线,从生产线到研发,全部自动化,里面包含了各种评审,检查,如果某项不做,自动化工具就不让你提交代码。当然最重要的是,讲师说了这么一句话,你要把软件当做你的孩子一样去培养,虽然,在某些情况下,这句话有点过,但是,这不得不说是一种高境界,这也是陈浩所推荐的《代码大全》里讲到的一种思想,那里面如果我记得没错,是用了培育这个词。
    有句话大概是这么说的,你的决策不是刻在石头上的,而是写在沙子上的,如果解决某个软件问题,这是你想到的唯一解决办法,那这就是你做出的最危险的事情了。总之,要尽量做到让你的代码灵活,易于重用。以上纯属于个人观点。

  26. "芝兰生于空谷,不以无人而不芳!君子修身养道,不以穷困而改志!"这句话说的好。看得出博主是个有着很高自我要求和修养的人!用脚投票吧

发表评论

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

*