锁定老帖子 主题:说说Code Review
精华帖 (4) :: 良好帖 (4) :: 新手帖 (0) :: 隐藏帖 (3)
|
|
---|---|
作者 | 正文 |
发表时间:2011-06-26
刚好看到一篇文章写的不错:http://www.javacodegeeks.com/2011/06/not-doing-code-reviews-whats-your.html
善于利用已有的工具,尽量采取"轻量级"的code review ,,etc………… |
|
返回顶楼 | |
发表时间:2011-06-27
如果我说的悲观的看法,不知道有没有人同意。
code review实际上无法进行。进行了也会流于形式。 真正的代码专家,代码几乎无须review。因为他的代码,始终是良好的风格,出错率很低,根本无须去review。review,对他们是个额外的负担。 而一些代码风格不良的人,仅仅是通过review,并不能让他们改正编码习惯,过一段时间就会打回原形。 真正需要改变的,不是code的风格,而是提高架构设计的水平。 代码风格不良,通常都体现在类的设计不良上。 detail design review,才是真正需要提高的重点。如果代码已经写好,设计的缺陷已经是事实,做code review又有何用?难道重头开始重做?没有多少Pm,敢承担这样的责任,最后只能走走形式,不了了之。 只有从detail design review抓起,提高硬实力,才能真正改变代码的质量。 而这个提高过程,需要的时间至少几个项目的实践锻炼。没有多少公司愿意等待,即使愿意,就软件业的实际状况看,也不是每个人都能达到要求。 所以,悲观看法,code review没用。差的还是差,好的还是好,最多,有少部分差的能渐渐变好,也不是短期能等得到的。 |
|
返回顶楼 | |
发表时间:2011-06-27
CodeReview不但可以让代码变得规范,也有利于开发人员的成长,但是要做好确实比较困难,需要时间。
|
|
返回顶楼 | |
发表时间: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就应该放弃,两手抓,两手都要硬。 |
|
返回顶楼 | |
发表时间:2011-06-27
我也是水瓶座的,我就非常重视代码的规范
水瓶和处女的性格的确是那样 但我觉得写代码,兴趣和逻辑能力占一些权重 有些人整洁不起来是逻辑不清晰 还有就是真正的热爱写代码,就会精雕细琢 不喜欢,没热情当然就会能将就,就将就 |
|
返回顶楼 | |
发表时间: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之后,发现改动的工作量很大,几乎是重做,请问你们如何去做? 如果你们缺少能够设计类库的开发人员,招聘困难,而现有的大多数开发人员,无法满足要求,需要培训一年才能达到要求,少数设计能力较好的开发人员,又没有足够的时间去完成全部工作,你们又如何去做? |
|
返回顶楼 | |
发表时间: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里面很多帖子都讨论过这个问题,我不过拾人牙慧。 |
|
返回顶楼 | |
发表时间: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很有用,只是要看重视程度 |
|
返回顶楼 | |
发表时间:2011-06-27
怎么感觉有些人更注重星座而不是code review呢?哈哈
个人感觉新人的代码都review一遍还是很必要的,因为看过某些代码是先查询一遍数据库存成arraylist,然后再判断是不是某种特殊情况,是的话再查询一遍把数据存成数组,当时真有种崩溃的感觉。但是这种错误是很容易发现和纠正的。 然后也是一个员工和团队融合的问题。 |
|
返回顶楼 | |
发表时间: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源码开始的,当你接触到的都是干净、整洁的代码,自然会拒接肮脏的东西。 |
|
返回顶楼 | |