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

[polyang]

以我所在的公司为例，平时项目周期已经很紧张了，根本没时间 code review 。

之前有个需求，从开发到联调再到 showcase，只给你一周的时间，这么短的时间，根本不会考虑什么 code review，只要能把功能实现就不错了，等到做完这个需求，还没等你缓过来，下一个需求就立马来了。

[x66]

我司有这个流程，每次提交代码都会有两位同事和一位 team leader review 。
但是很多时候也会沦为一种形式，因为同事写的业务你并不一定都清楚，也只能帮忙看看语法有没有明显的问题。
有些同事一次改动的代码过多，很难 review，
更多的时候你自己思路来了正在 coding，同事来找你 review，很难放下自己手里的工作去仔细看他的代码

[ferock]

楼上+1

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


制度和人之间，关键作用的还是人。

[Mirage09]

看情况吧，小的 CR 走个形式，大的 CR 还是比较严肃的

[NexTooo]

因为安排了 code review 的任务，也不会给你 review 的时间……

[duduaba]

code review 最大的阻塞就是很大的 commit，如果各个功能改动细分 commit，那 review 就很容易了。

[jzmws]

小公司根本没办法做到 CR ,有时候看看别人的代码最多看看代码是否符合规范，注释啥子是否描述正确，其他的真的不好再弄

[jdhao]

能跑就行。

[gggxxxx]

code review 只在 beta 时期有用。软件大部分都完工了，这个时候任何的代码修改，大家一起开会 review 看看，看看会不会因为个人修改代码考虑太少造成其他部分额外的风险。
我一直很不认同互相 review 代码风格啊，具体实现啊。毫无意义的事情。一方面，别人看你代码可能根本看不懂，每个人负责的模块和业务都不一样，草草看看也不实际测试，然后提交一个已阅标记........给自己一种感觉仿佛好像自己是美帝互联网大厂一员.....
另一方面代码风格其实根本不重要，只要能正确运行的代码就是好代码。我曾见过真正美帝互联网巨头公司的员工代码，每个人都是风格各异性格突出，有些人就喜欢 tab 空 2 个 space 呢.....

[xuboying]

@gggxxxx #8 代码风格不是项目一开始就定好了么，机器检查，项目风格都定不下来不是技术负责人压不住小弟么。要么就是没有负责人。。。

[chiu]

merge 代码的流程就有 review (自己 review/verify -> 机器人 review+机器人 build+机器人 test -> leader/owner review), 以上整个流程通过后, change 才会自动 merge 到对应 branch 上

[saulshao]

代码 review 的核心目标其实是尝试让其他人理解作者的代码。
挑刺永远都比做事容易，如果各位理解这点，就会明白 code review 其实是非常重要的，应该要切实执行。

[gggxxxx]

@xuboying 为啥老是开口就是权力话语这套说辞呢....压不住小弟....喷了。
一个团队里的成员有自己的个性其实是好事，在不重要的事情上做各种约束其实意义不大。想想看，团队里每个人都穿格子衬衫开发效率就会提高么？

[xuboying]

@gggxxxx #12 只是一份工作而已，不值得展示个性。没人在意

[Lemeng]

没有绝对的，重视程度有大不同

[ericcode]

来这家公司 3 年了，一直坚持做 review，很有用，但是真的很费时间

[b1ackjack]

之前小公司 sonar 和人工 cr 都有，来了这二线啥都没了

[hantsy]

@chiu 这个流程差不多可以。

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

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

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

还是重申我的观点，不写测试，做 CR，CI 都会成为形式主义。

[tkl]

1L + 10L

sonarqube

[channingcheng]

@saulshao 说的太对了， 遇到一个总挑别人的人，什么都要按照他的想法来实现，是时候真不想搭理这人

[channingcheng]

@hantsy 有个问题，cr 后重构，那测试不就要重新测了？确认改那么多东西没有问题吗？

[timedivision]

@gggxxxx 代码风格不定好，拉代码合并的时候，你 2 个 space，他一个 tab，你咋合并？难道自己不用格式化代码的吗

[Orenoid]

我司是有 CR 的，小型创业公司。
虽然谈不上形式化，但这个流程目前基本上已经变成，以 “应该按我的想法来实现” 为目的了。反正我现在也懒得争论了，对方怎么说我就怎么改……说到底还是话语权的问题，总该有个人让步。

[taowen]

code review 只是一种给反馈的手段而已。如果能尽早提出改进意见，没必要等到 code review 的时候来做。cr 时候提一堆意见去返工，浪费也挺大的。

[weer0026]

小公司表示只有在出现性能问题才会去 code review，新员工刚来也会看看，感觉大部分小公司都这样。

[IsaacYoung]

走形式

[mazyi]

垃圾人做辣鸡事，都是垃圾业务怎么来厉害的技术呢？

[Tonni]

我们公司会，Code Review + CI + Unit Testing，就是产品做的一塌糊涂

[saulshao]

@channingcheng
19# 我想表达的愿意其实是写代码的都不喜欢被人 Review，而参与 code review 的人都应该会喜欢。
所以逻辑上应该所有开发都参与 code review，这其实不是看有多少正面效果，而是增强互相之间的理解和沟通。

[hantsy]

@channingcheng 你从来没用过 CI 吗？？？

[hantsy]

@saulshao 这一点没错。更多应该 Peer to Peer Code Review，建立有效的沟通机制，而不是什么上级 Review 下面的人的代码。

[Cstone]

以前有，几个开发大家约个会议室一起认真评审代码，后来来了个领导，说减少工作时间开大会私下指定人 review 就行，代码评审也就成了走过场，再到现在没人 review 了

[leega0]

小公司就如你所说，开发周期根本没有 review 的时间给你，基本匆匆上线，各种改 bug 再测，循环往复。

[dayeye2006199]

我们公司只有三个人，也有 code review，有 CICD，有测试覆盖需求。这是一个企业文化的问题，对这点我们不妥协。

[lights]

刚毕业在传统 IT 行业的时候，没有 CR
后来跳槽做了两年多的互联网，配合 gitlab 做 CR 感觉很棒，偶尔能学到新姿势，也有利于增强代码维护性
再后来转行做游戏，虽然都是用 SVN，但第一家公司有做简陋的 CR，就是看一遍再用 QQ 或者口头和你沟通
现在依旧做游戏，没有 CR，虽然公司小，但毕竟有不同的人做同一个模块，偶尔会觉得比较蛋疼

[hantsy]

@dayeye2006199 这点没错，不用 CI，不写测试，所有 CR 都会是形式。

那种开会形式讨论，什么盯着纯代码提意见的，我也经历过，没任何实质性的作用。

具体 CR 实施一定要有的放矢，那么在 CI 中运行生成的测试报告，质量报告就是那个“的”，连一个最基本的讨论<<基点>>都没有的话，只能说大家公司都是在走过场，说白了，你们根本就不是在 CR 。

[channingcheng]

@saulshao 可惜我们这边都是只有业务 owner 才 code review，大头兵没有资格 code review

[channingcheng]

@hantsy CI 和重构是两个问题呀

[hantsy]

@channingcheng 你们那不是 CR 。只是普通的抽查工作情况（恰好拿代码挑刺说事），跟以前学校检查宿舍卫生一样，只有学工处干的事。

[hantsy]

@channingcheng 不知道怎么跟你解释你的问题。。。

[Perry]

Unit Testing, Code Review, Integration Testing, Accessibility Testing, Stress Testing, Chaos Testing, Load Testing 等等这些不通过估计进不了大公司的 Production 。

[llllboy]

就是个摆设

[DiverRD]

我一个版本改了 70 多个文件 组长看了 直接放弃 review

[Mirage09]

@Perry 我们组一堆 integration test 挂掉的 pipeline...

[USAA]

code review ？ 这玩意不应该自己来弄吗

[flowerains]

有时间才能互相 code review

比如我们公司如果是压着点做需求，能按时按量把需求作完上线就不错了

[hantsy]

@DiverRD 说明你们项目管理问题非常大。一个 PR 一般只包含一个 Feature，不应该太多，正常一般几个文件吧。如果是 Bug，可能可能几行代码，几个字符。

[hantsy]

@llllboy
@flowerains 跟时间没一点关系，这个和企业项目的工程文化有关。没写过测试，CR 就是摆设，没错。

[stirlingx]

@ferock 都 21 世纪了，鹅厂还用 svn

[onec]

纯纯的摆设

[dfzj]

在中型公司，项目分三个等级，只有 P1 等级才会 code review 。也就是是被定义为核心基础依赖的项目。
一般的业务项目，功能测试过了就发布了。

[irytu]

我们公司 code review 很多都喜欢鸡蛋挑骨头 要说意义么 几乎可以忽略不计

[polyang]

@dfzj 感觉这个有道理。

[pangleon]

楼上很多人没理解一点，CODE REVIEW 真正受益的是说人，他在给你介绍自己代码的时候也是重新梳理自己实现逻辑的流程，这个过程很能帮助他提高自己的思维甚至发现 BUG

[akira]

不做 cr 的产品 确实是能跑能上线，但是后面出问题你要花费数以倍记的时间。 单元测试也好，压力测试也好，代码评审也好，这些都是为了降低风险引入的，做了后续出问题的可能性小，不做后续出问题的可能性大。

出来混 迟早是要还的。

[yexiaoxing]

我们合规要求必须有人 review 才能 checkin 然后发 release 。

[lagoon]

我觉得，先是设计好，然后开发好，再然后才是测试好。

Code Review 肯定是好的，也是有用的。

但许多中小公司的情况是，设计没办法好，开发没办法好，然后领导指望抓测试，指望 Code Review，就能稳住质量。
本末倒置，只是安慰剂。

能不能设计好，取决于领导。能不能开发好，取决于领导。
领导不从自己身上找原因，寄希望于给开发人员找茬来稳住质量。



因此，大部分公司，不会 Code Review，或者只能进行走形式的 Code Review 。

[hugo54]

我所在的产品线的后端，都是 QA 来 CR 。 凡是非自主测试的代码，保准给你一行行 review 。

[vagranth]

我司不光有 review，而且还要求写测试 case 。
我曾经有一个大 patch 被要求拆分成 5 个 patch 慢慢 review 完的经历，要不是那个功能架构做的还可以，拆都拆不开。

[msg7086]

我们是强制 code review，除了其他开发以外，team leader 也要 review 一次，没问题了才能合并。

[Leee]

@dayeye2006199 你们在广州吗？还要人吗😂

[cwliang]

code review 很有必要，可以防止一些 anti-pattern 、性能冲击、维护性，虽然没时间看具体业务逻辑

[jorneyr]

理想很丰满，现实很骨感

[polyang]

@cwliang 我也觉得有必要，但首先是得给够时间，没时间的话，根本没办法做。

[leekafai]

sr
self review

[runliuv]

有个锤子

[LemonK]

@timedivision lint 和风格是两码事。比如有个前同事：他用他自己发明的标准划分为同类的变量，要求别人必须统一前后缀命名；多种语法都 ok 的逻辑，要求必须按他喜欢的那种写法；别人写 if 的地方他要求改成三目，别人写三目的地方他又要理论一下 if 更好。如果之前在这种代码孔乙己的身边工作，强调一下代码风格不重要还是有必要的。

[timedivision]

@LemonK 风格不是一个人制定的，不管怎么说，代码这种二进制的东西，实现某个功能逻辑有很多种方法，但一定是有一个最优解的，尽管说简单的 if 判断扯不上什么最优解，但对于项目本身来说，统一的风格一定是利于维护的

[LemonK]

@timedivision “写法一定有一个最优解”这句前提完全不认同。听起来就好像天下同一题目的作文只有一种标准写法一样。除了“一定不要这样写”的 Bad smell 共识之外，自由发挥的空间依然非常大。除非你只写 JAVA 。

[timedivision]

@LemonK 不要断章取义啊，我说的是实现某个功能逻辑的方法一定有一个最优解，另外你拿作文和代码相比，这两者根本没有可比性

[mlbjay]

项目组有个老同事，技术很强，但是 CR 后 总我“建议”我改一些“可有可无”的东西，我也不敢反对，改咯。

[saulshao]

@mlbjay 这其实就是代码 review 的价值。你可以尝试从中吸收对你有用的东西。