论坛首页 综合技术论坛

说说Code Review

浏览 19683 次
精华帖 (4) :: 良好帖 (4) :: 新手帖 (0) :: 隐藏帖 (3)
作者 正文
   发表时间:2011-06-26  
刚好看到一篇文章写的不错:http://www.javacodegeeks.com/2011/06/not-doing-code-reviews-whats-your.html

善于利用已有的工具,尽量采取"轻量级"的code review ,,etc…………
0 请登录后投票
   发表时间:2011-06-27  
如果我说的悲观的看法,不知道有没有人同意。
code review实际上无法进行。进行了也会流于形式。
真正的代码专家,代码几乎无须review。因为他的代码,始终是良好的风格,出错率很低,根本无须去review。review,对他们是个额外的负担。
而一些代码风格不良的人,仅仅是通过review,并不能让他们改正编码习惯,过一段时间就会打回原形。
真正需要改变的,不是code的风格,而是提高架构设计的水平。
代码风格不良,通常都体现在类的设计不良上。
detail design review,才是真正需要提高的重点。如果代码已经写好,设计的缺陷已经是事实,做code review又有何用?难道重头开始重做?没有多少Pm,敢承担这样的责任,最后只能走走形式,不了了之。
只有从detail design review抓起,提高硬实力,才能真正改变代码的质量。
而这个提高过程,需要的时间至少几个项目的实践锻炼。没有多少公司愿意等待,即使愿意,就软件业的实际状况看,也不是每个人都能达到要求。
所以,悲观看法,code review没用。差的还是差,好的还是好,最多,有少部分差的能渐渐变好,也不是短期能等得到的。
0 请登录后投票
   发表时间:2011-06-27  
CodeReview不但可以让代码变得规范,也有利于开发人员的成长,但是要做好确实比较困难,需要时间。
0 请登录后投票
   发表时间:2011-06-27  
wandou 写道
如果我说的悲观的看法,不知道有没有人同意。
code review实际上无法进行。进行了也会流于形式。
真正的代码专家,代码几乎无须review。因为他的代码,始终是良好的风格,出错率很低,根本无须去review。review,对他们是个额外的负担。
而一些代码风格不良的人,仅仅是通过review,并不能让他们改正编码习惯,过一段时间就会打回原形。
真正需要改变的,不是code的风格,而是提高架构设计的水平。
代码风格不良,通常都体现在类的设计不良上。
detail design review,才是真正需要提高的重点。如果代码已经写好,设计的缺陷已经是事实,做code review又有何用?难道重头开始重做?没有多少Pm,敢承担这样的责任,最后只能走走形式,不了了之。
只有从detail design review抓起,提高硬实力,才能真正改变代码的质量。
而这个提高过程,需要的时间至少几个项目的实践锻炼。没有多少公司愿意等待,即使愿意,就软件业的实际状况看,也不是每个人都能达到要求。
所以,悲观看法,code review没用。差的还是差,好的还是好,最多,有少部分差的能渐渐变好,也不是短期能等得到的。

走极端了不是。
引用
而一些代码风格不良的人,仅仅是通过review,并不能让他们改正编码习惯,过一段时间就会打回原形。

悲观了,习惯是可以改的,至少大部分人是可以改的。
引用
detail design review,才是真正需要提高的重点。如果代码已经写好,设计的缺陷已经是事实,做code review又有何用?难道重头开始重做?没有多少Pm,敢承担这样的责任,最后只能走走形式,不了了之。
只有从detail design review抓起,提高硬实力,才能真正改变代码的质量。

design是应该抓的,但是并不意味着code review就应该放弃,两手抓,两手都要硬。
0 请登录后投票
   发表时间:2011-06-27  
我也是水瓶座的,我就非常重视代码的规范
水瓶和处女的性格的确是那样

但我觉得写代码,兴趣和逻辑能力占一些权重

有些人整洁不起来是逻辑不清晰
还有就是真正的热爱写代码,就会精雕细琢
不喜欢,没热情当然就会能将就,就将就
0 请登录后投票
   发表时间:2011-06-27  
hobitton 写道
wandou 写道
如果我说的悲观的看法,不知道有没有人同意。
code review实际上无法进行。进行了也会流于形式。
真正的代码专家,代码几乎无须review。因为他的代码,始终是良好的风格,出错率很低,根本无须去review。review,对他们是个额外的负担。
而一些代码风格不良的人,仅仅是通过review,并不能让他们改正编码习惯,过一段时间就会打回原形。
真正需要改变的,不是code的风格,而是提高架构设计的水平。
代码风格不良,通常都体现在类的设计不良上。
detail design review,才是真正需要提高的重点。如果代码已经写好,设计的缺陷已经是事实,做code review又有何用?难道重头开始重做?没有多少Pm,敢承担这样的责任,最后只能走走形式,不了了之。
只有从detail design review抓起,提高硬实力,才能真正改变代码的质量。
而这个提高过程,需要的时间至少几个项目的实践锻炼。没有多少公司愿意等待,即使愿意,就软件业的实际状况看,也不是每个人都能达到要求。
所以,悲观看法,code review没用。差的还是差,好的还是好,最多,有少部分差的能渐渐变好,也不是短期能等得到的。

走极端了不是。
引用
而一些代码风格不良的人,仅仅是通过review,并不能让他们改正编码习惯,过一段时间就会打回原形。

悲观了,习惯是可以改的,至少大部分人是可以改的。
引用
detail design review,才是真正需要提高的重点。如果代码已经写好,设计的缺陷已经是事实,做code review又有何用?难道重头开始重做?没有多少Pm,敢承担这样的责任,最后只能走走形式,不了了之。
只有从detail design review抓起,提高硬实力,才能真正改变代码的质量。

design是应该抓的,但是并不意味着code review就应该放弃,两手抓,两手都要硬。


不要回避问题。

如果类库的结构设计就有缺陷,code review之后,发现改动的工作量很大,几乎是重做,请问你们如何去做?
如果你们缺少能够设计类库的开发人员,招聘困难,而现有的大多数开发人员,无法满足要求,需要培训一年才能达到要求,少数设计能力较好的开发人员,又没有足够的时间去完成全部工作,你们又如何去做?

0 请登录后投票
   发表时间:2011-06-27  
wandou 写道
hobitton 写道
wandou 写道
如果我说的悲观的看法,不知道有没有人同意。
code review实际上无法进行。进行了也会流于形式。
真正的代码专家,代码几乎无须review。因为他的代码,始终是良好的风格,出错率很低,根本无须去review。review,对他们是个额外的负担。
而一些代码风格不良的人,仅仅是通过review,并不能让他们改正编码习惯,过一段时间就会打回原形。
真正需要改变的,不是code的风格,而是提高架构设计的水平。
代码风格不良,通常都体现在类的设计不良上。
detail design review,才是真正需要提高的重点。如果代码已经写好,设计的缺陷已经是事实,做code review又有何用?难道重头开始重做?没有多少Pm,敢承担这样的责任,最后只能走走形式,不了了之。
只有从detail design review抓起,提高硬实力,才能真正改变代码的质量。
而这个提高过程,需要的时间至少几个项目的实践锻炼。没有多少公司愿意等待,即使愿意,就软件业的实际状况看,也不是每个人都能达到要求。
所以,悲观看法,code review没用。差的还是差,好的还是好,最多,有少部分差的能渐渐变好,也不是短期能等得到的。

走极端了不是。
引用
而一些代码风格不良的人,仅仅是通过review,并不能让他们改正编码习惯,过一段时间就会打回原形。

悲观了,习惯是可以改的,至少大部分人是可以改的。
引用
detail design review,才是真正需要提高的重点。如果代码已经写好,设计的缺陷已经是事实,做code review又有何用?难道重头开始重做?没有多少Pm,敢承担这样的责任,最后只能走走形式,不了了之。
只有从detail design review抓起,提高硬实力,才能真正改变代码的质量。

design是应该抓的,但是并不意味着code review就应该放弃,两手抓,两手都要硬。


不要回避问题。

如果类库的结构设计就有缺陷,code review之后,发现改动的工作量很大,几乎是重做,请问你们如何去做?
如果你们缺少能够设计类库的开发人员,招聘困难,而现有的大多数开发人员,无法满足要求,需要培训一年才能达到要求,少数设计能力较好的开发人员,又没有足够的时间去完成全部工作,你们又如何去做?



你是两层意思,而我只回答了一个,你的意思是前期的design才是更重要的,如果前期的design都有问题了后续的review还有神马用处对不?所以我说的design和后续的review都非常重要,不是说谈review就放了design,这两个本身没有矛盾。

另外还有层意思是说如果review的时候发现前期的design很有问题,需要大量资源去修改,怎么办。。首先呢,code review和后续的refactor是两块东西,其实如果真出现你所描述的问题,其实换个角度想就很简单,你code review和refactor的目的是什么?最终目的不外乎保证项目能够拿到钱,同时后续的维护成本降低。依照这个思路衡量你refactor的成本是否值得就好了。je里面很多帖子都讨论过这个问题,我不过拾人牙慧。
0 请登录后投票
   发表时间:2011-06-27  
wandou 写道
如果我说的悲观的看法,不知道有没有人同意。
code review实际上无法进行。进行了也会流于形式。
真正的代码专家,代码几乎无须review。因为他的代码,始终是良好的风格,出错率很低,根本无须去review。review,对他们是个额外的负担。
而一些代码风格不良的人,仅仅是通过review,并不能让他们改正编码习惯,过一段时间就会打回原形。
真正需要改变的,不是code的风格,而是提高架构设计的水平。
代码风格不良,通常都体现在类的设计不良上。
detail design review,才是真正需要提高的重点。如果代码已经写好,设计的缺陷已经是事实,做code review又有何用?难道重头开始重做?没有多少Pm,敢承担这样的责任,最后只能走走形式,不了了之。
只有从detail design review抓起,提高硬实力,才能真正改变代码的质量。
而这个提高过程,需要的时间至少几个项目的实践锻炼。没有多少公司愿意等待,即使愿意,就软件业的实际状况看,也不是每个人都能达到要求。
所以,悲观看法,code review没用。差的还是差,好的还是好,最多,有少部分差的能渐渐变好,也不是短期能等得到的。


人都会犯错,几率问题,专家也是人
如果review都不能让代码风格不良的人改进错误,那么这个人KPI最后肯定很低
code review很有用,只是要看重视程度
0 请登录后投票
   发表时间:2011-06-27  
怎么感觉有些人更注重星座而不是code review呢?哈哈

个人感觉新人的代码都review一遍还是很必要的,因为看过某些代码是先查询一遍数据库存成arraylist,然后再判断是不是某种特殊情况,是的话再查询一遍把数据存成数组,当时真有种崩溃的感觉。但是这种错误是很容易发现和纠正的。
然后也是一个员工和团队融合的问题。
0 请登录后投票
   发表时间:2011-06-27  
wandou 写道
如果我说的悲观的看法,不知道有没有人同意。
code review实际上无法进行。进行了也会流于形式。
真正的代码专家,代码几乎无须review。因为他的代码,始终是良好的风格,出错率很低,根本无须去review。review,对他们是个额外的负担。
而一些代码风格不良的人,仅仅是通过review,并不能让他们改正编码习惯,过一段时间就会打回原形。
真正需要改变的,不是code的风格,而是提高架构设计的水平。
代码风格不良,通常都体现在类的设计不良上。
detail design review,才是真正需要提高的重点。如果代码已经写好,设计的缺陷已经是事实,做code review又有何用?难道重头开始重做?没有多少Pm,敢承担这样的责任,最后只能走走形式,不了了之。
只有从detail design review抓起,提高硬实力,才能真正改变代码的质量。
而这个提高过程,需要的时间至少几个项目的实践锻炼。没有多少公司愿意等待,即使愿意,就软件业的实际状况看,也不是每个人都能达到要求。
所以,悲观看法,code review没用。差的还是差,好的还是好,最多,有少部分差的能渐渐变好,也不是短期能等得到的。


如果我替你重新总结一下,加一点我的看法,就是这样的:
如果需求有偏差,架构就可能坍塌
如果架构有倾斜,设计就很难支撑
如果设计已扭曲,编码就会混乱
如果编码逻辑混乱了,Code Review也不过是隔靴搔痒
当然,我这么说可能有些牵强,因为需求上模棱两可,不代表架构和设计就不清晰、优雅,一个是业务上的,一个是技术上的,两条线。但编码实现确实和需求(业务逻辑)直接相关。

就如同建一座大厦,需求是地基,架构是骨架,Coding是一种砌砖工艺。
我们必须保证在源头上的正确性,末端的Code Review才可能真正有效,比如产品开发到2.0版本了,已经接受了市场的检验,那么这时候,花精力在Code Review,回报可能会比较大。
我以前某些项目对Code Review的放弃,一个是因为团队现状,另外一个是因为需求一直不稳定(创业型项目)。

程序员的代码优雅、整洁性,别人是很难教出来的,除非他自己认识到重要性,就如同一个人的穿着打扮,只有自己觉得:有风度的男人应该有优雅外表和举止,这时候他的穿衣水平才能真正开始提高。

我记得自己的代码风格,是从看Jive Forum2.0和JDK1.4源码开始的,当你接触到的都是干净、整洁的代码,自然会拒接肮脏的东西。








0 请登录后投票
论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics