简介
本文介绍了 IBM Rational Team Concert（RTC）的代码评审功能（Code Review）。这一功能可以使代码评审流程变得更加规范，完善代码提交流程；对于不同区域的成员可以更高效的协同工作，在代码提交前发现到潜在的问题，尽快修复，提高代码质量，有效减少缺陷数。
代码评审的重要性
多数情况下，评审者能够发现开发人员自身不能发现的问题或潜在问题，毕竟思维方式和考虑的点等会有差异
- 优秀的评审者通过评审，不仅可以发现开发人员的不足，更可以通过开发人员的代码学到很多知识
- 对团队而言，通过评审以及互相评审，了解到其他团队成员负责的任务，必要时互相帮忙，互为后援，提高项目开发效率，降低项目风险
代码评审的规则
- 从逻辑上讲，本次修改是否符合需求，是否有类似的地方需要修改
- 可读性上，是否有足够的解释说明，以便以后维护
- 就代码规范而言，是否符合公司代码规范，以保持代码风格一致性
- 从代码性能上讲，是否有更有效的方案可以实现
- 单元测试（如果必要），测试用例是否能覆盖本次的修改
RTC 对代码评审的支持
作为目前主流的代码管理工具，RTC 对代码评审的功能已经有了很好的支持，比如利用邮件作为代码提交者与评审者通信的工具，代码评审过程中各个角色的划分，代码提交的权限设置等等，本节将具体介绍 RTC 在代码评审过程中所涉及的概念及详细配置。
对邮件的支持
在整个代码评审过程中，邮件是作为代码提交者及其他相关人员之间的重要通信工具，比如在代码评审前提交、对代码添加修改意见，团队相关人员都应收到相应的邮件提醒，用户可以通过如下配置是否启用邮件支持：
- 打开 Repository Connections 界面并连接
图 1. Repository 连接界面
- 打开用户编辑窗口，如图 2 所示：
图 2. Open My User Editor
- 找到 Mail Configuration 页面，进行相应的配置并保存，如图 3 所示：
图 3. 邮件配置界面
代码评审中所涉及的角色的划分
在整个代码评审过程中，RTC 将会涉及到如下几种角色
- Submitter：代码提交者，由实现新功能的开发者自己担任，可执行的操作有 Submit for review、Check-in，Deliver、Add Approver 等等。
- Review：代码审查人员，负责代码提交前细粒度的代码审查工作，排除潜在的缺陷，一般由团队中对所要修改的代码比较熟悉的人员担任。可执行的操作有 Add comment、Rejected、Approved 等。
- Approver：代码评阅者，负责代码提交前粗粒度的代码审查工作，一般由资深开发人员及 tech lead 担任，可执行的操作有 Add comments，Rejected、Approved 等。
- Verifier：功能的验证者，对功能的实现作一些单元测试等等。
事实上对于以上这些角色，Submitter，Reviewer 和 Approver 是必须，Verifier 是可选的，用户可以根据团队实际情况决定在代码评审过程中是否需要 Verifier。
代码提交前的权限控制
RTC 在代码提交时有了较好权限配置的支持，用户（一般由 Project owner 或团队的 tech lead 配置此权限）可以根据如下步骤进行配置：
- 连接自己所在的项目并打开，如图 4 所示：
图 4. 项目连接界面
- 切换到 Project Area 中的 Process Configuration 页面，如图 5 所示：
图 5. 流程配置界面
- 双击 Team Configuration 中的 Operation Behavior 选项，如图 6 所示：
图 6. 操作行为界面
- 从右边列表中选择 Source Control 中的 Deliver（server）选项，双击对应 Everyone(default) 图标，并双击 Add ... 按钮添加代码提交时的 Preconditions. 如图 7 所示：
图 7. Add Preconditions
- 在弹出的 Add Preconditions 对话框中选择 Require Work Item Approval 选项，如图 8 所示：
图 8. Add Preconditions 界面
- 双击 Required approvals 栏中 new ... 按钮添加代码提交时的 Required Approval，针对不同的 Approval 类型选择相应的 Approvers，单击 ok 按钮，最后保存所有配置。如图 9 所示：
图 9. 添加 Approval
经过上述一系列配置后，代码提交者必须先取得相应的 Approval 之后才能提交代码，从而达到代码提交时的权限控制，保证代码的质量。
RTC 代码评审使用示例
在 RTC 中，代码评审的流程大致如下，各个团队可以根据实际情况进行优化。
图 10. 代码评审时序图
下面我将以一个简单的实例来说明在 RTC 中是如何进行代码评审的：
- Check in 变更集
修改源代码，在 RTC 客户端中找到 Pending Changes 视图，并将这些变更集 check in 到在 Jazz repository 上的 workspace，如图 11 所示：
图 11. Check in 变更集界面
- 关联 work item
在 Pending Changes 视图中，将 check in 的变更集关联到相应的 work item(story 上的 task work item 或者是 issue 类型的 work item) 上。
图 12. 关联 work item 界面
- 提交代码给相应的 approver review
在 Pending Changes 视图中，找到相应的 Outgoing 变更集，点击右键菜单中的 Submit for Review... 选项。
图 13. Submit for Review 界面
- 添加注释和相应的 Approver
在弹出的 submit for review 的对话框中添加相应的注释及添加相应的 Approver 类型（具体类型请参考 RTC 中对代码评审章节）。
图 14. 添加注释和 Approver 对话框
- 确定需要评审代码关联的 work item
Approver 将会根据 RTC 中关于代码评审的邮件找到相应的 work item，并从 work item 中找到链接页面。
图 15. work item 链接界面
- 查找对应的变更集
Approver 从链接页面中找到需要评审的变更集，双击此变更集，变更集将会在 RTC 客户端的变更视图中显示。
图 16. 查看变更集界面
- 给出评审结果及意见
每个 Approver 根据代码评审的实际情况给出相应的修改意见和评审意见，如对于哪一行代码需要修改或者同意提交等等，具体操作如图 17 所示：
图 17. 代码评审界面
如果给出的评审结果为同意提交，则 submitter 直接进入代码提交阶段。如在此阶段给出的评审结果为拒绝，则 submitter 需要从 work item 的 overview 视图或 RTC 邮件中查看 Approver 添加的修改意见，并根据意见进行代码修改，重新提交代码评审。
- 代码提交
代码 Submitter 在 Pending Changes 视图中找到相应的 Outgoing 变更集并提交。
RTC 代码评审的注意事项
一次代码评审和所提交的一个变更集是一一对应的关系，当对一个变更集提交代码评审后，这个变更集就被冻结，此后对其中任何文件的修改都将通过另一新的变更集来跟踪。所以，对于新的修改，需要再次提交代码评审。
评审者在应用被评审者的变更集进行代码评审时，有时会和评审者本地的变更集产生冲突，此时只要将产生冲突的本地变更集暂停（Suspend），就能暂时避免冲突从而继续进行评审。
RTC 代码评审的不足及展望
虽然 RTC 已经能够支持完整的代码评审功能，但在实际使用中还有一些改进之处。比如无法动态嵌入或链接到评论所涉及的代码中的指定行，方便被评审者阅读修改意见。而且评审的粒度较大，基于每个评审者的修改意见无法针对每条评论进行接收或拒绝。此外，如果加入代码静态分析功能，就能更快的找到问题，避免人为的疏漏。