公司有 CodeView 功能, 看到新同事的代码逻辑上没有什么问题,就是有几点小问题
1. 没有遵循 PEP8 代码风格
2. 有些功能可能用别的方法会更好的解决,避免了过多的代码量和逻辑判断
遵循 PEP8 这个还好弄,关于第 2 点应该如何说呢?
1. 没有遵循 PEP8 代码风格
2. 有些功能可能用别的方法会更好的解决,避免了过多的代码量和逻辑判断
遵循 PEP8 这个还好弄,关于第 2 点应该如何说呢?

2 asj Jan 6, 2016 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 都是好公司啊,我代码写的烂自己知道但是不知道咋改,也没人告诉我。。要是我,你说多了我还请你吃饭 |