簡介
本文介紹了 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 已經能夠支持完整的代碼評審功能，但在實際使用中還有一些改進之處。比如無法動態嵌入或鏈接到評論所涉及的代碼中的指定行，方便被評審者閱讀修改意見。而且評審的粒度較大，基于每個評審者的修改意見無法針對每條評論進行接收或拒絕。此外，如果加入代碼靜態分析功能，就能更快的找到問題，避免人為的疏漏。