Trac：代碼審查插件

Question

我正在尋找一個代碼審查插件爲我們的trac安裝。

我發現這兩個爲 「trac code review」 查詢頂部結果對谷歌

• PeerCodeReview
• CodeReview

我傾向於PeerCodeReview插件。

要求SO社區輸入關於這些插件的信息，以幫助我們選擇一個用於trac安裝的插件。

如果你知道其他插件，請讓我知道這些。 :)

什麼，我在插件

• 尋找一種方式與註釋註釋代碼。
• 批准/不批准;有點像按鈕來通知代碼需要改變。可能會創建一個錯誤。
• 一種將代碼審查「任務」分配給某個人的方法。

第一個功能是必需的（我想這就是整點）;其他人是可選的。我可以破解trac以獲得與該工作流相似的內容。希望！ ;）

Answer 1

我們是同樣的情況。最後，我們選擇與Trac並行安裝Review Board。雖然它不是一個Trac插件，但它是一個很好的工具，到目前爲止我們對它很滿意。

它也有基本的Trac的支持，這樣，例如，檢討錯誤修正時，你會得到自動鏈接到Trac的車票。

Answer 2

在我的公司，我們簡單地看了一下TracHacks上的「peerreview」插件，並對此非常失望。

對我們來說，一個代碼審查插件自然會默認假設整個Subversion提交應該進行代碼審查，這似乎很明顯。不幸的是，peerreview插件強制您手動確定要查看的代碼行。它甚至不會給你提示哪些行可能因特定的提交而改變，這意味着如果你沒有輸入那些經過仔細修改的行，最終可能會反覆檢查相同的代碼行。

我們沒有機會詳細回顧其他插件（CodeReviewPlugin）。

Answer 3

我認爲PeerCodeReview更適合您的需求。

但是，上一張海報是正確的，您必須瀏覽源代碼庫並選擇您想要查看的代碼並對其進行註釋。它對變更集一無所知。

如果您有人（如建築師或主管）主動查看代碼並確定可能存在問題的事情，這很好。

如果您想查看與變更相關的每一塊代碼，它並不會奏效。

如果你正在尋找的東西，與關聯提交和處理的diff，然後看ReviewBoard (a DJango app):

Answer 4

我也對PeerCodeReview感到失望。它將評論與特定修訂相關聯，並且當您「重新提交」一個新的修訂版以供審閱時，您將關閉舊評論並開啓一個新評論 - 但所有評論僅保留在舊評論中！所以沒有簡單的方法可以看到一個評論以及解決它的新的源代碼。再加上完全不支持審查提交/差異，這使得PeerCodeReview不適合我。

的代碼審查的插件看上去不錯（實際上並沒有嘗試），但我還是很懷念在特定行進行評論的能力。

我不應該說我的使用情況下，是不是經典的「代碼評審」，但回顧單一的LaTeX文檔。這有不同的要求：

• 在不需要提交之前進行檢查;相反，一個「流水線」工作流程 是至關重要的：當審稿人有空餘時間， 創建評審意見和當作家變得對他們來說，經常要晚得多提交解決。

• 它會是不錯的跟蹤其文本部分都在什麼修改了審查。
  這並不重要，因爲審閱通常一次完成一個部分，並且很容易手動追蹤 。

• 有許多小型的獨立意見。每個評論應獨立跟蹤 ，一個提交的「批准/拒絕」解決方案。

• 多數意見是在文件中以及本地化的，所以我想，允許在文件中附加 他們特定的地方流動，他們應該保持自己的位置時，該文件是 編輯。

的權流因爲這將是開出罰單爲每個評論，與尋址時提交掛鉤關閉它們。唯一的問題是，沒有簡單的方法將票證綁定到文件中的特定行，使其非常麻煩。我很想寫一個簡單的插件，將門票綁定到源/差線。會有其他人喜歡這樣的野獸嗎？

我在練習中可能會做的事情是將TODO註釋放在源代碼本身中，並且完全不使用花哨的Trac接口。版本控制將確保評論留在編輯之間它們所屬的位置。

[乳膠具體而言，我可能會使用todonotes和/或fixme包很好地顯示評論，也許latexdiff視覺diff文件]我將修改這個稍後向警方如何去...

順便說一句，這種方法並不侷限於文檔 - 我曾與一個團隊合作，在密集的敏捷開發過程中使用它進行代碼審查，並且運行良好。他們也有類似的願望來「審視」審查過程 - 發展必須繼續下去，但在發佈之前必須審查所有變更。最難的部分是跟蹤什麼已經或沒有被審查，這是通過標記「乾淨」的修訂和差異來完成的;回想起來，有「審查」分支和櫻桃採摘到它會更好。 （當然，非本地化的架構問題可能會轉化爲Trac門票，或者會以TODO評論的形式出現，並且如果證明這些問題不是很重要，那麼它們將被遷移到門票中。）