備註：IE6核心的瀏覽器圖片總是出不來，建 議使用Mozilla Firefox，Opera，谷歌瀏覽器 

一、       Jupiter 是什麼？

這裡的 Jupiter 是一個開源的程式碼審查工具，是整合在 Eclipse 下執行程式碼審查工作一個很棒的工具。

可以把 Jupiter 的工作劃分為 3 個階段，（我個人認為 5 個人階段），分別是：

Individual Phase 個人階段，表示個人審查階段。

Team Phase 團隊階段，表示團隊審查階段。

Rework Phase 修復階段，表示修改 Bug 階段。

而我覺得應 該加入：

任務定義階 段和 BUG 確認階段。

任務定義階 段：是指在指派審查任務前的任務定義和分配過程。

BUG 確認階段：是指 bug 修改結束後的重新審查和關閉 bug 階段。

二、       如何安裝 Jupiter

條件： Jupiter 需要 Java 5 或更高版本的 JDK 以及 Eclipse3.3 （ Europa ）或更高版本 Eclipse 。由於 Jupiter 是基於團隊的工作，建議在一個版本控制系統下執行 程式碼生審查工作。（即 CVS 或 SVN 等）。

安裝： [ 這裡只提供針對 Eclipse3.5 Galileo 的離線安裝，通過線上安裝的地址是： http://jupiter-eclipse-plugin.googlecode.com/svn/trunk/site/ 請自行決定 ]

第一步：

到 http://code.google.com/p/jupiter-eclipse-plugin/downloads/list 下載最新的 JAR 檔案。

第二步：

把下載到的 JAR 檔案拷貝到 Eclipse 的 plugins 目錄下。

第三步：

重啟 Eclipse （或是開啟 Eclipse ）如果在 Eclipse 的工具欄出現如下圖示表示安裝成功。

 

三、       如何建立 Review ID ？

1、          我們先了解 什麼是 Review ID

Review ID 代表一個審查任務，包涵了很多元素，比如審查任務 名稱，描述，審查那些程式碼檔案，審查人，審查型別，級別設定等等，而這些資訊正是組成一個審查任務的基本元素。

2、          建立 ReviewID 流程

A、        在 Eclipse 右擊選擇要審查程式碼的專案

B、        選擇“屬 性”，如下圖：

 

 

C、        進入屬性頁 面選擇“ Review ”選項，如下圖：

  

 

D、    點選右邊的 “ New… ”按鈕出現填寫框，可以填寫 ReviewID 的名稱，描述。如下圖：

 

 

E、     點選“ Next> ”按鈕進入下一步，選擇對那些程式碼檔案進行審查， 如下圖：

 

 

F、     點選“ Next> ”按鈕進入下一步，選擇或是新輸入審查人員，如下 圖：

 

 

G、    點選“ Next> ”按鈕進入下一步，指定 Session 的作者，這部可以不選擇，但是一般選擇所審查程式 的程式設計人員。

 

 

H、    點選“ Next> ”按鈕進入下一步，選擇“ Type ， Severity ， Resolution ， Status ”的選項，同時可以修改這裡選擇項，這一點很有 用，在大部分的程式碼審查工具中這個不能做到很靈活，所以有不少弊端。但是 Jupiter 搞定了這個問題。

 

 

I、        點選“ Next> ”按鈕進入下一步，確定“ Type ， Severity ， Resolution ， Status ”的預設選項。如下圖：

 

 

J、       點選“ Next> ”按鈕進入下一步，輸入最後得審查資料放在那個目 錄下，建議用日期加任務標記作為目錄，

比如 :2010630TEST ，如下圖：

 

 

K、    點選“ Next> ”按鈕進入下一步，最後設定每個階段的過濾器，每 個專案可以根據專案的需要設定，這裡預設不變。

 

 

L、     點選“ Finish ”按鈕完成 ReviewID 的設定，在工程的屬性對話方塊裡多了一條資料，這些 資料就在檔案“ .jupiter ”下，這個檔案在工程的檔案目錄下，如下圖：

 

 

 

3、          釋出 ReviewID

釋出 ReviewID 的過程其實就是配合 SVN 或是 CVS 或是其他版本控制系統釋出“ .jupiter ”，通過傳播“.jupiter ”，讓其他人把該檔案拿到同一工程下的同一目錄， 即可實現下一步驟的功能。

4、          獲取 ReviewID

獲得的方式 主要通過同步版本控制器的“ .jupiter ”檔案即可，一般是定製一個審查任務之後，發起者發出郵件，郵件裡面說明此次任務的具體細節，在“ .jupiter ”裡面就 是這些細節的體現。

四、       在 Individual Phase 我們應該做些什麼？

1、          Individual Phase 的目標

個人階段的 目標就是針對在 ReviewID 定義階段指定的審查人員開始工作的出發地，他們要 從這裡開始，把屬於他的任務執行完成，並提交到版本控制器，有很多需要注意的細節我們在後面表述。

2、          Individual Phase 的過程

1)                確認已經從 版本控制器更新了“ .jupiter ”檔案。

2)                點選 Jupiter 的 Eclipse 圖示的下拉箭頭，出現 4 個選項，選擇 1 Individual Phase ，即可進入選擇ReviewID 介面。如下圖：

 

 

3)                選擇 ReviewID 介面，如下圖：

 

 

4)                點選“ Finish ”按鈕，進入 Individual Phase 檢視，圖下圖：

 

 

5)                點選“ ReviewTable ”檢視的 按鈕，出現可以選的待審查的程式碼檔案列表，如下 圖：

 

 

6)                選擇其中你 想審查的檔案，那麼在 Eclipse 的編輯區即開啟該檔案。這時候，你可以開始你的Review 工作了。

7)                找到一個 Bug ，那怎麼辦？選擇程式碼行，右擊，選擇“ Add Review Issue…”, 如下圖：可記錄改BUG 的所有資訊，並分型別，嚴重等級等。填寫之後點選 右邊的 儲存按鈕，形成一條審查記錄。

 

 

8)                這時候在代 碼檔案行號的位置出現一個小圖示，說明這行程式碼有問題，同時在“ ReviewTable“檢視增加了一條記錄。如下圖：

 

 

 

3、          結束 Individual Phase

個人審查階 段就是這麼一個一個問題的疊加的，直到你完成所有程式碼檔案的審查工作，這之後重新整理工程專案的目錄，在目錄的下面會增加一個子目錄“ 2010630TEST ” [ 不一定就這個名稱，這是根據你在定義ReviewID 時資料而定 ] ，裡面有一個檔案“測試程式碼審查任務 -XXX.review ”。其中“ - ”的前一部分是ReviewID 名稱，後一部分的 XXX 是執行 Individual 的 ReviewerID ，也就是審查者。檔案的字尾是 .review。提交 .review 檔案到版本控制系統，並回復執行的任務郵件告知審 查發起者你的任務已經完成，在回覆時記得把 .review 檔名稱寫在郵件裡面。

五、       在 Team Phase 我們討論些什麼？

1、          Team Phase 的目標

Team Phase 的目標就是把很多審查人的審查檔案集合起來然後， 開個評審會議，把問題討論清楚，確認是否需要調整或是制定給誰解決等。

2、          Team Phase 的過程

1)      進入 Team Phase ，操作如下圖：

 

 

2)      進入下圖， 選擇討論哪個審查者審查出來的問題。

 

 

3)      點選“ Finish ”按鈕，進入 BUG 的瀏覽介面面，如下圖：

 

 

4)      那麼如何討 論一個審查出來的 BUG 呢，雙擊“ Review Table ”裡面的一個 Bug ，在 Eclipse 的編輯區即可導航到該程式碼行，而在“ Review Edit ”則開啟該 Bug 的具體描述，可以指定給那個開發人員修改 [ 預設是在設定改 ReviewID 時指定的 Session Author ] ，可以設定“ Resolution” 的選項，並新增備註。如下圖：

 

 

5)      最後點選保 存，結束一個 Bug 的討論。

3、          結束 Team Phase

依次迴圈， 逐個解決審查出來的 Bug ，並提交 .review 檔案到版本控制器，並郵件通知程式碼修改人員。每個 Bug 都應該得到重視，討論時一種很好的傳播方式，所以 在結束 Team Phase 前，一定要把問題總結出來，儘可能的避免下次再次 出現。

六、       在 Rework Phase 修改 Bug

1、          Rework Phase 的目標

Rework Phase 的目標就是每個開發人員去看看被檢查出來的 bug ，並徹底的修復它，不要留下任何給檢查者在 Reopen 的機會。

2、          Rework Phase 的過程

1)            進入 Rework Phase ，操作如下圖：

 

 

2)            同樣需要選 擇對應的專案和對應的 Review 資訊，如下圖：

 

3)            一般這時候 不一定可以在“ Review Table ”看得到 BUG 記錄，需要選擇“ Review Table ”的過濾按鈕  才能看到 Bug 記錄。

4)            Ok ，逐個雙擊，導航到程式碼，逐個修改，修改之後在“ Review Editer ”調整該 Bug 的資訊。如下圖：

 

 

其中狀態可 以改成 Resolved ，表示已經解決問題；或是 Closed 表示直接關閉，或是 Reopen ，重新開啟（最好不要被重新開啟）。

3、          結束 Rework Phase

逐個解決 Bug ，逐個修改它的狀態，最後提交 .review 檔案到版本控制系統，並郵件通知程式碼審查人員可以 重新審查已經修改的 Bug 了。

七、       確認修改

1、          可能不需要 這一步驟

有些團隊可 能不需要這一步驟，但是這只是建議，應為他們的人手不夠，而且每個開發人員都值得信任，每個修改者在修改完 bug 之後直接 close 了 bug 。直接進入報表生成階段。而我覺得這一步驟在很多 場合很有必要，比如需要有人來證明你的 bug 確實解決了。

2、          如何重新審 查

進入重新審 查的過程和進入 Rework Phase 的過程一樣，只需要檢視 Bug 修改情況和調整 Bug 的狀態即可。

3、          結束審查

結束審查之 後需要郵件通知所有相關人員您的重新審查情況。

八、       分析 .review 檔案

.review 檔案以 xml 格式為結構，具體的每個標籤標示一個實際的意義， 我們來看看它的描述問題方式：

<?xml version="1.0" encoding="UTF-8"?>

< Review id =" 測試程式碼審查任務 "> <!— 表示我們定義的 Review ID 的名稱 —>

  < ReviewIssue id =" GB1UV3SO "><!— 表示自動生成的 Bug 對應的 ID—>

   < ReviewIssueMeta >

     < CreationDate > 2010-06-30 :: 15:38:57:144 CST </ CreationDate ><!— 什麼時間建立的 Bug—>

     < LastModificationDate > 2010-07-01 :: 14:18:02:631 CST </ LastModificationDate ><!— 最後修改時間 —>

   </ ReviewIssueMeta >

   < ReviewerId > 呂寬溝 </ ReviewerId ><!— 發現 bug 的人員 —>

   < AssignedTo > 穀子地 </ AssignedTo ><!— 修改 bug 的人員 —>

   < File line =" 60 "> src/com/jem/report/exam/xml/XmlDataSourceExample.java </ File ><!—Bug 具體位置 —>

   < Type > item.type.label.programLogic </ Type ><!—Bug 的型別 —>

   < Severity > item.severity.label.normal </ Severity ><!—Bug 的嚴重等級 —>

   < Summary > 多餘程式碼 </ Summary > <!—Bug 描述標題 —>

   < Description > 這個語句在這裡是多餘的語句，沒有實際的用處。 </ Description ><!—Bug 的描述 —>

   < Annotation > 也就是這樣的 </ Annotation ><!—Bug 的批註 —>

   < Revision > 就是啊 </ Revision ><!—Bug 的調整備註 —>

   < Resolution > item.resolution.label.validFixlater </ Resolution ><!—Bug 的解決選項 —>

   < Status > item.status.label.closed </ Status ><!—Bug 最後得狀態 —>

  </ ReviewIssue >

</ Review >

九、       把 .review 檔案變成報表

因為到最後 可能有很多的 .review 檔案，我們需要把他們全比合並起來，於是我們可以 寫一個 Eclipse 外掛或是寫一個獨立的應用來完成這個工作，把多個 .review 檔案合併成一個 .review 檔案，合併的目的在於我們要利用 iReport 來幫我們完成報表的建立。如何製作一個報表參考 iReport 的使用。

本文完成 時，“ JE ”合併工具還沒有最後完成，但是介面已經出來，可 以先拿來參考，最後的報表也還沒有實現，這部分內容需要通過 iReport 實現，放在後續的文章說明。