paulwong

使用 IBM Rational Team Concert（RTC）進(jìn)行代碼評(píng)審

簡(jiǎn)介

本文介紹了 IBM Rational Team Concert（RTC）的代碼評(píng)審功能（Code Review）。這一功能可以使代碼評(píng)審流程變得更加規(guī)范，完善代碼提交流程；對(duì)于不同區(qū)域的成員可以更高效的協(xié)同工作，在代碼提交前發(fā)現(xiàn)到潛在的問(wèn)題，盡快修復(fù)，提高代碼質(zhì)量，有效減少缺陷數(shù)。

代碼評(píng)審的重要性

多數(shù)情況下，評(píng)審者能夠發(fā)現(xiàn)開(kāi)發(fā)人員自身不能發(fā)現(xiàn)的問(wèn)題或潛在問(wèn)題，畢竟思維方式和考慮的點(diǎn)等會(huì)有差異

• 優(yōu)秀的評(píng)審者通過(guò)評(píng)審，不僅可以發(fā)現(xiàn)開(kāi)發(fā)人員的不足，更可以通過(guò)開(kāi)發(fā)人員的代碼學(xué)到很多知識(shí)
• 對(duì)團(tuán)隊(duì)而言，通過(guò)評(píng)審以及互相評(píng)審，了解到其他團(tuán)隊(duì)成員負(fù)責(zé)的任務(wù)，必要時(shí)互相幫忙，互為后援，提高項(xiàng)目開(kāi)發(fā)效率，降低項(xiàng)目風(fēng)險(xiǎn)

代碼評(píng)審的規(guī)則

• 從邏輯上講，本次修改是否符合需求，是否有類似的地方需要修改
• 可讀性上，是否有足夠的解釋說(shuō)明，以便以后維護(hù)
• 就代碼規(guī)范而言，是否符合公司代碼規(guī)范，以保持代碼風(fēng)格一致性
• 從代碼性能上講，是否有更有效的方案可以實(shí)現(xiàn)
• 單元測(cè)試（如果必要），測(cè)試用例是否能覆蓋本次的修改

RTC 對(duì)代碼評(píng)審的支持

作為目前主流的代碼管理工具，RTC 對(duì)代碼評(píng)審的功能已經(jīng)有了很好的支持，比如利用郵件作為代碼提交者與評(píng)審者通信的工具，代碼評(píng)審過(guò)程中各個(gè)角色的劃分，代碼提交的權(quán)限設(shè)置等等，本節(jié)將具體介紹 RTC 在代碼評(píng)審過(guò)程中所涉及的概念及詳細(xì)配置。

對(duì)郵件的支持

在整個(gè)代碼評(píng)審過(guò)程中，郵件是作為代碼提交者及其他相關(guān)人員之間的重要通信工具，比如在代碼評(píng)審前提交、對(duì)代碼添加修改意見(jiàn)，團(tuán)隊(duì)相關(guān)人員都應(yīng)收到相應(yīng)的郵件提醒，用戶可以通過(guò)如下配置是否啟用郵件支持：

1. 打開(kāi) Repository Connections 界面并連接

2. 打開(kāi)用戶編輯窗口，如圖 2 所示：

3. 找到 Mail Configuration 頁(yè)面，進(jìn)行相應(yīng)的配置并保存，如圖 3 所示：

代碼評(píng)審中所涉及的角色的劃分

在整個(gè)代碼評(píng)審過(guò)程中，RTC 將會(huì)涉及到如下幾種角色

• Submitter：代碼提交者，由實(shí)現(xiàn)新功能的開(kāi)發(fā)者自己擔(dān)任，可執(zhí)行的操作有 Submit for review、Check-in，Deliver、Add Approver 等等。
• Review：代碼審查人員，負(fù)責(zé)代碼提交前細(xì)粒度的代碼審查工作，排除潛在的缺陷，一般由團(tuán)隊(duì)中對(duì)所要修改的代碼比較熟悉的人員擔(dān)任。可執(zhí)行的操作有 Add comment、Rejected、Approved 等。
• Approver：代碼評(píng)閱者，負(fù)責(zé)代碼提交前粗粒度的代碼審查工作，一般由資深開(kāi)發(fā)人員及 tech lead 擔(dān)任，可執(zhí)行的操作有 Add comments，Rejected、Approved 等。
• Verifier：功能的驗(yàn)證者，對(duì)功能的實(shí)現(xiàn)作一些單元測(cè)試等等。

事實(shí)上對(duì)于以上這些角色，Submitter，Reviewer 和 Approver 是必須，Verifier 是可選的，用戶可以根據(jù)團(tuán)隊(duì)實(shí)際情況決定在代碼評(píng)審過(guò)程中是否需要 Verifier。

代碼提交前的權(quán)限控制

RTC 在代碼提交時(shí)有了較好權(quán)限配置的支持，用戶（一般由 Project owner 或團(tuán)隊(duì)的 tech lead 配置此權(quán)限）可以根據(jù)如下步驟進(jìn)行配置：

4. 連接自己所在的項(xiàng)目并打開(kāi)，如圖 4 所示：

5. 切換到 Project Area 中的 Process Configuration 頁(yè)面，如圖 5 所示：

6. 雙擊 Team Configuration 中的 Operation Behavior 選項(xiàng)，如圖 6 所示：

7. 從右邊列表中選擇 Source Control 中的 Deliver（server）選項(xiàng)，雙擊對(duì)應(yīng) Everyone(default) 圖標(biāo)，并雙擊 Add ... 按鈕添加代碼提交時(shí)的 Preconditions. 如圖 7 所示：

8. 在彈出的 Add Preconditions 對(duì)話框中選擇 Require Work Item Approval 選項(xiàng)，如圖 8 所示：

9. 雙擊 Required approvals 欄中 new ... 按鈕添加代碼提交時(shí)的 Required Approval，針對(duì)不同的 Approval 類型選擇相應(yīng)的 Approvers，單擊 ok 按鈕，最后保存所有配置。如圖 9 所示：

經(jīng)過(guò)上述一系列配置后，代碼提交者必須先取得相應(yīng)的 Approval 之后才能提交代碼，從而達(dá)到代碼提交時(shí)的權(quán)限控制，保證代碼的質(zhì)量。

RTC 代碼評(píng)審使用示例

在 RTC 中，代碼評(píng)審的流程大致如下，各個(gè)團(tuán)隊(duì)可以根據(jù)實(shí)際情況進(jìn)行優(yōu)化。

下面我將以一個(gè)簡(jiǎn)單的實(shí)例來(lái)說(shuō)明在 RTC 中是如何進(jìn)行代碼評(píng)審的：

1. Check in 變更集

修改源代碼，在 RTC 客戶端中找到 Pending Changes 視圖，并將這些變更集 check in 到在 Jazz repository 上的 workspace，如圖 11 所示：

2. 關(guān)聯(lián) work item

在 Pending Changes 視圖中，將 check in 的變更集關(guān)聯(lián)到相應(yīng)的 work item(story 上的 task work item 或者是 issue 類型的 work item) 上。

3. 提交代碼給相應(yīng)的 approver review

在 Pending Changes 視圖中，找到相應(yīng)的 Outgoing 變更集，點(diǎn)擊右鍵菜單中的 Submit for Review... 選項(xiàng)。

4. 添加注釋和相應(yīng)的 Approver

在彈出的 submit for review 的對(duì)話框中添加相應(yīng)的注釋及添加相應(yīng)的 Approver 類型（具體類型請(qǐng)參考 RTC 中對(duì)代碼評(píng)審章節(jié)）。

5. 確定需要評(píng)審代碼關(guān)聯(lián)的 work item

Approver 將會(huì)根據(jù) RTC 中關(guān)于代碼評(píng)審的郵件找到相應(yīng)的 work item，并從 work item 中找到鏈接頁(yè)面。

6. 查找對(duì)應(yīng)的變更集

Approver 從鏈接頁(yè)面中找到需要評(píng)審的變更集，雙擊此變更集，變更集將會(huì)在 RTC 客戶端的變更視圖中顯示。

7. 給出評(píng)審結(jié)果及意見(jiàn)

每個(gè) Approver 根據(jù)代碼評(píng)審的實(shí)際情況給出相應(yīng)的修改意見(jiàn)和評(píng)審意見(jiàn)，如對(duì)于哪一行代碼需要修改或者同意提交等等，具體操作如圖 17 所示：

如果給出的評(píng)審結(jié)果為同意提交，則 submitter 直接進(jìn)入代碼提交階段。如在此階段給出的評(píng)審結(jié)果為拒絕，則 submitter 需要從 work item 的 overview 視圖或 RTC 郵件中查看 Approver 添加的修改意見(jiàn)，并根據(jù)意見(jiàn)進(jìn)行代碼修改，重新提交代碼評(píng)審。

8. 代碼提交

代碼 Submitter 在 Pending Changes 視圖中找到相應(yīng)的 Outgoing 變更集并提交。

RTC 代碼評(píng)審的注意事項(xiàng)

一次代碼評(píng)審和所提交的一個(gè)變更集是一一對(duì)應(yīng)的關(guān)系，當(dāng)對(duì)一個(gè)變更集提交代碼評(píng)審后，這個(gè)變更集就被凍結(jié)，此后對(duì)其中任何文件的修改都將通過(guò)另一新的變更集來(lái)跟蹤。所以，對(duì)于新的修改，需要再次提交代碼評(píng)審。

評(píng)審者在應(yīng)用被評(píng)審者的變更集進(jìn)行代碼評(píng)審時(shí)，有時(shí)會(huì)和評(píng)審者本地的變更集產(chǎn)生沖突，此時(shí)只要將產(chǎn)生沖突的本地變更集暫停（Suspend），就能暫時(shí)避免沖突從而繼續(xù)進(jìn)行評(píng)審。

RTC 代碼評(píng)審的不足及展望

雖然 RTC 已經(jīng)能夠支持完整的代碼評(píng)審功能，但在實(shí)際使用中還有一些改進(jìn)之處。比如無(wú)法動(dòng)態(tài)嵌入或鏈接到評(píng)論所涉及的代碼中的指定行，方便被評(píng)審者閱讀修改意見(jiàn)。而且評(píng)審的粒度較大，基于每個(gè)評(píng)審者的修改意見(jiàn)無(wú)法針對(duì)每條評(píng)論進(jìn)行接收或拒絕。此外，如果加入代碼靜態(tài)分析功能，就能更快的找到問(wèn)題，避免人為的疏漏。

posted on 2012-10-31 21:19 paulwong 閱讀(1331) 評(píng)論(0)  編輯  收藏 所屬分類: Configuration Management