 |
1
x66 Jan 4, 2021  2
我司有这个流程，每次提交代码都会有两位同事和一位 team leader review 。
但是很多时候也会沦为一种形式，因为同事写的业务你并不一定都清楚，也只能帮忙看看语法有没有明显的问题。 有些同事一次改动的代码过多，很难 review， 更多的时候你自己思路来了正在 coding，同事来找你 review，很难放下自己手里的工作去仔细看他的代码 |
 |
2
ferock PRO 1
楼上+1
参考鹅厂，有 code review，svn 递交必须审批，回顾问题落实到责任制。 那可能沦为形式化会弱一点。 制度和人之间，关键作用的还是人。 |
 |
3
NVDA Jan 4, 2021 via iPhone
看情况吧，小的 CR 走个形式，大的 CR 还是比较严肃的
|
 |
4
NexTooo Jan 4, 2021 6
因为安排了 code review 的任务，也不会给你 review 的时间……
|
 |
5
duduaba Jan 4, 2021
code review 最大的阻塞就是很大的 commit，如果各个功能改动细分 commit，那 review 就很容易了。
|
 |
6
jzmws Jan 4, 2021
小公司根本没办法做到 CR ,有时候看看别人的代码最多看看代码是否符合规范，注释啥子是否描述正确，其他的真的不好再弄
|
 |
7
jdhao Jan 4, 2021
能跑就行。
|
 |
8
gggxxxx Jan 4, 2021 2
code review 只在 beta 时期有用。软件大部分都完工了，这个时候任何的代码修改，大家一起开会 review 看看，看看会不会因为个人修改代码考虑太少造成其他部分额外的风险。
我一直很不认同互相 review 代码风格啊，具体实现啊。毫无意义的事情。一方面，别人看你代码可能根本看不懂，每个人负责的模块和业务都不一样，草草看看也不实际测试，然后提交一个已阅标记........给自己一种感觉仿佛好像自己是美帝互联网大厂一员..... 另一方面代码风格其实根本不重要，只要能正确运行的代码就是好代码。我曾见过真正美帝互联网巨头公司的员工代码，每个人都是风格各异性格突出，有些人就喜欢 tab 空 2 个 space 呢..... |
 |
10
chiu Jan 4, 2021 1
merge 代码的流程就有 review (自己 review/verify -> 机器人 review+机器人 build+机器人 test -> leader/owner review), 以上整个流程通过后, change 才会自动 merge 到对应 branch 上
|
 |
11
saulshao Jan 4, 2021 3
代码 review 的核心目标其实是尝试让其他人理解作者的代码。
挑刺永远都比做事容易，如果各位理解这点，就会明白 code review 其实是非常重要的，应该要切实执行。 |
|
12
gggxxxx Jan 4, 2021
@xuboying 为啥老是开口就是权力话语这套说辞呢....压不住小弟....喷了。
一个团队里的成员有自己的个性其实是好事，在不重要的事情上做各种约束其实意义不大。想想看，团队里每个人都穿格子衬衫开发效率就会提高么？ |
 |
14
Lemeng Jan 4, 2021
没有绝对的，重视程度有大不同
|
 |
15
ericcode Jan 4, 2021
来这家公司 3 年了，一直坚持做 review，很有用，但是真的很费时间
|
 |
16
b1ackjack Jan 4, 2021
之前小公司 sonar 和人工 cr 都有，来了这二线啥都没了
|
 |
17
hantsy Jan 4, 2021
@chiu 这个流程差不多可以。
我现在只要参与的项目 100%需要 CR 。主要创建的 PR 在进行。 进行 Code Review 之前，必须保证（这些都是由 CI 完成）： 1，所有代码通过测试 2，测试 Coverage 报告（指标认可， 测试不到位，添加测试） 3，代码质量检测工具报告达标（如果引入新的 Bad Smell 代码等，需要重构清除）（现在智能化的检测工具，借助大数据，通过海量分析，可以检测很多代码质量的问题，及预测运行时产生的动态问题，不仅仅是命名规范等的问题） 这之后才是人工 Code Review，加入一些修正意见 4，Code Review，进行重构 还是重申我的观点，不写测试，做 CR，CI 都会成为形式主义。 |
 |
18
tkl Jan 4, 2021
1L + 10L
sonarqube |
 |
19
channingcheng Jan 4, 2021
@saulshao 说的太对了， 遇到一个总挑别人的人，什么都要按照他的想法来实现，是时候真不想搭理这人
|
|
20
channingcheng Jan 4, 2021
@hantsy 有个问题，cr 后重构，那测试不就要重新测了？确认改那么多东西没有问题吗？
|
 |
21
8888888888 Jan 4, 2021 1
@gggxxxx 代码风格不定好，拉代码合并的时候，你 2 个 space，他一个 tab，你咋合并？难道自己不用格式化代码的吗
|
 |
22
Orenoid Jan 4, 2021
我司是有 CR 的，小型创业公司。
虽然谈不上形式化，但这个流程目前基本上已经变成，以 “应该按我的想法来实现” 为目的了。反正我现在也懒得争论了，对方怎么说我就怎么改……说到底还是话语权的问题，总该有个人让步。 |
 |
23
taowen Jan 4, 2021
code review 只是一种给反馈的手段而已。如果能尽早提出改进意见，没必要等到 code review 的时候来做。cr 时候提一堆意见去返工，浪费也挺大的。
|
 |
24
weer0026 Jan 4, 2021
小公司表示只有在出现性能问题才会去 code review，新员工刚来也会看看，感觉大部分小公司都这样。
|
 |
25
IsaacYoung Jan 4, 2021
走形式
|
 |
26
bigdogbigpig PRO 垃圾人做辣鸡事，都是垃圾业务怎么来厉害的技术呢？
|
 |
27
Tonni Jan 4, 2021
我们公司会，Code Review + CI + Unit Testing，就是产品做的一塌糊涂
 |
|
28
saulshao Jan 4, 2021
@channingcheng
19# 我想表达的愿意其实是写代码的都不喜欢被人 Review，而参与 code review 的人都应该会喜欢。 所以逻辑上应该所有开发都参与 code review，这其实不是看有多少正面效果，而是增强互相之间的理解和沟通。 |
|
29
hantsy Jan 4, 2021
@channingcheng 你从来没用过 CI 吗？？？
|
|
30
hantsy Jan 4, 2021 1
@saulshao 这一点没错。更多应该 Peer to Peer Code Review，建立有效的沟通机制，而不是什么上级 Review 下面的人的代码。
|
 |
31
Cstone Jan 4, 2021
以前有，几个开发大家约个会议室一起认真评审代码，后来来了个领导，说减少工作时间开大会私下指定人 review 就行，代码评审也就成了走过场，再到现在没人 review 了
|
 |
32
leega0 Jan 4, 2021
小公司就如你所说，开发周期根本没有 review 的时间给你，基本匆匆上线，各种改 bug 再测，循环往复。
|
 |
33
dayeye2006199 Jan 4, 2021 4
我们公司只有三个人，也有 code review，有 CICD，有测试覆盖需求。这是一个企业文化的问题，对这点我们不妥协。
|
 |
34
lights Jan 4, 2021
刚毕业在传统 IT 行业的时候，没有 CR
后来跳槽做了两年多的互联网，配合 gitlab 做 CR 感觉很棒，偶尔能学到新姿势，也有利于增强代码维护性 再后来转行做游戏，虽然都是用 SVN，但第一家公司有做简陋的 CR，就是看一遍再用 QQ 或者口头和你沟通 现在依旧做游戏，没有 CR，虽然公司小，但毕竟有不同的人做同一个模块，偶尔会觉得比较蛋疼 |
|
35
hantsy Jan 4, 2021
@dayeye2006199 这点没错，不用 CI，不写测试，所有 CR 都会是形式。
那种开会形式讨论，什么盯着纯代码提意见的，我也经历过，没任何实质性的作用。 具体 CR 实施一定要有的放矢，那么在 CI 中运行生成的测试报告，质量报告就是那个“的”，连一个最基本的讨论<<基点>>都没有的话，只能说大家公司都是在走过场，说白了，你们根本就不是在 CR 。 |
|
36
channingcheng Jan 4, 2021
@saulshao 可惜我们这边都是只有业务 owner 才 code review，大头兵没有资格 code review
|
|
37
channingcheng Jan 4, 2021
@hantsy CI 和重构是两个问题呀
|
|
38
hantsy Jan 4, 2021
@channingcheng 你们那不是 CR 。只是普通的抽查工作情况（恰好拿代码挑刺说事），跟以前学校检查宿舍卫生一样，只有学工处干的事。
|
|
39
hantsy Jan 4, 2021
@channingcheng 不知道怎么跟你解释你的问题。。。
|
 |
40
Perry Jan 4, 2021 via iPhone
Unit Testing, Code Review, Integration Testing, Accessibility Testing, Stress Testing, Chaos Testing, Load Testing 等等这些不通过估计进不了大公司的 Production 。
|
 |
41
llllboy Jan 4, 2021
就是个摆设
|
 |
42
DiverRD Jan 4, 2021
我一个版本改了 70 多个文件 组长看了 直接放弃 review
|
 |
44
USAA Jan 4, 2021
code review ？ 这玩意不应该自己来弄吗
|
 |
45
flowerains Jan 4, 2021
有时间才能互相 code review
比如我们公司如果是压着点做需求，能按时按量把需求作完上线就不错了 |
|
46
hantsy Jan 4, 2021
@DiverRD 说明你们项目管理问题非常大。一个 PR 一般只包含一个 Feature，不应该太多，正常一般几个文件吧。如果是 Bug，可能可能几行代码，几个字符。
|
|
47
hantsy Jan 4, 2021
|
 |
49
onec Jan 4, 2021
纯纯的摆设
|
 |
50
dfzj Jan 4, 2021
在中型公司，项目分三个等级，只有 P1 等级才会 code review 。也就是是被定义为核心基础依赖的项目。
一般的业务项目，功能测试过了就发布了。 |
 |
51
irytu Jan 4, 2021
我们公司 code review 很多都喜欢鸡蛋挑骨头 要说意义么 几乎可以忽略不计
|
 |
53
pangleon Jan 4, 2021
楼上很多人没理解一点，CODE REVIEW 真正受益的是说人，他在给你介绍自己代码的时候也是重新梳理自己实现逻辑的流程，这个过程很能帮助他提高自己的思维甚至发现 BUG
|
 |
54
akira Jan 4, 2021
不做 cr 的产品 确实是能跑能上线，但是后面出问题你要花费数以倍记的时间。 单元测试也好，压力测试也好，代码评审也好，这些都是为了降低风险引入的，做了后续出问题的可能性小，不做后续出问题的可能性大。
出来混 迟早是要还的。 |
 |
55
yexiaoxing Jan 4, 2021 via iPhone
我们合规要求必须有人 review 才能 checkin 然后发 release 。
|
 |
56
lagoon Jan 4, 2021
我觉得，先是设计好，然后开发好，再然后才是测试好。
Code Review 肯定是好的，也是有用的。 但许多中小公司的情况是，设计没办法好，开发没办法好，然后领导指望抓测试，指望 Code Review，就能稳住质量。 本末倒置，只是安慰剂。 能不能设计好，取决于领导。能不能开发好，取决于领导。 领导不从自己身上找原因，寄希望于给开发人员找茬来稳住质量。 因此，大部分公司，不会 Code Review，或者只能进行走形式的 Code Review 。 |
 |
57
hugo54 Jan 4, 2021
我所在的产品线的后端，都是 QA 来 CR 。 凡是非自主测试的代码，保准给你一行行 review 。
|
 |
58
vagranth Jan 5, 2021 via Android
我司不光有 review，而且还要求写测试 case 。
我曾经有一个大 patch 被要求拆分成 5 个 patch 慢慢 review 完的经历，要不是那个功能架构做的还可以，拆都拆不开。 |
 |
59
msg7086 Jan 5, 2021 via Android
我们是强制 code review，除了其他开发以外，team leader 也要 review 一次，没问题了才能合并。
|
 |
60
Leee Jan 5, 2021 via Android
@dayeye2006199 你们在广州吗？还要人吗😂
|
 |
61
cwliang Jan 5, 2021
code review 很有必要，可以防止一些 anti-pattern 、性能冲击、维护性，虽然没时间看具体业务逻辑
|
 |
62
jorneyr Jan 5, 2021
理想很丰满，现实很骨感
|
 |
64
leekafai Jan 5, 2021
sr
self review |
 |
65
runliuv Jan 5, 2021
有个锤子
|
 |
66
LemonK Jan 5, 2021
@timedivision lint 和风格是两码事。比如有个前同事：他用他自己发明的标准划分为同类的变量，要求别人必须统一前后缀命名；多种语法都 ok 的逻辑，要求必须按他喜欢的那种写法；别人写 if 的地方他要求改成三目，别人写三目的地方他又要理论一下 if 更好。如果之前在这种代码孔乙己的身边工作，强调一下代码风格不重要还是有必要的。
|
|
67
8888888888 Jan 5, 2021
@LemonK 风格不是一个人制定的，不管怎么说，代码这种二进制的东西，实现某个功能逻辑有很多种方法，但一定是有一个最优解的，尽管说简单的 if 判断扯不上什么最优解，但对于项目本身来说，统一的风格一定是利于维护的
|
|
68
LemonK Jan 5, 2021
@timedivision “写法一定有一个最优解”这句前提完全不认同。听起来就好像天下同一题目的作文只有一种标准写法一样。除了“一定不要这样写”的 Bad smell 共识之外，自由发挥的空间依然非常大。除非你只写 JAVA 。
|
|
69
8888888888 Jan 5, 2021
@LemonK 不要断章取义啊，我说的是实现某个功能逻辑的方法一定有一个最优解，另外你拿作文和代码相比，这两者根本没有可比性
|
 |
70
mlbjay Jan 5, 2021
项目组有个老同事，技术很强，但是 CR 后 总我“建议”我改一些“可有可无”的东西，我也不敢反对，改咯。
|
Select Language