发起个讨论，你们公司有 code review 吗？

zzzzzy · 2016-07-11T02:02:22Z

code review 好处很多，可以规范代码、传递知识和保证代码质量等，但是因为项目进度和其他因素，不一定保证 review 被有效执行。请教各路大神都是怎么做的？有没有啥套路、工具、方法之类的。

Review

Code

代码

请教

108 replies • 2016-07-12 17:57:17 +08:00

1 2

❮

❯

zhenjiachen

Jul 11, 2016

1

技术经理：什么是 code review ？

bigtan

Jul 11, 2016

2

完全不需要，自己写，自己用。

chousb

Jul 11, 2016

3

One on One Code Review.

lution

Jul 11, 2016

4

不同的组不一样吧，反正我们组是必须 review 的。公司层面应该到了一定规模的公司很难规定这个东西。

bytenoob

Jul 11, 2016

5

方便某个人离职后其他人迅速交接

tabris17

Jul 11, 2016

6

review by myself
功能都来不及赶， review 个毛线

repus911

Jul 11, 2016

7

自己搭了个 gitlab 上线开 mr 有权限合的人去 review

zzzzzy

OP

Jul 11, 2016

8

@chousb 结对编程前期成本很高吧，还要看团队人员构成，我们这一个老员工， 3 个新来的小鲜肉，怎么破？

zzzzzy

OP

Jul 11, 2016

9

@tabris17 业务需求频繁、赶项目，可能确实要 review self

mrwangrj

Jul 11, 2016

10

review 邮件是展示工作量的方式。。。

zzzzzy

OP

Jul 11, 2016

11

@zhenjiachen 哈哈

knightdf

Jul 11, 2016

12

自写自测自 review 自上线

zzzzzy

OP

Jul 11, 2016

13

@lution 基础的、功能性的组件确实要做 review ，请问你们怎么做的？

zzzzzy

OP

Jul 11, 2016

14

@Yc1992 你说的好像也有道理，哈哈

murmur

Jul 11, 2016

15

每个新人的第一个模块要 review 的
或者新系统的每个人的第一个模块
后面看造化了

lution

Jul 11, 2016

16

@zzzzzy 基本就是 7 楼说的那样

hxtheone

Jul 11, 2016

17

我们公司是所有的代码都要 review

zhouxuchen

Jul 11, 2016 via iPhone

18

刚进公司的时候负责人大概 review 了一个礼拜我的代码（当然到底有没有 review 我就不知道了）。后来一切就看一个人的命运和历史的进程了（

zvving

Jul 11, 2016

19

大家对 code reivew 好不重视啊。

我们是用 gitlab - merge request 做的， develop 分支不能直接提交代码，全走 MR ，自己不能 merge 自己发的 MR 。
好处就不说了。

Phariel

Jul 11, 2016 via iPhone

20

Atlassian 的 Stash ，还有 Gerrit 都很好用

aitaii

Jul 11, 2016

21

每周 4 下午有一个 code review 确实能规范公司的代码风格

jmc891205

Jul 11, 2016

22

我们用 code collaborator

不过别人憋了两礼拜的代码一口气传上来让 review 的时候。。真的觉得不想去看

quericy

Jul 11, 2016

1

23

产品比开发都多,还来得及 review?

sudoz

Jul 11, 2016

24

极个别的组有 review ，真的很少会审查代码，加班都来不及马丹的

clino

Jul 11, 2016

25

我们这里不自觉做 code review,做不好 code review 的工程师设计质量和代码质量都比较差

rekulas

Jul 11, 2016

26

500 强外企用的 gerrit 来 view view 要经手好多人最后的审核者还在国外流程有点慢

rekulas

Jul 11, 2016

27

而且审核的也很严格比如行尾多了一个空格。。。是过不了的

repus911

Jul 11, 2016

28

@jmc891205 没办法有时候会在例会上说今天我 review 代码 1 天嗯 1 天

odirus

Jul 11, 2016

29

加班赶进度都来不及，还啥子 view 哦， just make it work

公司人力资源多、钱多、注重技术，一般都会。

menc

Jul 11, 2016

30

one on one ，用 gerrit 来做 review 。

说不 review 的，都是没 review 过的， review 一下就知道了，注释， coding style 还有 bug ，问题茫茫多。

代码不仅是写给自己看的，在公司里也是写给别人看的， review 不止有挑 bug ，也有保证自己代码别人能读懂的关系在。 code review 不仅会找出 bug ，也会要求修改格式，添加注释以增加代码可读性。

在 V2 上看到有人推崇不写注释，要求代码自解释，来一个稍微大点的团队就知道，这根本就是狗屎。

imswing

Jul 11, 2016

31

技术经理：什么是 code review ？

DevineRapier

Jul 11, 2016

32

不知道什么才算 review ，我们这写好了提交个 diff ，过了就可以提交。

review 是，先提交，过后在一起回顾审核？

感觉我们是 preview...

cnly1987

Jul 11, 2016 via iPhone

33

人多就需要 review ，不然你敢 merge 其他人的分支吗

expkzb

Jul 11, 2016

34

@DevineRapier 提交 diff 在 phabricator 里就算 review 。感觉这样挺好的

monkeylyf

Jul 11, 2016

35

没有最后代码库简直臭气熏天

4everLoveU

Jul 11, 2016

36

RD 提测， QAreview

nullp

Jul 11, 2016

37

全靠自觉，，接收人骂爹

hemingway

Jul 11, 2016 via iPhone

38

有

gefranks

Jul 11, 2016

39

据说是有 review 的,也有 reviewer 的名字,但是仍然不工作或者 bug 百出

hahastudio

Jul 11, 2016

40

https://www.reviewboard.org/

kkzxak47

Jul 11, 2016 via Android

41

我们组加上负责人才 3 个人，名存实亡

sc3263

Jul 11, 2016

42

之前的项目组有。
svn 上新建 work 目录，上传原始代码，上传正式代码
->更新 redmine 上对应的案件，通知相关人员 review
->review 代码，有啥问题提一下，有啥 bug 修复一下，都在 redmine 上更新
->结束了上传到 trunk 目录，结束 redmine 上的案件
代码质量确实高，不管是代码风格、注释，还是业务逻辑。写的人可能只考虑当前模块当前需求， review 的人会考虑到系统整体。毕竟 reviewer 对整个系统的了解，比我们不知道高到哪里去了。至于耗时什么的，我是觉得，整套流程跑起来之后，其实也不会多花很多时间，毕竟这边在 review 的时候，那边可以继续做别的需求的开发。

qqzj

Jul 11, 2016

43

有，即使我改一行代码都有两个人来 review ，你得解释清楚为什么这么改，他们看得非常认真。有时还不止看改动，还把前面的代码也看下。顺便说下，他们都是工作 2 ， 30 年的人，有时我都不好意思。

czheo

Jul 11, 2016

44

有，两人 review 之后才能 merge 到 master branch

yangxiongwei

Jul 11, 2016

45

用 phabricator ，强制 review

easing

Jul 11, 2016

46

必须要有啊， code review 对质量的保证还是很有效果的

SourceMan

Jul 11, 2016

47

看造化吧，新功能都不够时间做

shenxian

Jul 11, 2016

48

木有

twoyuan

Jul 11, 2016

49

@zzzzzy 小鲜肉表示刚开始老员工 review 比较好，熟悉后谁有时间谁 review 吧

kimmykuang

Jul 11, 2016

50

gitlab 会发 commit 邮件，然后我偶尔会 review 下我们组的提交；每个项目版本提测前会组内 review

broadliyn

Jul 11, 2016

51

每次看到这类问题，我就想到那张图。
要 copy － paste ， good design 又不会给你加工资。
人生没有时间给你重构。

review 有个蛋用，功能都赶不及。

逃

young

Jul 11, 2016

52

都是形式

review 个蛋蛋

zzzvvvxxxd

Jul 11, 2016

53

要的，你可以前期自己 review
后期让实现功能的小鲜肉串讲一下，介绍一下代码的组织和设计的思路，你听一听就好了。

Ixizi

Jul 11, 2016

54

每次 commit 必须 review 。

所有的队友必须一起 review 。

Tonni

Jul 11, 2016

55

我们公司用的 GitHub Enterprise ，没个代码改动都要发送一个 Pull Request ，没个 Pull Request 必须要至少两个人 review 并且给予 👍 后才能 merge 到 master 里面去。

daochouwangu

Jul 11, 2016

56

用 facebook 的 phabricator 来做 code review

messense

Jul 11, 2016

57

Bitbucket PR + 自行开发的 CI 自动化测试、 Code Lint 自动化代码风格检查

lovedebug

Jul 11, 2016

58

每次提交修改前都要 review 吧~~
公司用的 perforce, 和 Idea 以及 JIRA 结合 review code 还不错

proudzhu

Jul 11, 2016

59

@messense 道理我都懂，流程这么正规，为啥文件名这么随便。。。

flydogs

Jul 11, 2016

60

有 review 率，有指摘率

iphantom

Jul 11, 2016

61

用的 git 每次都需要 review 然后再合并
我感觉 leader 只看看大概逻辑和写代码风格
特别是有无性能特低的代码，有没有良好的缩进和注释习惯

NovemberEleven

Jul 11, 2016

62

外包行业，做项目的时间都不够，唉，还 review 。

messense

Jul 11, 2016

63

@proudzhu 因为是 test fixture.....

tianlang1989

Jul 11, 2016

64

有，个人觉得很重要
我们公司时间也很紧，天天晚上加班
然而 CR 流程一直保留

clorts

Jul 11, 2016

65

@Tonni github enterprise 价格多少？

@Ixizi review 代码要看多久？
@broadliyn review 是闲的蛋疼公司才干的么？功能都赶不及， review 个蛋啊：）
@yangxiongwei 用这个多久了？是不是很烦躁呢？
@repus911 review 这么麻烦啊？是一行行代码看过去么？都能看懂么？

lightening

Jul 11, 2016

66

有，必须有人 review 才能 merge 。

repus911

Jul 11, 2016

67

@clorts gitlab 我们 gitlab 用开源版还没有特殊需求

有的大功能比较麻烦，数据库看一遍， redis 看一遍，核心逻辑看一遍，兼容性过一遍，确认一遍。中间还有打回去修改，那边一个 sprint 10 天开发过来的 mr 怎么也得对上个 1 、 2 个小时。

当然这种情况比较少见，一般 bugfix 10 分钟，小功能半个小时搞定，还有熟练工发过来的来基本也是 10 分钟内。

别说我还真遇见过单元测试和 QA 没覆盖到的低级语法错误，嘿嘿嘿。

yangxiongwei

Jul 11, 2016

68

@clorts 习惯就好。代码质量就靠这个加测试来保证了。

而且这样是非常有必要的，前期花点功夫，后期维护起来会简单很多。

kqz901002

Jul 11, 2016

69

@sc3263 svn 可以和 review board 配合起来用，很方便

shyrock

Jul 11, 2016

70

@chousb one in One?

robert9484

Jul 11, 2016 via iPhone

71

没有啊

DingSoung

Jul 11, 2016

72

新功能没有。旧的代码，涉及底层公共的一般我自己写，让小弟看看久合了。剩下的就让测试妹子把关了。

ourcubk

Jul 11, 2016

73

代码->gerrit->自动编译 /UT/复杂度校验->review->review 通过触发自动编译生成 img->自动生成包->自动安装包->重启机器->启动完成后触发各种 case 跑自动化测试->代码 gerrit merge into git brunch->git brunch 自动 merge into brunch->终于他妈妈的完成了...........................................................................................................
review 都是小事,重要的耗时间的都是 review 无关,却严格控制代码之类的其他工作...我们公司这样进去的代码,感觉还挺放心的...

ourcubk

Jul 11, 2016

74

git brunch 自动 merge into master...

mahone3297

Jul 11, 2016

75

再来一个话题，有写 test 吗？

xwartz

Jul 11, 2016

76

代码烂成屎，入错坑了。。

Totato5749

Jul 11, 2016

77

@mahone3297 哈哈哈哈没有

sc3263

Jul 11, 2016

78

@kqz901002 是么？我试试。谢啦~

其实讲道理，这东西，得项目组 leader 规定，强制执行才有效果。个人提出来，只会被认为工作量不饱和，闲着没事干。前几天在新项目组里提出来要搞一整套流程。然后被所有人反对了，理由是浪费时间。。。

hantsy

Jul 11, 2016

79

@iphantom 你们不写测试吗》

hantsy

Jul 11, 2016

80

基本上用 Github Flow 。。。 Fork ， Branch, PR, Code Review

结合 Circle CI 等，每个 Branch 都是自动运行测试，从建 PR 开始几乎团队所有人都会参与 Review ，特别与其他人有交叉的部分，@相关人，反复讨论修改。

Upstream Master 在一些项目是稳定分支，执行自动部署。没 Code Review 谁敢直接部署？

hantsy

Jul 11, 2016

81

@ourcubk Github 做 Code Review 不是更直接。。。