大部分公司应该都不会 code review 吧?

2021-01-04 09:55:15 +08:00
 polyang
以我所在的公司为例,平时项目周期已经很紧张了,根本没时间 code review 。

之前有个需求,从开发到联调再到 showcase,只给你一周的时间,这么短的时间,根本不会考虑什么 code review,只要能把功能实现就不错了,等到做完这个需求,还没等你缓过来,下一个需求就立马来了。
10987 次点击
所在节点    程序员
71 条回复
x66
2021-01-04 10:03:59 +08:00
我司有这个流程,每次提交代码都会有两位同事和一位 team leader review 。
但是很多时候也会沦为一种形式,因为同事写的业务你并不一定都清楚,也只能帮忙看看语法有没有明显的问题。
有些同事一次改动的代码过多,很难 review,
更多的时候你自己思路来了正在 coding,同事来找你 review,很难放下自己手里的工作去仔细看他的代码
ferock
2021-01-04 10:14:24 +08:00
楼上+1

参考鹅厂,有 code review,svn 递交必须审批,回顾问题落实到责任制。
那可能沦为形式化会弱一点。


制度和人之间,关键作用的还是人。
Mirage09
2021-01-04 10:17:36 +08:00
看情况吧,小的 CR 走个形式,大的 CR 还是比较严肃的
NexTooo
2021-01-04 10:17:37 +08:00
因为安排了 code review 的任务,也不会给你 review 的时间……
duduaba
2021-01-04 10:19:18 +08:00
code review 最大的阻塞就是很大的 commit,如果各个功能改动细分 commit,那 review 就很容易了。
jzmws
2021-01-04 10:26:45 +08:00
小公司根本没办法做到 CR ,有时候看看别人的代码最多看看代码是否符合规范,注释啥子是否描述正确,其他的真的不好再弄
jdhao
2021-01-04 10:29:07 +08:00
能跑就行。
gggxxxx
2021-01-04 10:30:24 +08:00
code review 只在 beta 时期有用。软件大部分都完工了,这个时候任何的代码修改,大家一起开会 review 看看,看看会不会因为个人修改代码考虑太少造成其他部分额外的风险。
我一直很不认同互相 review 代码风格啊,具体实现啊。毫无意义的事情。一方面,别人看你代码可能根本看不懂,每个人负责的模块和业务都不一样,草草看看也不实际测试,然后提交一个已阅标记........给自己一种感觉仿佛好像自己是美帝互联网大厂一员.....
另一方面代码风格其实根本不重要,只要能正确运行的代码就是好代码。我曾见过真正美帝互联网巨头公司的员工代码,每个人都是风格各异性格突出,有些人就喜欢 tab 空 2 个 space 呢.....
xuboying
2021-01-04 10:37:39 +08:00
@gggxxxx #8 代码风格不是项目一开始就定好了么,机器检查,项目风格都定不下来不是技术负责人压不住小弟么。要么就是没有负责人。。。
chiu
2021-01-04 10:37:44 +08:00
merge 代码的流程就有 review (自己 review/verify -> 机器人 review+机器人 build+机器人 test -> leader/owner review), 以上整个流程通过后, change 才会自动 merge 到对应 branch 上
saulshao
2021-01-04 10:40:33 +08:00
代码 review 的核心目标其实是尝试让其他人理解作者的代码。
挑刺永远都比做事容易,如果各位理解这点,就会明白 code review 其实是非常重要的,应该要切实执行。
gggxxxx
2021-01-04 10:51:01 +08:00
@xuboying 为啥老是开口就是权力话语这套说辞呢....压不住小弟....喷了。
一个团队里的成员有自己的个性其实是好事,在不重要的事情上做各种约束其实意义不大。想想看,团队里每个人都穿格子衬衫开发效率就会提高么?
xuboying
2021-01-04 10:54:31 +08:00
@gggxxxx #12 只是一份工作而已,不值得展示个性。没人在意
Lemeng
2021-01-04 10:55:18 +08:00
没有绝对的,重视程度有大不同
ericcode
2021-01-04 10:55:25 +08:00
来这家公司 3 年了,一直坚持做 review,很有用,但是真的很费时间
b1ackjack
2021-01-04 10:56:43 +08:00
之前小公司 sonar 和人工 cr 都有,来了这二线啥都没了
hantsy
2021-01-04 10:58:45 +08:00
@chiu 这个流程差不多可以。

我现在只要参与的项目 100%需要 CR 。主要创建的 PR 在进行。

进行 Code Review 之前,必须保证(这些都是由 CI 完成):
1,所有代码通过测试
2,测试 Coverage 报告(指标认可, 测试不到位,添加测试)
3,代码质量检测工具报告达标(如果引入新的 Bad Smell 代码等,需要重构清除)(现在智能化的检测工具,借助大数据,通过海量分析,可以检测很多代码质量的问题,及预测运行时产生的动态问题,不仅仅是命名规范等的问题)

这之后才是人工 Code Review,加入一些修正意见
4,Code Review,进行重构

还是重申我的观点,不写测试,做 CR,CI 都会成为形式主义。
tkl
2021-01-04 11:07:40 +08:00
1L + 10L

sonarqube
channingcheng
2021-01-04 11:19:59 +08:00
@saulshao 说的太对了, 遇到一个总挑别人的人,什么都要按照他的想法来实现,是时候真不想搭理这人
channingcheng
2021-01-04 11:21:36 +08:00
@hantsy 有个问题,cr 后重构,那测试不就要重新测了?确认改那么多东西没有问题吗?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/741378

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX