1
taozle 2016-01-06 12:21:26 +08:00
直接说啊
|
2
asj 2016-01-06 12:26:02 +08:00 3
code review 应该关注代码风格统一和知识分享,在这个场合少提议重新设计。应该关注代码做了什么,而不是谁写了这段代码。否则这种建议很容易被写代码的人视作对他的批评,最终演变成互撕,或者消极参与。
对于优化的建议,不妨换个思路。不是建议“他的”代码应该怎样,而是分享“我觉得”更好的设计知识。下次 reviewer 或者结对的时候给他 show 你的方法。如果真的有先进性,他自然会借鉴。 |
3
bobuick 2016-01-06 12:29:36 +08:00
lz 我也有这样的问题, 可是我的问题是如何给老同事说, 日了狗了, 用的方式, 写的代码那么难看就没想到去改一下
|
4
jiongxiaobu 2016-01-06 12:56:49 +08:00 via Android
直接说啊
|
5
k9982874 2016-01-06 12:58:59 +08:00
你是 review 的负责人么?监督代码优化是你的职责么?
如果是,不用多想这是你的工作。如果不是给自己找点事干吧,太闲了。 |
6
GNiux 2016-01-06 12:59:39 +08:00 via iPhone
2 楼正点。赞
|
7
clino 2016-01-06 13:10:11 +08:00 via Android
不明白为什么要委婉 工程师不是应该直接了当的讨论技术问题吗
|
9
luoway 2016-01-06 13:21:21 +08:00
如果对方用文字记下来了,说明他采纳了,下次发现同样的问题直接说就好。
如果没有用文字记下来,那就说明自己还没有说服对方,下次发现同样的问题还得重试。 推而广之,当面说是头脑风暴,文字交流才是技术分享。 |
10
a0000 2016-01-06 13:35:12 +08:00 via Android
直接说比较好
|
11
clino 2016-01-06 13:38:10 +08:00
@GNiux 我们做 code review 的时候什么都可以说啊 包括风格 效率这些
当然不是每个建议都会被采纳 不过明显好的做法一般都会采用的 |
13
raincious 2016-01-06 13:39:56 +08:00
轻轻的走过去,拍他的肩膀,温柔的说:
小 X ,: 1 、如果你以后写代码遵守 PEP8 规则的话,我就请你吃烧烤。 2 、如果你以后多做做设计而不是用 if 解决问题的话,我就请你吃烧烤。 |
16
ShadowFiend OP @clino 因为有一次在 review 时写了一些建议,但是在后面的时候对方没有去修改,所以不知道是否再去写一些建议
例子: django model date_created = models.DateTimeField() 我建议可以这样 date_created = models.DateTimeField(auto_now_add=True) 说明了下,发现对方没有采纳 |
17
ShadowFiend OP @bobuick 哈哈 我是想更好的同事相处,所以了解下如何最好
|
18
ShadowFiend OP @k9982874 算是负责人,那如果功能上没有问题呢,这时候的建议是否有更好的表达方式
|
19
shibo501c 2016-01-06 14:03:45 +08:00
用 lint
|
20
clino 2016-01-06 14:23:26 +08:00
@ShadowFiend code review 除了写下来,最好当面或者电话沟通说一遍
我们用 gerrit,一般来说 patch 都是别人看过没问题以后 merge 的,有时候会有改过很多次如 10 次以上才 merge 的情况 |
21
paw 2016-01-06 16:39:48 +08:00
制定公司代码规范。。。
|
22
Lpl 2016-01-06 20:51:12 +08:00 via Android
要是我肯定很愿意让你说啊。。。有 code review 都是好公司啊,我代码写的烂自己知道但是不知道咋改,也没人告诉我。。要是我,你说多了我还请你吃饭
|