静不下心 review 组里别人的代码怎么办

[xiandao7997]

稍微复杂一点的代码就不想看，于是对项目代码不熟悉，于是很多东西不知道，于是越来越..

[tongbufu]

让 Ai 干这种事

[casey8802]

一楼说的对，先让 gpt 帮你粗读一遍，简单理解。那部分不理解，再摘出来，单独详细问 gpt

[sumu]

所有不用做 cr 的人，都很喜欢 cr 这套方法论，也认为 cr 是技术团队必须的，google 的成功案例更是鼓舞人心。
但，我得说，cr 是反人性的，花自己的时间帮助别人且对方未必认可且付出没回报，你静不下心来就对了，能静得下的，也只是阶段性静，等清醒了，就不能了。
cr 是技术团队的政治正确，你无法公开反对，更是技术 leader pua 员工的工具。分享一个技能：参考 google 编程规范，认真做几次 cr ，仅针对编程规范问题提建议，不用理解代码逻辑，攒下几十个评论模板，后面 cr 换着用就行。只要是人写的代码，问题都是类似的，每次用个三五个，既能交差也不用花心思

[billzhuang]

在足够多的眼睛注视下，任何 bug 都无处遁形。

unit test 是双眼睛，code review 也是一双眼睛。

我比较喜欢 clone 人家 PR 的 branch ，在 ide 里看。

[momoguo]

review 前 心挺静的
review 后 血压高了

[nyxsonsleep]

review 代码是自我提高的一部分。训练自己对于代码的品味、能力的步骤。

从制度上说：
review 应该由项目责任人来做，并且作为合入前的必要条件，否则项目失控只是时间问题。有必要的情况下需要进行至少两轮 review 。
review 发起人应当按照负责人的要求进行必要的代码注释，说明（并非指每行进行注释）。按照我的认知来看，被 review 的人就应该说明自己的每一行代码的意图，如果被 review 人不能说明清楚自己的提交在干什么，代码本身都没看的必要。
review 发现的问题点数量进行统计，周期性进行评估。review 出的问题点多的人与被 review 问题少的人应该进行奖励，甚至是晋升的充分条件，以鼓励 review 的行为。
如果项目责任人需要 review 的 PR 过多，应该安排副责任人，或者说明项目组应当进行拆分，细分责任归属。

我个人还挺喜欢 review 的，但被 review 的人必须亲自来说明自己在做什么。经常感觉 review 的过程收获远大于自己写代码的收获。尤其是复杂的高难度的方案。