?!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
q两天,在微博上表达了一下Code Review的重要性。因为翻看了阉K内部的Review Board上的记录Q从上面发现Code Review做得好的是一些比较偏技术的团队Q而偏业务的技术团队基本上没有看到Code Review的记录。当Ӟqƈ不能说没有记录他们就没有做Code ReviewQ于是,我就问了一下以前在业务团队做过的同事有没有Code ReviewQ他告诉我不但没有Code ReviewQ而且他认为Code Review没用Q因为:
1Q工期压得太紧,旉qcoding都不够,以上Uؓ目的?/p>
2Q需求老变Q代码的生命周期太短。所以,写好的代码没有Q何意义,烂就烂吧Q反正与l效无关?/p>
我心里非怸认同q样的观点,我觉得我是程序员Q我是工E师Q就像医生一P不是把病人医好就好了Q还要对病h的长期健庯责。对于常见病Q要很快地医好病人很单,下猛药,大量使用抗生素,好得飞快。但大家都知道,q明显是“饮鸩止渴”、“竭泽而渔”的做法。医生需要有责Q心和ddQ我也觉得程序员工程师也要有相应的责d和相应的修养。东西交l我我必需要负责,我觉得这U负责和修养不是”做出来“就了事了,而是要到“做漂亮”这个别,q就是“山寨”和“工业”的差别。而只以“做出来”ؓ目的标准Q我只能以ؓQ这L做法只不q是“按部就班”的堆砌代码|了Q和力_密集型的“装配生产线”和“砌砖头”没有什么差别,在这U环境里呆着q不如离开?/p>
老实_因ؓd我在业务团队的时候,我的团队也没有做Code ReviewQ原因是多样的。其中一个重要原因是Q我刚来阉KQ所以,需要做的是在适应阉K的文化,M公司都有自己的风格和特点QQ何公司的做法都有他的理由和成因,对于我这L一个初来者,首要的是要适应和观察,不要对团队做太多的改动,跟从、理解和信Q是融入的关键。(注:在徏北京团队和不要专职的试人员上我都受C一些阻力)Q所以跟着团队走没有玩Code Review。干了一q后Q觉得我妥协了很多我以前所坚持的东西,觉得自己的标准在降低Q想一惛_背拔凉拔凉的Q所以我军_坚持Q而且q要坚持高标准?/p>
对于Code Review很重要的q个观点Q在微博上抛出来后,被一些阿里的工程师,架构?专家Q甚臌深架构师批评Q我在和他们回复和讨论的q程中,居然发现有个“因为对方用L讄”我无法回复了(我被拉黑了,q有一些直接就是冷讽和骂h了,微博中我q接删除了Q。这些批评我的阿里工E师/架构师的观点ȝ一下如下:Q顺便说一下,阉K内还是有很多团队坚持做Code Review的)
1Q到业务团队体会一下,倒逼工期的目有多?订好交付日期后再要求提前1个月的有多少Q现在是做到已经不容易,更不谈做得漂亮!?/p>
2QCode Review是一U教条,意义不大Q有试Q只要不出错Q就可以了?/p>
3Q目标都是改q质量,有限的投入d望能有最大的产出Q不同沉湎改q质量的方式不一P业务应用开发忙的跟狗一P而且业务逻辑变化快,通用性差QCode Review的成本要比底层高?/p>
4Q现在的主要矛盾是倒排出来的工期和不靠qE序员之间的矛盾Q我认ؓCode Review不是解决q个问题的银式V不从实际情况出发光打正义的嘴炮实在太过于自C ?/p>
我们可以看到Q上面观点其实和Code Review没有太多关系Q其实是在抱怨另外的问题。这些观点其实是技术团队和业务团队的矛盾,但不知道Z么强加给了我的“Code Review很重要”的q个观点Q然后这些观点反q来冲击“Code Reivew”,q说“Code Review无用”。这U讨论问题的方式在很常见Q你说AQ我说BQ本来A、B是两件事Q但是要Z谈,然后似是而非的用B来证明你的A观点是错的。(也许Q这些工E师/架构师心存怨气Q需要一个发泄的通道Q?/p>
我觉得,很多时候,人思考问题思考不清楚Q很大一部分原因是因为把很多问题混ؓ一谈,q我自己有些时候都会这栗引以ؓ戒?/p>
即然被Z谈,那我来拆分一下,也是下面q三个问题:
Code Review有没有用的问题?/p>
Code Review做不h的问题?/p>
业务变化快,速度快的问题Q技术疲于跟命?/p>
Code Review
你Google一下Code Reivewq个关键词,你就会发现Code Review的好处基本上是不存在争议的,有很多很多的文章和博文都在说Code Review的重要性,怎么做会更好Q而且很多公司在面试过E中会加入“Code Review”的问题。打开Wikipedia的词条你会看到这L描述—?/p>
卡珀斯L斯(Capers JonesQ分析了过12,000个Y件开发项目,其中使用正式代码审查的项目,发现潜在~陷率约?0-65%之间Q若是非正式的代码审查,发现潜在~陷率不?0%。大部䆾的测试,发现的潜在缺L会在30%左右?/p>
对于一些关键的软gQ例如安全关键系l的嵌入式YӞQ一般的代码审查速度U是一时150行程序码Q一时审查数百行程序码的审查速度太快Q可能无法找到程序中的问题。代码审查一般可以找到及U除U?5%的错误,最高可以到85%?/p>
也有研究针对代码审查扑ֈ的缺L型进行分析。代码审查找到的~陷中,?5%是和计算机安全隐患有兟뀂对于品生命周期很长的软g公司而言Q代码审查是很有效的工具?/p>
Code Review的好处我觉得不用多说了,主要是让你的代码可以更好的组lv来,更易读,有更高的l护性,同时可以辑ֈ知识׃nQ找到bug只是其中的副产品。这个东西已l不新鲜了,你上|可以找到很多文章,我就不多说了。就像你写程序要判断错误一PCode Review也是最基本的常识性的东西?/p>
我从2002q开始就在严格的Code Review中,我的个h成长和Code Review有很大的关系Q如果我的成长过E中没有l历qCode Reviewq个事,我完全不敢想像?/p>
我个Z码有q几U别:1Q可~译Q?Q可q行Q?Q可试Q?Q可读,5Q可l护Q?Q可重用。通过自动化测试的代码只能辑ֈW?QQ而通过Code Review的代码少会在W?Q甚至更高。关于Code ReviewQ你可以参看本站的《Code Review中的几个提示?/p>
可见QCode Review直接关系C你的工程能力Q?/p>
Code Review 的问?/strong>
有下面几个情况会让你的Code Review没有效果?/p>
首当其冲的是——“h员能力不”,我经历过q样的情况,Code Review的过E中Q大家大眼瞪眼Q没有什么好的想法,不知道什么是好的代码Q什么是不好的代码。导致Code Review大多数都在代码风g。今天,我告诉你Q代码风DU事Q是每个E序员自查的事情Q不应该费大家的时间。对此,我有两个Q?Q你团队的h招错了,该换血了?Q让你团队的时候阅M下《代码大全》这本书Q当Ӟq要d多基知识的书Q?/p>
ơ当其冲的是——“结果更重要”,也就是说Q做出来更重要,做漂亮不重要。因为我的KPI和年l奖based on how many works I’ve doneQ而不是How perfect they are ! q让我想到那些天天在用Spring MVC做CRUD|页的工E师Q我承认Q他们很熟练。大量的重复力_。其实,仔细想一下好多东西是可以框架化,模板化,或是自动生成的。所以,Z堆出q么多网就不停地去堆,做的东西是很多,但是没有M成长。急功q利Q也许,你做得多Q拿C不错的年l奖Q但是你失去的也多,失去了成Z个卓工E师的机会。你本来可以让你的月薪在1-2q后?-2倍的Q但一q后你只拿到了ؓC多的q终奖?/p>
然后是——“h员的态度问题”,一斚w是懒,不想_求精Q只要干完活交差了事。对此,你更要大力开展Code Review了,让这Uh写出来的代码曝光在更多h面前Q让他ؓ质量不好的代码蒙。另一斚wQ有Z觉得那是别h的模块,我不懂,也没旉LQ不懂他的业务怎么做Code Review? 我只惌Q如果你的团队里q样的“各个自扫门前雪”的事越多,那么q个团队也就没d性,没有d性也p不可能是个好团队Q做的东西也不可能好。而对于个人来_也就不可能有成ѝ?/p>
接下来是——“需求变化的问题”,有h认识Q需求变得快Q代码的生存周期比较短,不需要好的代码,反正q两天这些代码就会被废弃了。如果是一ơ性的东西Q的质量不需要太高,反正用了扔。但是,我觉得多多少要Review一下这个一ơ性的烂代码不会媄响那些长期在用的代码吧,如果你的目全部都是临时代码Q那么你团队是不是也是一个时团队?关于如果应对需求变化,你可以看看本站的《需求变化与IoC》《Unix的设计思想来应对多变的需求》的文章 Q从q些文章中,我相信你可以看到对于需求变化的代码质量需要的更高?/p>
最后是——“时间不够问题”,如果是业务逼得紧,让你疲于奔命Q那么这不是Code Review好不好问题,q是需求管理和目理的问题以及别的非技术的问题。下面我会说?/p>
不管怎么P上述Code Review的问题不应该成ؓ“Code Review无意义”的理由或借口Q这好像“因噎废食”一栗干什么事都会有困隑֒问题的,有的人就q样退~了Q但有的人看得到利大于弊Q还是去坚持Qh与h的不同正在这个地斏V这是Z么运动会受伤Q但q是会h去运动,而有人因为怕受伤就退~了一栗?/p>
被业务逼得太紧
被业务逼得太紧Q需求ؕ变,q其实和Code Review没有多大关系了。对此,我想先讲一个我的故事?/p>
我去q在阉K的聚矛_Q刚ȝ时候,聚石塔正在做一个很大的重构——对架构的大调整。因此压了很多业务需求,{这个项目花?-3个月做完了后Q一下子涌入?0-50个需求,q规定一个月完成Q搞得团队疲于奔命。在累了两周后,我仔l分析了一下这些需求,发现很多需求是在重复做阉K云已l做q的东西Q还有一些需求是因ؓ聚石塔这个^C规范没有标准所产生的问题。于是,我做了这么三件事Q?/p>
1Q重新定义聚矛_q个产品主要目标和范_定哪些该做Q哪些不该做?/p>
2Qؓ聚石塔制定标?Q让阉K云的API都长得基本一Pq制订云资源的接入标准?/p>
3Q推动重构阿里云的PortalpȝQ不再实现阿里云已经做过的东西,与阿里云紧密l合?/p>
q些事情推动hq不ҎQ聚矛_的业务方一开始也不理解,我和产品一起做业务方的工作Q而阿里云也被我逼得很惨Q在q里一q感谢,其阉K云的同学Q老实_和阿里云跨团队合作中是我q么多年来感觉最好的一ơ,相当赞)。通过q个事,聚石塔需求一下就有质的下降了。搞得还有几个工E师来和我说Q你q么搞,聚石塔就没事可干了。姑且不说工E师对聚矛_的理解是怎么L?我只惌Q我大量地减了需求,最大可能联合了该联合的人,而不是自己闭门造RQƈ让品的目标和方向更明确了。做了这些事情后Q大家不但不用加班,而且q有旉充电d技术,qؓ聚石塔思考未来的方向和发展。去q公?96的时候,我的团队q在965Q搞得跟异教徒似的)Q而且q有很多旉M研新的东ѝ?/p>
说这个故事,我不是ؓ了得瑟,而是因ؓ有些人在微博上抨L是一个道貌岸然的只会谈概念讲道理的装逼犯。所以,我告诉大家我在聚矛_是怎么做的Q我公开写在q里Q你也可以向相关的同学去求证我说的是不是真的。也向你证明Q我可能是个装逼犯Q但l不是只会谈概念讲道理的装逼犯?/p>
被业务方逼得紧不要抱怨,你没有时间被逼得像牲口一样工作,q个时候,你需要的是暂停一下想一惻IZ么会像牲口一P而这正是让你变得聪明的机会?/p>
我ؓ你ȝ一下,
1Q你有没有去Review业务部门l你的这么多的需求,哪些是合理的Q哪些是不合理的。在AmazonQ开发工E师都会被教育拿到需求后一定要问——“ؓ什么要做?业务影响度有多大Q有多少用户受益Q”,回答不清q个问题Q没有数据的支持Q就不做。所以,产品l理要做很多数据挖拙和用戯研的工作Q而不是拍拍脑袋,听极数的用h怨就要开需求了?/p>
2Q品经理也要管理和教育的。你要告诉你的品经理:“你是一个好的品经理,因ؓ你不但对用户把握得很好,也会对Y件工艺把握得很好。你不但会开出外在的功能性需求,也同样会开出内在的让Y件系l更完善的非功能性需求。你不是在迁qP而是引导用户。你不会无限制地加功能,而是把握产品灵魂控制q简化功能。你会ؓ自己要做的和不做东西的感到同L自豪。”你要告诉你的品经理:“做一个半成品不如做好半年产品”(更多q样的观点请参看《Rework摘录和感惟뀋)
3Q做事情是要讲效率的。Amazon里喜Ƣ用一U叫T-Shirt Size Estimation的评估方法来优先做投入小产出大的“Happy Case”。关于什么是效率Q什么是T-Shirt Size EstimationQ你可以看看《加班与效率》一??/p>
4Q需求L会变化的Q不要抱怨需求变化太快。你应该抱怨的是ؓ什么我们没有把握好方向Q老变Q这个事像t球一P你要ȝ地方是球要ȝ地方Q而不是球现在的地斏V你要知道球要去哪里Q你q道球之前是怎么动的Q找Cq动轨迹后,你才知道球要d何方。如果你都不知道球要d何方Q那你就是一只无头苍蝇一P东一下西一下?/p>
当你忙得跟牲口一P你应该停下来Q问一下自己,自己成ؓ牲口的原因,是不是就是因己做事时候像q口一h考?
其它
最后,我在l阿里今q新入职的毕业生的“技塑h生”的分n中,我给他们布置??个HomeworkQ分享几个给大家Q?/p>
1Q重构或写一个模块,把他做成真正的ElegantU别?/p>
2Q与大家分n一或几篇技术文?Qƈ收获10-30个赞?/p>
3Q降低现有至?0%的重复工作或l护工作
4Q拒l或化一个需求(需要项目中所有的Stakeholders都同意)
部vq些作业的原因,是我希望新入行的同学们对自己的工作坚持高的标准,我知道你们会因ؓ骨感的现实而妥协,但是我希望你们就在现实中妥协了也要在内心中坚持可能高的标准,不要习惯成自Ӟ最后被C会q个大染~给潜移默化了。因Z臛_要对自己负责。对自己负责是Q用脚投,如果妥协得受不了了就d吧?/p>
芝兰生于IQ不以无不芻I君子修n养道Q不以穷困而改志!