在给其他人 code review 时需要注意什么，怎样提建设性的意见？

[rihkddd]

最近正好看到一个文章： https://testing.googleblog.com/2019/11/code-health-respectful-reviews-useful.html，应该可以回答一部分你的问题。

[billtsui]

没有人喜欢听意见，能夸就夸，实在没得夸就说他代码格式很整齐

[xingheng]

第一条：先忍住不要骂，看完了再一并怼。

[elfive]

闭嘴或者最多：“嗯”、“对”、“是的”。
提了建议，就能保证不出问题了吗？出了问题那不就要找你解决了？

[elfive]

@elfive 或者是个小公司，老板在场的话就一些看似正确，但明知对方不会采纳的建议，这样能让老板觉得你还是在认真做事的。不过这么做有个前提是你自己有能力，免得对方出了问题，老板觉得你能搞定，然后交给你搞。

[namelosw]

Code review 最大的目的其实不是找问题。
首先是让分歧能早统一，如果不 review 可能一个月之后才发现，那时候就晚了，想改只能重写了，如果第二天就发现所有事情都来得及。
其次团队互相分享代码，能知道其他人在做什么，接手不至于从头猜。提升巴士系数。

所以最好每天都 Code review，不要攒着。
有新想法，或者发现对方代码做得和自己的代码放一起会有问题这样可以提早发现，提早讨论解决。
不懂对方在做什么也可以让对方解释下，自己觉得别人可能不知道也可以快速解释下。
Code review 的时候可以讨论小问题，风格之类的，但是观点僵持不下，重要的话开会讨论，不重要的话就投票或者找个人让他选就行了。或者干脆再不重要就不用统一。
当然还有写安全问题，设计的问题也要捕捉提出来。

而且不一定提建设性意见，有可能是你发现一个问题，别人没注意，但是你也不知道怎么解决，说出来大家聊聊，不然可能后面就是坑。

最后，当然，政治因素各家不同，自行拿捏。但是不要牺牲太多 Code review 本身的目的，不然还不如不搞。

[heyyyy]

不要好为人师

[pmispig]

除非这个问题会让整个挂掉的灾难问题要提，其他什么优化什么的少说。当然业务 BUG 也可以说