|
此文章由 乱码 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 乱码 所有!转贴必须注明作者、出处和本声明,并保持内容完整
谢谢大家阿,没想到这么多的回复,昨天下班前发的帖子,晚上忙家里的事没来的急上网,现在一起回一下。
@netstat
他是consultant,我们开不了他的,现在换人都太晚了,不过下次我们开发,估计他再来的可能性很小了。
@da_wang
从来没用过code review的软件,从来都是人工作,我猜它软件能找出小问题,但结构性的大问题它可能就无能为力了,correct me if I'm wrong.
@uowzd01
what is "random name"? bob blah...?
@napolian
也没什么具体的流程,tfs要求checkin的时候,policy要求有code reviewer,我们一般找team的人来做。先brief一下task的要求(在PBI的description有写),然后比较一个文件的改动,并说明理由。
如果review满意改动,code就可以checkin,这时候实施者跟code reviewer共同承担code的责任,一般reviewer可能责任更多些,因为一般都是snr或更熟悉系统的人来做review.
@kr2000
code review跟他的薪水没关系,他怎么都能拿到钱, 即使我打他一顿他也能拿到钱
@变形金刚
consultant这个行业水很深,但整体素质要比一般公司的dev team水平高些,但不排除有些混混在里面,我觉得水平太凹了肯定混的也不舒服。
@萝卜
他的小问题例如代码级别的我都不挑,不然没完没了,对他我只捡架构性的错误。
@slateblue && jn1216
嗯,我个人的观点,这是code review的目的之一.
@bffbffbff && 收路费 && righttang && greed && o2h2o
我个人觉得平时做review是挺注意措词,好话先说,坏话都是跟在but后面,而且是建议性的,但昨天他上来就给我看一个根本不需要的store proc,让我好话都没地方说,直接就来建议了,可能的确是有这个问题。
不过他是个愤青,平时正常说话都能翻脸那种(不过不是跟我),水平也是属于left outer join,inetmgr不知道是啥的....我觉得即使夸的他跟花一样,他也真不一定能领我的情。
@linkspeed
又让你失望了,我的确不是什么tl,我喜欢管闲事,让别人比较烦
@fly050505
谢谢你这么详尽的建议阿!!
我觉得你跟我性格差不多,都是比较平和的那种,跟人交往不带什么进攻性。
不过business付我钱来deliver有质量的产品,我的确不能随便让烂code checkin进去,尤其是架构性错误的那种,否则以后很难维护。
他这次最严重的错误是很多database的chatty talk,如果有1万条记录,他的approach就要跟query database 1万次,真的很不能接受。
我们有自己的coding standard,没什么特殊的,都是大路的要求,这种错误是一个普通的developer都不能犯的,更不要说是consultant.
其实我早就不把他当consultant了,就当一个jnr developer来用,让他写code的时间,我写10个都出来了,但这都不是主要问题。
最重要的他干活心不在焉,我跟其他snr consultant/BA往来的技术email/要求都是抄送他的,需要他注意的地方我都把他的名字highlight一下,结果他错误照犯...
另一个问题是他对修改现有的code很没有信心,动一个class都心惊胆颤,生怕碰到其他不该碰得,我说你不用害怕,花些时间做调查,看看其他地方是不是还用这个class,如果不用,你可以大胆的改动...
现在vs的工具也很发达,如果一旦break什么东西,肯定可以fix好的,整个solution在local上就是自己的,要有信心来操纵,他恰恰很缺乏这种信心,这个也很要命。
在客户这边干活,就少上些linkedin的那类东西,即使上,也没关系,不要瞎吹,什么mentoring jnr,tech vp...啥的,当大家都不懂google呢?
最后一个他没有bigger picture,也不想有,一些有关联的东西他连看都不看,这也是导致他犯错的直接原因之一.
我们的结构决定了做code review主要是来保证产品质量,提高可能有,但很少。
私人恩怨我的确不怎么在乎,对有些人,我不愿意去social,但对另外些人,我更愿意表现得友好些,足迹有我几个原来的同事,我做事什么风格他们很清楚。 |
评分
-
查看全部评分
|