因为我之前和现在的公司都实施 Code Review ，我发现我会重复做以下几件事：
每次做都会耗费我一些时间，这些操作感觉有点琐碎，不知道是否可以在一个地方统一做掉省的来回切了。不知道大家有没有类似的感受？是否有工具可以帮助解决？
 | 1 SoloCompany Jan 11, 2022 用 worktree 就可以 |
 | 2 aircjm Jan 11, 2022 via Android upsource |
 | 3 Ljcbaby Jan 11, 2022 VSCode 有 Github 插件来着 |
 | 5 shadowfish0 Jan 12, 2022 阿里云效好像有一个命令行方案，可以优化这个流程，名字忘了 |
 | 6 Mithril Jan 12, 2022 @DuDuDu0o0 和 JB 家的 IDE 集成的更好一些。 但实际上最关键的还是要减少每次 Review 的代码量，尽可能细的拆分功能。 不然一次搞上去十几个类，几百行代码，折腾啥工具都没用。 代码足够少你用 Gitlab 的 Review 都够了 |
 | 7 Goooler Jan 12, 2022 via Android idea 不是自带 GitHub 的代码审查功能，很好用啊 |
 | 8 marat1ren Jan 12, 2022 via iPhone 用 gerrit ，直接在网页上 review |
| 9 aircjm Jan 12, 2022 via Android @DuDuDu0o0 修改建议可以直接打在对应代码上 提高 review 效率啊 特别是很多文件提交的情况下 有上下文 可以直接在 jetbrains 的 IDE 里面进行 review 操作 merge request 光在网页上看 效率极低 |
 | 10 corningsun Jan 12, 2022 via iPhone 2 你可以再 clone 一份代码到本地，专门做 code review ；这样不会打断自己写的分支。 |
 | 11 LeslieLeung Jan 12, 2022 via iPhone Phabricator ，有个自带的 arc 工具用来 diff ，然后能生成一个链接，对方用链接就能 comment/accept 你的代码 |
 | 12 rhacker1995 Jan 12, 2022 idea 上已经集成了 github 的 pr review 了 |
 | 13 weiasd Jan 12, 2022 gerrit 是不是已经过时了？ |
 | 14 leontung OP @aircjm 我昨天找了我朋友请教，他和你持一样的观点，指出 code review 的时候，上下文不一定都在这个 PR 改动的文件中，导致他需要拉到本地用 IDE 看，然后再对照着 IDE 去 Gitlab 里评论。 |
 | 15 lululau Jan 12, 2022 团队平均水平不够的话不要做 Code Review ，纯粹浪费时间 |
 | 16 EastLord Jan 12, 2022  1 试试 CodeStream 插件？ |
| 18 leontung OP @corningsun 厉害了，这也是个办法 |
 | 20 connection Jan 12, 2022 可以请教一下你们分支管理以及 CR 时机么 |
 | 22 Cihua Jan 12, 2022 不确定是指那种，我们之前 java 用 SonarQube ，在 jenkins 打包镜像过程中去检测，发现不符合定的标准则会打包失败，同时 idea 有插件可以连接 sonar 服务器直接检测。 |
 | 23 lizuoqiang Jan 12, 2022 @aircjm upsource 不支持 gitee 吗 |
| 24 leontung OP @connection 分支管理部分，我们是在一个仓库里开发，不走 fork 路线。主要有 3 大分支：production 、main 和 develop 。大家从 develop 切分支，开发完合并到 develop ，develop 对应 test 环境；准备上线前从 develop 合并 main ，main 对应 staging 环境，业务上这个环境预览测试； main 合并 production 分支，上生产环境。 |
| 25 leontung OP @EastLord thanks ，我看下是否好用，我认为在 IDE 里完成 code review 是挺爽的，但可能只是我的个人观点。最好能够找到让我老板买单的点。 |
| 26 leontung OP @Goooler thanks ，我和楼下提到的 CodeStream 对比一下。想请教一下你是觉得是这个插件好用，还是在 IDE 里 code review 这个过程好用呢？ |
| 28 leontung OP @lizuoqiang 不支持 > Review GitHub pull requests and GitLab merge requests in Upsource. |
| 29 aircjm Jan 12, 2022 @lizuoqiang (⊙⊙) 我们之前用的时候用的是自建的 gitlab 没了解过 gitee 我理解可以用同步的方式同步 git 库 这个应该不是大问题 |
| 30 aircjm Jan 12, 2022 @leontung 换了团队了 需求太多就没时间做 review 说下之前是怎么玩的 他是 10 人免费的 可以只建两个账号 ，一个提交人，一个 review 人 要 review 的时候合并提交记录，尽量在提交记录少的情况下进行 review 。 每个人都可以用可以用这两个账号 但是也出现过账号混乱使用的问题 也可以找 pj 但是不建议这样做 公司用不要用破解东西 有风险 |
 | 31 dayeye2006199 Jan 13, 2022 原来只有我一个人永远看的是网页。。 |
| 32 dayeye2006199 Jan 13, 2022 我觉得其实工具倒还是次要的。以下几点我觉得对 review 的效率更重要： 1. 每个 PR 只做一件事情 -- 加一个 feature ，修复一个 bug 等等；这样可以保证一次需要 review 的代码量不会太大 2. 一些格式问题，常见的语法问题等等不要人来 review ，用 linter 和分析器来解决，review 之前保证先把这些低级错误给修复了 3. 特别复杂的 PR 需要附上设计文档，作者需要阐述大概是怎么实现这个功能的 4. 测试还是需要写，否则全靠人来把握代码正确性，reviewer 的心理负担会很重 |
 | 33 vilicvane Jan 13, 2022 我们通过远程工作空间解决这个问题，然后整合到了工作流中，不过也有代价。 方案比较粗糙，因为是内部工具能用就行，可以参考一下。 https://github.com/makeflow/remote-workspace |
| 34 leontung OP @dayeye2006199 哈哈，我也一直看网页，直到想到为什么不在 IDE 里 review ，是不是更高效？所以跑来请教大家意见 |
 | 36 Akiya Jan 15, 2022 via iPad vscode 的 GitHub pull requests 插件基本上可以满足需求了 |
 | 37 kejin114978 Apr 13, 2022 via Android 我们在用云效，开箱即用，还不限制团队人数，背靠阿里大厂 |
Select Language