大家有没有尝试过用什么工具提升团队 Code Review 时候的协作效率?

2022-01-11 17:24:07 +08:00
 leontung

因为我之前和现在的公司都实施 Code Review ,我发现我会重复做以下几件事:

  1. 最常见的:在 IDE 里写代码的时候,切换窗口到浏览器打开 Github/Gitlab 的网站,找到自己的 PR ,review 代码提交评论,再回到 IDE 里。
  2. 较为少的:我要 checkout 别人的分支在本地预览代码,这时候我需要 git stash 、git checkout branch 、git pull ,对着 IDE 在浏览器里提交评论。结束之后,checkout 自己开发的分支,恢复 stash 的代码,回忆自己上次写到哪里打开那个文件继续写。

每次做都会耗费我一些时间,这些操作感觉有点琐碎,不知道是否可以在一个地方统一做掉省的来回切了。不知道大家有没有类似的感受?是否有工具可以帮助解决?

6443 次点击
所在节点    程序员
37 条回复
leontung
2022-01-12 13:11:20 +08:00
@aircjm BTW ,请问你的团队在用这款产品么?因为是付费产品,需要能够有理由驱动我们老大买单
Cihua
2022-01-12 13:46:48 +08:00
不确定是指那种,我们之前 java 用 SonarQube ,在 jenkins 打包镜像过程中去检测,发现不符合定的标准则会打包失败,同时 idea 有插件可以连接 sonar 服务器直接检测。
lizuoqiang
2022-01-12 14:27:04 +08:00
@aircjm upsource 不支持 gitee 吗
leontung
2022-01-12 17:26:11 +08:00
@connection 分支管理部分,我们是在一个仓库里开发,不走 fork 路线。主要有 3 大分支:production 、main 和 develop 。大家从 develop 切分支,开发完合并到 develop ,develop 对应 test 环境;准备上线前从 develop 合并 main ,main 对应 staging 环境,业务上这个环境预览测试; main 合并 production 分支,上生产环境。
leontung
2022-01-12 17:30:15 +08:00
@EastLord thanks ,我看下是否好用,我认为在 IDE 里完成 code review 是挺爽的,但可能只是我的个人观点。最好能够找到让我老板买单的点。
leontung
2022-01-12 17:32:22 +08:00
@Goooler thanks ,我和楼下提到的 CodeStream 对比一下。想请教一下你是觉得是这个插件好用,还是在 IDE 里 code review 这个过程好用呢?
leontung
2022-01-12 17:35:44 +08:00
@Ljcbaby 请问你日常使用这个插件么
leontung
2022-01-12 17:37:15 +08:00
@lizuoqiang 不支持
> Review GitHub pull requests and GitLab merge requests in Upsource.
aircjm
2022-01-12 18:45:34 +08:00
@lizuoqiang (⊙﹏⊙) 我们之前用的时候用的是自建的 gitlab 没了解过 gitee 我理解可以用同步的方式同步 git 库 这个应该不是大问题
aircjm
2022-01-12 18:57:41 +08:00
@leontung 换了团队了 需求太多就没时间做 review 😓
说下之前是怎么玩的 他是 10 人免费的 可以只建两个账号 ,一个提交人,一个 review 人 要 review 的时候合并提交记录,尽量在提交记录少的情况下进行 review 。
每个人都可以用可以用这两个账号 但是也出现过账号混乱使用的问题

也可以找 pj 但是不建议这样做 公司用不要用破解东西 有风险
dayeye2006199
2022-01-13 06:35:46 +08:00
原来只有我一个人永远看的是网页。。
dayeye2006199
2022-01-13 06:41:32 +08:00
我觉得其实工具倒还是次要的。以下几点我觉得对 review 的效率更重要:
1. 每个 PR 只做一件事情 -- 加一个 feature ,修复一个 bug 等等;这样可以保证一次需要 review 的代码量不会太大
2. 一些格式问题,常见的语法问题等等不要人来 review ,用 linter 和分析器来解决,review 之前保证先把这些低级错误给修复了
3. 特别复杂的 PR 需要附上设计文档,作者需要阐述大概是怎么实现这个功能的
4. 测试还是需要写,否则全靠人来把握代码正确性,reviewer 的心理负担会很重
vilic
2022-01-13 07:33:44 +08:00
我们通过远程工作空间解决这个问题,然后整合到了工作流中,不过也有代价。
方案比较粗糙,因为是内部工具能用就行,可以参考一下。
https://github.com/makeflow/remote-workspace
leontung
2022-01-13 10:12:27 +08:00
@dayeye2006199 哈哈,我也一直看网页,直到想到为什么不在 IDE 里 review ,是不是更高效?所以跑来请教大家意见
leontung
2022-01-13 10:25:26 +08:00
@vilic thanks ,我 star 了项目,待会试用一下,如果有问题向你请教
Akiya
2022-01-15 13:41:07 +08:00
vscode 的 GitHub pull requests 插件基本上可以满足需求了
kejin114978
2022-04-13 17:17:46 +08:00
我们在用云效,开箱即用,还不限制团队人数,背靠阿里大厂😁

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

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

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

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

© 2021 V2EX