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

78 天前
 xiandao7997
稍微复杂一点的代码就不想看,于是对项目代码不熟悉,于是很多东西不知道,于是越来越..
1426 次点击
所在节点    问与答
6 条回复
tongbufu
78 天前
让 Ai 干这种事
casey8802
78 天前
一楼说的对,先让 gpt 帮你粗读一遍,简单理解。那部分不理解,再摘出来,单独详细问 gpt
sumu
78 天前
所有不用做 cr 的人,都很喜欢 cr 这套方法论,也认为 cr 是技术团队必须的,google 的成功案例更是鼓舞人心。
但,我得说,cr 是反人性的,花自己的时间帮助别人且对方未必认可且付出没回报,你静不下心来就对了,能静得下的,也只是阶段性静,等清醒了,就不能了。
cr 是技术团队的政治正确,你无法公开反对,更是技术 leader pua 员工的工具。分享一个技能:参考 google 编程规范,认真做几次 cr ,仅针对编程规范问题提建议,不用理解代码逻辑,攒下几十个评论模板,后面 cr 换着用就行。只要是人写的代码,问题都是类似的,每次用个三五个,既能交差也不用花心思
billzhuang
78 天前
在足够多的眼睛注视下,任何 bug 都无处遁形。

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

我比较喜欢 clone 人家 PR 的 branch ,在 ide 里看。
momoguo
77 天前
review 前 心挺静的
review 后 血压高了
nyxsonsleep
77 天前
review 代码是自我提高的一部分。训练自己对于代码的品味、能力的步骤。

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

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

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1070863

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX