V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member Sign In
This topic created in 3772 days ago, the information mentioned may be changed or developed.
公司有 CodeView 功能, 看到新同事的代码逻辑上没有什么问题，就是有几点小问题
1. 没有遵循 PEP8 代码风格
2. 有些功能可能用别的方法会更好的解决，避免了过多的代码量和逻辑判断
遵循 PEP8 这个还好弄，关于第 2 点应该如何说呢？
1. 没有遵循 PEP8 代码风格
2. 有些功能可能用别的方法会更好的解决，避免了过多的代码量和逻辑判断
遵循 PEP8 这个还好弄，关于第 2 点应该如何说呢？
 |
1
taozle Jan 6, 2016
直接说啊
|
 |
2
asj Jan 6, 2016  3
code review 应该关注代码风格统一和知识分享，在这个场合少提议重新设计。应该关注代码做了什么，而不是谁写了这段代码。否则这种建议很容易被写代码的人视作对他的批评，最终演变成互撕，或者消极参与。
对于优化的建议，不妨换个思路。不是建议“他的”代码应该怎样，而是分享“我觉得”更好的设计知识。下次 reviewer 或者结对的时候给他 show 你的方法。如果真的有先进性，他自然会借鉴。 |
 |
3
bobuick Jan 6, 2016
lz 我也有这样的问题， 可是我的问题是如何给老同事说， 日了狗了， 用的方式， 写的代码那么难看就没想到去改一下
|
 |
4
jiongxiaobu Jan 6, 2016 via Android
直接说啊
|
 |
5
k9982874 Jan 6, 2016
你是 review 的负责人么？监督代码优化是你的职责么？
如果是，不用多想这是你的工作。如果不是给自己找点事干吧，太闲了。 |
 |
6
GNiux Jan 6, 2016 via iPhone
2 楼正点。赞
|
 |
7
clino Jan 6, 2016 via Android
不明白为什么要委婉 工程师不是应该直接了当的讨论技术问题吗
|
 |
9
luoway Jan 6, 2016
如果对方用文字记下来了，说明他采纳了，下次发现同样的问题直接说就好。
如果没有用文字记下来，那就说明自己还没有说服对方，下次发现同样的问题还得重试。 推而广之，当面说是头脑风暴，文字交流才是技术分享。 |
 |
10
a0000 Jan 6, 2016 via Android
直接说比较好
|
 |
13
raincious Jan 6, 2016
轻轻的走过去，拍他的肩膀，温柔的说：
小 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 Jan 6, 2016
用 lint
|
|
20
clino Jan 6, 2016
@ShadowFiend code review 除了写下来,最好当面或者电话沟通说一遍
我们用 gerrit,一般来说 patch 都是别人看过没问题以后 merge 的,有时候会有改过很多次如 10 次以上才 merge 的情况 |
 |
21
paw Jan 6, 2016
制定公司代码规范。。。
|
 |
22
Lpl Jan 6, 2016 via Android
要是我肯定很愿意让你说啊。。。有 code review 都是好公司啊，我代码写的烂自己知道但是不知道咋改，也没人告诉我。。要是我，你说多了我还请你吃饭
|
Select Language