同事写的code很乱，需要指出来吗？

取决于你的目标。

* 你需要指出他错误的credit吗？如果需要，礼貌指出。
* 你希望提高组里代码质量 / 你跟这人还算熟想帮帮忙 / 这人需要好的PR来promo 《- offline sync，如果可以让manager/tech lead知道一下。或者看这个人下一次PR revision有没有写based on offline sync with you 如果没写，下次考虑直接留字面PR
* 如果就是不想背锅： 有别人也是owner吗？你提点小意见，然后不LGTM或者多tag几个其他的人问opinion？

我一般逻辑上没问题会approve，然后到处comment。

楼主说的几点我会直接问。
1. 我们的代码库中已经有xxx了，在保持代码统一性的目标下我希望和他们尽可能有差不多的结构，但是有任何我没考虑到的地方不能让我们也用同样的方式实现吗？
2. 不clean，命名不好，都是一种很主观的说法。其中一部分能客观分析并且指出标准的，一般都能在code style里找到，直接引用说我们根据code style可以这么写。
尤其是命名，很多组没有命名约定，更多的是凭经验，甚至需要很多领域知识。更有甚者好几个人给我cr，我根据A的说法把名字改成了A，B说不好要B，说服A改成B，C说C更好。我死了。
可以的话就自己写个文档分享，说自己命名一般是怎么考虑的，然后让大家指正完善，最后全组用一套方法论，有了共识才方便。

要指出来，最好带上评论的依据和来源，可以是style guide、内部document、general rule比如design pattern等等，最好严格把关，否则后面出了问题你作为reviewer也有责任

你想过没有你告诉他代码质量不高他会怎么想？
有帮他的时间你都自己写完了。。。何必纠结呢，自己学到东西有机会了想办法换公司换队友得了。
你没有话语权的时候说啥都没用。

pubu666 发表于 2021-12-03 15:13:31
我觉得需要指出来，否则这种PR被别人看到多了会觉得你们两个都是菜b……

附议！一对菜逼。

大的pr 你可以要求他弄个review meeting，这样沟通起来效率更高，也不会因为comments 也太多，被对方误会你针对她

“总体上完全不搭但是能跑”

不是我吧 哈哈哈哈

ddmmtx 发表于 2021-12-03 23:39:04
你想过没有你告诉他代码质量不高他会怎么想？
有帮他的时间你都自己写完了。。。何必纠结呢，自己学到东西有机会了想办法换公司换队友得了。
你没有话语权的时候说啥都没用。

我本来也是这么想的，所以才会提出这个问题。特别是“我有时间教他还不如自己写了”这点深有同感。但是事实是工作中已经assign给别人的任务，人家写好了你不签收，自己重写一套是不可能的，比直接指出错误还差，要写也只能手把手教他写，更累。
昨天看了评论，我最后还是委婉指出我的疑虑，给了理由。改不改看他吧。他说觉得原本更好的话我也就approve了反正我该说的说了。

摸鱼啊兄弟

匿名用户 发表于 2021-12-04 08:32:43
我本来也是这么想的，所以才会提出这个问题。特别是“我有时间教他还不如自己写了”这点深有同感。但是事实是工作中已经assign给别人的任务，人家写好了你不签收，自己重写一套是不可能的，比直接指出错误还差

唉，我也是真的屡次失望过后，还碰上一个全是理由的人才这么说。
不过具体情况还是具体分析吧，能学到些东西总归是好的。