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