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