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

我还可以，既可以学习学习大佬的代码，还能偶尔看看窒息操作。对自己挺好的

，

不喜欢，typo 太多了，看得心烦

可以摸鱼聊天，很好呀。

@timelessg 程序员会不会像文人一样文人相轻，大多数情况觉得别人写的代码都是

8 成都是

penta kill

帮同事 review
- 这写的什么垃圾？
- 啊？ for 遍历不知道用 steam ？
- 啊？什么勾把？ BeanUtil.copy 不就行了？为什么要 set ？
- 啊？代码这不是上删的代码嘛？
- 啊？什么鬼方法都不知道拆分嘛？
- 啊？什么垃圾代码？谁写的，原来是我一年前写的，那没事了

喜欢，我喜欢挑剔其他人

有种别人拉的屎自己再吃一遍的感觉

#8 @ppllss 那个.... 是 steam 还是 stream 啊 我不知道

自己两年前写的代码已经完全看不懂了，还看别人的。。。

看谁的都是 shit ，包括自己的

@ppllss 所以 for 循环要登录 steam 么……
stream ？还是 iterator ？

@Jihua 不，看到自己写的代码都是，然后改一遍又一遍，改完发现还是，然后看看别人开源的优秀代码净化下心灵

@Leonard review 不看 typo 问题吧，这种上静态代码检查？

喜欢，这样我就能喷开发了 （逃

只有互相监督、互相 review 代码，大家才能保持良好的编码风格和习惯。
大佬 review 别人代码，可以提前发现问题 规避线上事故
像我这样的彩笔 review 别人代码，就是抱着学习的心态， 学习别人的思路和设计方案。偶尔还能发现大佬的一些不小心的错误

我们之前是团队 review ，6 人以内一个团队，周期要尽可能短，比如一天一次，这样每个人的代码可能只需要 5-10 分钟就可以 review 完了。

我是觉得从别人代码里找到问题挺有成就感的，同时也可以从各个人的观点中获得更多思路。

给自己一条活路

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

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

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

挺喜欢的

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

看多了大多数是：

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

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

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

@vayci 卧槽忒真实了

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

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

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

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

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

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

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

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

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

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

code review 可以缓慢提升水平均值，同时绝对可以降低方差

@ppllss 啊~~~这！

刚入职的时候会读公司一些关键中间件，基础服务的代码和配置，比如消息 /定时任务相关的，了解它们做了什么。。。出问题时候方便排查。。当然也会读到大佬的代码而目瞪口呆

好代码可以看。垃圾代码能跑就行，谁爱看谁看

小 PR 可以 一下子几十个 除非是全新的，否则不看

都是业务垃圾代码，没人想看

@vayci 太真实了。。

作为 owner 不论多少还是要看的

看是看 但是不会说

这写的什么垃圾代码，看看 git 提交记录是谁写的。噢是我写的。

@nonwill 前面一大串还以为是外国人交锋，结果突然冒出截图才发现原来都是懂中文的。。。

自己几年前写的代码都不想看，更不要说是别人的代码了。。。

@redford42 5000 行的模块代码，各种工具函数混合业务代码，比论文难读多的了

@RainCats 那位乌克兰大哥中文应该也不错，但氛围都被 pr 主的多国英文给搞了......别说，中文都说不好英文也不行的真是多......

不算 review 吧 ，更像是看帖子 ，但有问题也会说

挑重点看

我狠起来连自己的代码都很少 review ，还给别人 review ？

看代码风格。风格恶臭的，3 行都看不下去。风格好的，看起来赏心悦目。

我也不喜欢 review 主要原因
1 、小公司，我们技术都一般通过 review 同事代码也学不到太多东西
2 、业务堆砌，你 review 给出了重构意见。重构之后，千年老代码本来跑的好好的，结果重构完之后出个问题算谁头上？
总结，没有任何好处。

对着自己拉的屎还能勉强进行，对着别人拉的屎。。。。

我们公司每一行代码都是要 review 的。我个人喜欢 review 也喜欢被 review 。

Review 代码只对代码不对人，每个人都是从 0 过来的，能帮助同事并提升代码质量是最终目的。当然了，自己能从别人的 review 的意见中学到东西也很开心。

我们还在招人，感兴趣的朋友可以加我聊一下 /t/834762

眼不见心不烦