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

[Jihua]

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

[deplivesb]

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

[timelessg]

💩🙅，🎂🉑

[Leonard]

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

[jones2000]

可以摸鱼聊天，很好呀。

[Jihua]

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

[wolfie]

8 成都是 💩

[wakaka]

penta kill

[ppllss]

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

[golangLover]

喜欢，我喜欢挑剔其他人

[tabris17]

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

[cydysm]

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

[yazinnnn]

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

[leeyuzhe]

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

[jinliming2]

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

[Pastsong]

[littlewing]

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

[iyaozhen]

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

[iyaozhen]

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

[SkipToMyLou]

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

[libook]

我们之前是团队 review ，6 人以内一个团队，周期要尽可能短，比如一天一次，这样每个人的代码可能只需要 5-10 分钟就可以 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 了会说，别的基本不吭声，好的地方算是学到了，不好的地方当没看见了

[dayeye2006199]

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

[sjzjams]

@ppllss 啊~~~这！

[tqccc]

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

[zw1one]

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

[SD10]

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

[lawsiki]

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

[eijnix]

@vayci 太真实了。。

[pkwenda]

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

[hejw19970413]

看是看 但是不会说

[Renco]

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

[RainCats]

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

[tianzhiya]

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

[LabJo]

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

[nonwill]

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

[snickers]

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

[wangyzj]

挑重点看

[monospace]

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

[xuanbg]

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

[sorshion]

不喜欢，眼不见为净，说了，还怪你，屁事多

[Daiwf]

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

[Cloutain]

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

[yuezk]

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

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

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

[ideaspad]

眼不见心不烦