作为程序员的你，喜欢帮同事 review 代码吗

[Jihua]

我有点讨厌 review 同事代码，想听听大家的想法。

[liian2019]

给自己一条活路

[lizon]

等你同事的代码上生产了，过了半年他跑路了，你接手了，然后半夜出问题了，领导要你起床马上修复并且上线，还要顺带热修数据，你就会后悔，这么 sb 的写法一眼就能看出问题，当初为什么没有 review 代码提前发现

review 能提前发现处理一些 sb 问题 sb 写法

[lizon]

@lizon 比同事先跑路?那没事了

[MegrezZhu]

挺喜欢的

[iovekkk]

review 同事代码，那肯定是非常不喜欢，毕竟会浪费自己时间，平时的任务排期也不会专门为这件事去预留时间
不过我们公司，review 代码，一般分两种
日常提交：因为硬性规定所有代码都需要同事 review ，一般都是看看代码规范，以及有没有一眼就能看出来的错误，如果提交后代码依然出了 bug ，review 代码的人是没有任何责任的
重要功能开发完毕：这个要拉个会议，整组人一起 review 的，这个也主要是 review 代码结构和核心逻辑，太细节的东西也不会去看

[wanguorui123]

看多了大多数是：💩⛰️

[yuhuan66666]

上个需求写完 上面要求 找同部门 review 代码 然后 大家一脸懵逼的看着我 讲了一个半小时没讲完 完全不知道 只能看出读写问题 具体为啥这么写 他们不了解业务完全不知道。
讲得我口干舌燥的，最后变成了 小黄鸭编程，他们是那群鸭子

[vayci]

看代码量。
少量代码：这写的不好，那可以优化
几十上百个变动：过

[ffw5b7]

@ppllss BeanUtils 有问题，转换类型不一致，预编译 /运行不一定会报错，各个包的不一样。从效率来说 get/set 最快。 嫌麻烦可以使用插件生成。

[ALVC666]

@vayci 卧槽忒真实了

[RedisMasterNode]

喜欢，而且部门应该鼓励做这个事情，例如按 review comment 量来予以奖励

[OldDriver8848]

你们竟然还有时间看别人的代码，自己代码写不完，每天干到 11 点

[janus77]

一般只看有 bug 的地方，别的地方不说话

[Chad0000]

你这个“帮”字用得不太恰当，一般是“迫于”：为了完成任务。

[redford42]

迫于改造老项目，硬着头皮看
边看还要做笔记：写尼玛代码，2000 行的函数写论文吧你

[dingdong]

团队有 review 代码的氛围，那还是相当享受的

[nonwill]

最近刚把一高手大虾给杠爆了：
https://github.com/goldendict/goldendict/pull/1447

[YuTengjing]

我还是蛮愿意的，不 review 的话，一方面不知道他们负责的那块业务大概是怎么实现的，另一方面都是写一个仓库的代码，它要是写的不规范，自己写那块逻辑也难受，另外还可以促进彼此编码能力提高。

[YuTengjing]

你不 review 同事代码帮他指出问题，大概率以后还会发生经常碰到同样的问题。

[nanjoyoshino]

还行，有 bug 了会说，别的基本不吭声，好的地方算是学到了，不好的地方当没看见了