从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 ,请勿用于任何商业用途)

好烂啊有点差凑合看看还不错很精彩 (221 人打了分,平均分: 4.78 )
Loading...

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

  1. 其实这个和公交车司机一样,有追求的司机车交通再糟糕也能把车开稳。

  2. 亲身体会到review有很多好处,尤其对一个不太成熟的因队,对个人的成长有很大帮助。
    一直不认为review会耽误开发时间。

  3. Code review是必须的,绝对是磨刀不误砍柴工。工作10年了,一直都执行code review。对于潜在的深层次的问题,可能只有code review才能发现。不过review的方法和组织很重要,博主引用的“代码审查速度“就是一个毫无意义的标准,我们的review系统就有这么个参数,我多次质疑过。楼主要是能再写个怎么做code review的文章,那样更有意义。
    反对者的立场,我绝对能理解。谁也不能抱怨农民工不爱惜身体,最后看病花钱多吧?这话题就大了。

  4. 看了耗子哥多年博客,第一次感到共鸣(以前都是纯粹的学习,因为我还是个菜鸟,有的文章还要看几遍才彻底理解),刚刚辞职了,感触特别深。
    在原公司,需求不断来,项目做完了上线了,缺陷无数,客户需求又变了;
    发起一个code review,过一周一看,会上我指出的代码错误一个都没改,一问:啊,我忘了,就这样吧。
    呵呵,大概因为我不是组长?只是个破代码走查负责人是吧。
    我的代码呢,没人走查。我跟组长提出,走查不能我来走查别人,没人看我的,我就算技术比他们强,我工作才两年多,又不是大牛,我的错误肯定山高海深,有些东西我自己看自己可能看不出来,需求互相走查。他说:你指望谁走查你的代码呢?A君?B君?他们八成就是随便应付了事。我当时也不知道说什么了,心里只有呵呵呵。
    我写了公用代码和可用模块,有人用有人不用,组内用组外没人理,领导完全无视,只关心:这个项目还要多久?那个项目呢?几个项目组在闭门造车,不断重复造轮子,没人在乎。技术经理在干什么呢,我不知道,我只知道这家公司两年多来技术上进步可谓完全靠裁员和更高薪招人。
    再多说点:有次和同时闲聊,说道现在感觉技术好烂,有段时间没什么进步了啊,心情有点烦。他说:你技术差?那我们不是更差。。。然后一顿吹捧我。当时我的感觉,这家公司不能再呆了。我毕业进公司,基础可以,但实用技术最差,要不断请教别人,一年后,别人不断请教我。再然后,组内基本可以说技术第一;但是,也就是21分和20分的区别,也就是多看了两本书,写得代码犯错少一点。有人说,勤奋就能牛逼;我想说:勤奋可以牛逼,但环境也很重要,周围都是混日子的人的时候,一个普通人也必然受到侵蚀;周围都是一心向上的人,再普通的人也会学习。
    最近一直在思考,是不是完成项目是第一位,老老实实干完就对了,测试通过项目就完结了,工资就到手了,老去追求代码质量是不是脑残呢?多谢耗子哥这个文章算是解疑答惑了:我可以是菜鸟,我可以被逼完成无谓的需求,写脑残的代码;但是我心里一定有向上的心,对代码负责的态度,对自己写的垃圾羞愧的想法,以及该走就走的觉悟。
    很快要去新公司了,我希望能坚持住自我。同时也希望耗子哥有闲暇的话,可以针对菜鸟程序员进步之路多提一些意见和指引。尤其是,一年期的各种困惑,和三年期的迷茫。前者已经度过,后者现在正在迷茫。
    老公司是什么就不说了,只想说,老同事对我真的很好,上司对我也非常好,公司福利还可以,薪资也不错,也挺关心员工,可惜了,志趣不同。祝安好!

  5. 感触最深的是整合阿里云api那段,工作中的得到一个感触是完成功能并不是要把所有事情都自己做完,而是想明白如何做完做好。把属于其他团队的问题反馈回去,而不是自己不停的做补丁,帮别人遮盖错误

  6. 你也是在吐槽,土鳖就是要为了这些东西奔波,土豪才不管你在说啥。什么是code不需要明白!生活很逍遥

  7. 我觉得code review不仅仅是团队间,而且应该是在个人,代码是要推敲的,当然让别人review也是使得自己快速成长的一条捷径。那些无视code review的人,我只能说,道不同不相为谋。
    当然我觉得楼主后来关注的焦点其实不是code review,而是设计评审的事情了,我倒觉得可以另起一篇文章来单独探讨。
    最后我觉得,任何公司,事实胜于雄辩,只要坚持自己的原则,如果能够通过产品证明是对的,那我觉得自然会让那些jjww的人闭嘴。楼主大可不必同他们一般见识,唯一需要提防的是他们的言行可能会扭曲下一代对于相关问题的看法

  8. 首先声明,我是特别支持code review,也一直这么执行,只是在执行过程中,多少感觉很无力。我来说说这骨感的现实:
    1、时间成本:
    但凡做个开发的人都知道,需求的变化,人员变化,配置变化,都可能影响整个软件开发的周期,各个阶段的时间都有可能被压缩,需求分析不能少,coding不能少,联调不能少,测试不能少,那最看不出任何踪迹和效益的code review显然最容易被忽略,很明显,如果把几十万行代码都看完,或许能发现问题或许发现不了问题(跟能力有关),结果不可预知,却消耗的研发工时,当项目经理不够强势和足够说服力的情况下,老板很容易砍掉这部分工时。
    2、能力成本:
    团队里,一般情况,会有不同级别的程序员,高中低,项目经理review高级,高级review中级的,中级review低级的,如果作为一种考核制度制定下来,查出多少有问题的code,做一些惩罚,皆大欢喜。现实情况下,高级程序员一个两个,中级或者初级一大堆,项目经理很忙,高级稀少,剩下的中级和初级,在没培训和大量自我学习,又能期待他们能检查出多少代码的问题?

    3、执行效果:
    一个有效的code review必须是有法可依,有据可查,一个研发团队,针对不同语言编写的软件、不同类型的项目、是否依赖其他的系统,设计不同的code review标准,code review作为一种规则和需求,需要持续更新维护,试问,这样的制度随着时间推移,人员更替,人员培训成本,如果不作为一种KPI考核标准,会有多少团队能坚持下来而且执行有效?

    4、适用范围:
    code review是不是所有的项目都要做,作为个人能力和基本职业要求,当然没问题,我列举几种场景,你看看那个更有优先级来做code review?
    1)、计算机专业研究生毕业设计
    2)、企业POC演示软件
    3)、日访问量百亿的网站
    4)、日交易量千万商务交易平台
    显然各个场景对代码的质量要求不一样,决策者对产品的品质要求也不一样,谁都能看出来那些产品更应该做code review。

  9. 在什么样的大环境下,就应该做什么样的事情,脱离了这样一个上下文,也只能是向往一下,说说而已。不过要经常地审视自我,铭记自己本不该忘记的东西就可以了。

  10. 外和内的区别:
    外:决定一个事很快,办这个事要求细致到无法言语
    内:决定一个事很慢,办这个事要求时间短到无法理解!

    从程序员作出来的,谁不是这么出来的?
    你经历过,就不要站在岸上指指点点了,在水里的什么心情?
    有能力就为大环境的改善出点力吧!

  11. 同意8楼,作为个人能力的提升没问题,也是对自己负责,当然是在“空闲时间”,别挤占上班时间,不允许的。
    牲口?你和这时代一样,越来越浮躁了。
    出国吧,比较适合你…

  12. 我非常赞成你的观点,在上次我们团队说接下来我们团队建设和学习新的方向和知识时,我就推荐了CR,可是另外一个同学就觉得枯燥,没用等等;可是我觉得他对CR认识的好短浅。很囧。。。

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

  14. Code Review的确很重要,是一个不断否定自己和不断重新认识自己的过程,我本人的很多收获都是来自Code Review。

  15. 当年偶找的第一份工作,那个奇葩公司连设计都不做……

    但我仍然坚持先出文档后编码。因为再明显不过了,多花几天时间做设计,在把一切都想通、安排就绪之前不编码,原本几个月都做不完的东西,往往只要几天就能搞定,而且很容易就能0 bug。

    后来,这个项目做到了“客户提的任何合理需求,都能在一天之内完成”。

    等我离开之后,他们5年都没找到能接下这个项目维护任务的人,居然又打电话来了。只是我那时的薪水,已经不是他们出得起的了。

    ——————————————————————

    国人的一大劣根性,就是轻视技术。这种轻视已经渗透到了骨子里,以至于很多搞技术的人本身就轻视技术。

    正是这种轻视导致各种不思进取的奇葩。他们拿“能够不动脑子、直接堆砌代码实现需求”当作终极追求。

    你说“稍微做点设计,就能以小得多得多的代价完成”?呵呵……你能保证总能这样吗?你敢保证没有“万一”?

    更甚者,我见过这样的同事:他说,“晚上/星期天加班……最起码,万一捅了漏子……能证明你的态度;如果不加班,出了问题你可无话可说”。

    ——我的看法是:
    ——首先,我知道自己能拿什么钱,不能拿什么钱;
    ——其次,拿什么钱,我就做什么事,超过能力范围我不接;
    ——第三,有把握接我就有把握做好,做不好说明我太高估自己,说明我不能胜任这个职位,那么肯定早走早安心,省得闹得两边都不好看;
    ——最后,可能的风险我会事先列出来、并尽力控制。但如果真规避不了,那就说明这种风险是必须承担的成本之一,只能请公司体谅。如果不肯体谅,那我也觉得这种公司没有呆下去的价值。
    ——至于加班……不好意思,加班说明我对工作量估计不足,属于能力问题。不去追求工程质量、反而用加班来假装“敬业”,才是态度问题。

    ————————————————————

    另一家公司。每次做计划都喜欢追求“一星期”,时间越紧越好;然后每次都做成几个月甚至半年、一年。

    最后,他们程序的质量……只能demo forever

    当他们说什么“一星期就好”时,我的回答是“我从学习GTK到用它写出一个钻石迷城只用了三天;但那是因为经理给了一星期的时间供我学习GTK。如果只给我三天就想要钻石迷城,那么很可能一星期后,连GTK是什么我都说不清”。

    ————————————————————————————————

    正常情况下,在软件开发这件事上,公司的利益其实和个人的利益是完全一致的: 致力于做精品、致力于写出更高质量的代码,对公司价值、员工价值,都是一种提升。

    而且,如我之前提到的,高质量代码带来的,常常是10倍以上的高效率,而不是相反。

    如果两者目标出现了偏差,那么就说明要么是员工不上进,要么是公司不懂技术。

    http://www.mengstupiditis.com/2011/06/do-right-thing-wait-to-get-fired.html

  16. 我从两年多以前开始接触code review,当时本觉得没用,后来才发现其重要性,如楼主所说,如果没有code review的习惯,简直不敢想象。

  17. 这篇文章看下来很畅快,基本是全同意。少有的看楼上文章没有质疑的。这篇写的非常好。

  18. 写的太好了,我就是文章中说的忙的像牲口一样的苦逼开发。顶一下这句话, “我知道你们会因为骨感的现实而妥协,但是我希望你们就算在现实中妥协了也要在内心中坚持尽可能高的标准”。

  19. “我心里非常不认同这样的观点,我觉得我是程序员,我是工程师,就像医生一样,不是把病人医好就好了,还要对病人的长期健康负责。” 以前,我带我家闺女到武汉的同济医院去看病,发现那些返聘的,年龄70+的医生的号,总挂不到,她们看病总是开最简单的药,一般不给小孩打针. 当时我就觉得我们程序员其实和医生有诸多相似之处,医生是越老越知吃香,而程序员是30岁现象.值得我们思考.

  20. 在百度,可能是面上的,也可能是我只待过的两个team是这种情况:
    1、甭说review了,一直乱,从未治理;
    2、百度的高大上,并不代表每个深处其中的个体在个人能力和代码水平上同样高大上;
    3、作为team中服务治理和code review的推动者,逐渐感觉到各种疲惫,各种对自身价值的怀疑。。。

  21. 非常赞同耗子的看法,我一直认为,反对做codereview的工程师一定不是对自己有高标准的人。阿里很多业务线的代码烂得一塌糊涂,没时间做codereview和没必要做codereview根本不是一回事,好多人没认真看完耗子的唠叨就开骂。

  22. CodeReview无疑是很重要的,而且我觉得不想做的人都是自私的人:“反正这个烂滩子以后会交给别人的”
    我们总是在抱怨前人留下的代码太烂,同时自己又在不遗余力地生产这样的代码。

  23. 你的怨气太重了,老兄. coding重要,codingReview也重要,但是都不如一颗平和心重要. 本来就没有一个”绝对”的事情, 不同的项目,不同的高度,做不同的要求. 欧美人是很职业的,他们的基因就是如此,但是很难套用在我们的文化背景下. 己所甚欲,难施于人.

  24. 听命于人,或听从内心;
    不必赞同,更不必攻击;
    互联网精神本就是一场革命,新的世界必然革掉腐朽;
    众生本就平等,互联网创造自我管理的新格局。

  25. 在我们的项目遇到的问题是
    需求不透明,每个人都独立负责一个业务,design没有一起review, 开发业没有peer coding,在code review的时候,因为参与review的其他人不了解需求,所以只能看出来一些类似coding style,NPE, 最多就是这代码是否线程安全。

  26. 说的好。

    不过时间不够的问题,lz分析的简单化了,毕竟不是所有的需求都能够象你这样来简化的。

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

  27. @Ken
    比较赞同你提出的疑问,
    1、聚石塔的案例就是在阿里云已经有功能的前提下缩减需求的,但是大部分业务可能没有这样的优势,这个案例其实想表达的意思是让工程师去拒绝需求,但是在快速迭代的电商公司的业务开发里,这个很难做到,作者并没有告诉应该怎样做。
    2、Code review当然是有意义的,但是更多觉得是“鸡肋”,因为很多bug不是凭肉眼能看出来的,review的更多的是编程习惯(异常的捕获处理等)和代码风格,而代码质量还是得依赖工程师的素质、单元测试、功能测试、性能测试等;
    PS:觉得作者面对质疑的态度并不友好,你是Coolshell的站长也是微博大V,是公众人物,应该能很好地面对和回答质疑的。。。我们不反对Code review的好处,但是为了说它的好处而举的例子并没有说服力。

  28. 好与能,是两回事。
    因为觉得好而强迫别人接受就是另一回事了。
    Code Review的好处大家都接受,但是好不代表就能做到。
    人人都觉得长的漂亮,长的帅好。但是你能做到吗?
    做事应该遵从实际,教条会害死人。
    理论的研究与实际的情况是要做严格的区分的。
    否则就只有科学家,没有工程师了。
    工程师应该更加务实。
    过份追求Elegant就是浪费生命。
    我支持那些反对你的人。

回复 kazaff 取消回复

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