这是一个创建于 1701 天前的主题，其中的信息可能已经有所发展或是发生改变。
虽然用只有自己的代码不经过 review 也能上线才能独挡一面来安慰自己，但是仍然对同事拒绝 review 代码感到不可理解
 |
1
qwefdrt 2020-03-24 23:51:49 +08:00  2
个人认为 review 不光是检验代码质量，因为 review 了不代表就提升了代码质量。
更多的是互相交流对齐，共同进步的工程，利远远大于弊。 |
 |
2
renmu 2020-03-25 00:38:46 +08:00 via Android 27
当你只有十行代码的时候，review 的评论可能有几十条。
当你有五百行代码的时候，review 瞬间就被通过了 |
 |
3
123444a 2020-03-25 00:44:23 +08:00 via Android
PM 同意你晚几天上线没？晚一周少一百万实名用户的教训还少吗
|
 |
5
ericgui 2020-03-25 03:12:13 +08:00
没有 code review 绝对不行
但是，code review 搞不好也会成为一种阻碍生产力的工具 要平衡 |
 |
7
daozhihun 2020-03-25 04:23:19 +08:00 1
我觉得有 CR 这个流程是好的，但是还是看人，如果碰到不怎么 care 的人不去看那怎样的流程都没办法。
|
 |
8
zjsxwc 2020-03-25 06:46:59 +08:00 via Android
既然同事拒绝 review 代码了，那你们各自开个自己的代码目录项目，相互 rpc 通信调用，自己玩自己的吧，别用分支合并了，这样出问题背锅好解决，谁由于 bug 多影响产品也好定位。
|
 |
9
TTC 2020-03-25 07:14:54 +08:00
1. 合理排期, 安排好 Review 的时间花费.
2. 单次 PR, Commit 次数不宜太多. 3. 看不懂的代码建议 评论 或者 拒绝掉 PR. |
 |
10
vindurriel 2020-03-25 08:37:44 +08:00 via iPhone
当然是互相伤害啊 “认真” review 同事的代码
|
 |
11
sumarker 2020-03-25 08:43:30 +08:00
review 可能会避免一些比较低级的问题，或者一些隐藏的问题
当然把代码拿出来讲，一些逻辑的处理方式互相交流也是好的 |
 |
12
exploreXin 2020-03-25 09:04:55 +08:00 4
很多写程序的人其实是在用厨师，外卖员，裁缝还有卡车司机的思维在干着程序开发的工作，相比于编程，后面的这些职位更加适合他们，这是由于当前国内人才培养机制不完善，而企业又急需大量开发人员的问题导致的，当所有人都做对的事情，而你做错的时候，大家会纠正你，通化你，而当所有人都做错而只有你是内行，用专业手法做事情的时候，其他人照样会通化你，努力让你和他们一样不规范的做事。对于这种情况，网上的一句话很能说明问题，“要么忍，要么滚”，能忍下来，打一份工，赚钱养家，这无可厚非，如果忍不了，想要充分发挥自己更大的优势，做一点将来自己年老时可以拿出来怀念与炫耀的事情，那么就去找更好的同事，更好的团队吧，因为并不是所有的努力得到的回报率都是相同的，不同的环境，不同的团队，会相应增加，或者降低回报率，想要有所作为，与其生闷气，不如另谋高就来的更爽快。
|
 |
14
ocean1477 2020-03-25 10:47:50 +08:00
@exploreXin cannot agree more
|
 |
15
7654 2020-03-25 10:54:54 +08:00
测试岗位起来走两步？
|
 |
16
hbolive 2020-03-25 10:56:55 +08:00
到了 v2ex，发现所有人都觉得同事是猪，但可能你同事也在上这个论坛呢。。
|
 |
17
wangbenjun5 2020-03-25 11:00:25 +08:00
国内能认认真真 review 代码的公司屈指可数吧？
基本上都是以业务结果为导向，谁关心你代码质量，只要能跑不出故障就行了，你说 review 是图啥？自己为自己代码负责，甭想通过 review 解决潜在的 bug 而且很多代码都是涉及到具体的业务逻辑，你不了解这块功能也不好下结论，所以 review 啥呢？代码规范吗？ 最后，时间上也不允许，大家都忙的很 |
 |
18
optional 2020-03-25 11:02:31 +08:00
先上 sonar 之类的静态检查工具，粗滤一遍
|
|
19
optional 2020-03-25 11:04:27 +08:00
另外 cr 需要提前提交代码，不能快到 dealline 了提交一个巨大的 commit，这是不负责任的。
|
 |
20
wednesdayco 2020-03-25 11:06:48 +08:00
CR 很考验 reviewer 的能力的，学了几天 code 的人怕是 re 不动啊。
|
 |
21
Dongxilemo 2020-03-25 11:26:13 +08:00 via Android
这个时候就只有规范代码了…
|
 |
22
Elephant696 2020-03-25 11:52:28 +08:00 1
团队以前也研究过 review 代码，主要有几个问题比较难解决。
一、新业务开发中，review 代码就意味着你首先要熟悉这部分的业务，包括产品，接口等，产品还好说，接口就要看后端的文档是否完善了，指不定开发的时候有什么特殊的字段啥的，如果你不知道，那就没法理解前端处理的逻辑。但这无疑是增加了巨大的工作时间和精力，在业务为导向的我们目前根本没有时间去做这件事。 二、bugfix 中，review 代码会相对花费的精力和时间要少一点，但可能涉及到其他的一些库的 bug，或者用了什么组件的 bug，这你就要去查找文档之类的，也是很麻烦。 所以目前，review 主要是看代码风格和代码质量，至于业务逻辑实在没精力去搞 |
 |
23
chenliangngng 2020-03-25 12:00:11 +08:00 via Android
review 是有必要的，尤其是不稳定的团队和刚组建的团队，磨刀性质
|
 |
24
hantsy 2020-03-25 12:02:48 +08:00
1, Code Review 是相互交流的过程。提高代码质量，和交换一些实现方法。
2, 代码逻辑正确与否，主要是用测试代码来实现，分支 PR 跑 CI 服务器。 |
 |
25
nianyu 2020-03-25 20:34:57 +08:00
你去任何公司 review 代码其实都是走过场。这个道理还想不明白
|
 |
26
Noobs OP 六字诀早就烂熟于心了，把自己的职场困惑发出来讨论一下，免得钻了牛角尖还不自知吧。
code review 显而易见的好处就是加强团队沟通和代码 质量保证，实施起来的话问题其实就是谁也不想添加自己的工作量吧，各人自扫门前雪。可能比较好的解决方案是根据代码改动影响范围酌情 review 。要是重要改动都没人做靠谱的 review，那就没天理了，早点闪人吧，常在河边走哪有不湿鞋(发现自己很害怕出事故背锅啊…)。 说靠责任心的，感觉和期望当官的自觉清廉一样，只能当官的说给自己听。说工作忙没时间的，我理解也应该是少数时间忙到没时间 review 代码吧。 用工具做检测的话，其实算另外一种保证代码质量的手段吧，不知道 sonar 可不可以搞 c++ 跨多个文件的检测和到底有多强，用过 clangtidy，cppcheck 之类的，感觉有点弱 |
|
27
123444a 2020-03-26 01:33:53 +08:00 via Android
一起加入 linux kernel community
|
Select Language