與SVN和ReviewBoard成功的代碼審查策略？

Question

我已經成功地將ReviewBoard引入到我公司的編碼工作流程中，而「引入」意味着已經安裝並呈現它。我們也有一個普遍的協議，我們需要嚴格的代碼審查，但是，我們不太確定我們想如何去做。

我們的主版本控制是SVN，所以我們在分支和合並方面相當有限。我已經考慮過的一些策略：

1. 從主幹預先提交審查。優點包括擁有一個補丁，在版本庫中沒有未經審查的代碼。對比度不得不保持結帳清潔或者做幾個結帳的窮人分支
2. 從幹線發送後的評論。審查委員會可以很好地工作，但它不會阻止人們犯下髒代碼，也可以讓他們忽略審查請求。
3. 來自功能分支的提交後審查。優點是顯而易見的，因爲一個特性可以獨立工作，但是在創建基於服務器的分支方面存在巨大的痛苦，並且在保持不同分支同步方面也是一個巨大的痛苦。另請參閱第2項。

我希望儘可能無痛，因此有幾種可能的工作流程自動添加，例如機器人提交至少獲得X的代碼「運送它！」。投票和讓審查委員會「跟隨」具有提交鉤子的功能分支。不過，我不確定哪個代碼審查工作流程可能對我們約8個編碼人員的團隊來說是最好的。我們將無法更改修訂控制系統，即git-svn和SVK不可能出現問題（而後者無論如何都已經死掉了）。

你能從你的經驗中推薦任何東西嗎？

Answer 1

基地你的信任和責任，並保持它的重量輕系統：

1. 使用良好的判斷：「你可以在任何時間任何檢查。當你需要時請求代碼審查。'如果評論爲了方便快速評論而添加'評論者'以評論。
2. 評論板負責通過提交掛鉤監視更改。如果他們看到他們不喜歡的東西，請與開發人員討論。不同的成員可以查看不同部分。
3. 如果開發人員繼續檢查垃圾而不要求複查，請將其解僱。
4. 如果系統的某些部分異常複雜/中心/容易混亂 - 鎖定這些部分並需要批准登記。
5. 每個人都可以監控簽入。審查不僅僅是爲了審查委員會。

我已經看到了這個工作，2個開發人員，並與100

Answer 2

你的＃2，＃3（也許如果關注的分支已經審覈簡稱主幹評論）的組合可以很好地工作。我發現預先提交的評論有點令人窒息的過程 - 最好有一個熱情（由你點燃？）審查感染整個團隊。

我推薦閱讀SmartBear的免費書籍Best Kept Secrets of Peer Code Review，這是一個非常平凡的待遇。考慮到其作者出售商業代碼審查套件。 （我不爲他們工作，也不使用他們的產品，FWIW。）

這本書可以幫助你思考你的環境的兩種可能的工作流程，以及如何引入工作流程，向團隊解釋爲什麼你可能希望瞄準x-loC或更少的評論，或者有一點點導遊之前評論等

Answer 3

我們處於類似的位置。

你有沒有配置svn來給每個提交的所有開發者發郵件？這是保持每個人誠實的良好開端。我們發送一封電子郵件，其中包含日誌消息，svn diff的前200行以及trac中的全部差異鏈接（基本上只用於顯示svn差異）。

如果開發人員認爲事後需要審覈變更，我們會使用ReviewBoard進行審覈。

另一方面，開發人員也可以在辦理登機手續前申請審查。無論他們是在功能分支還是在中繼沙箱中開發更改，都沒有區別。我們已經考慮調整腳本以從命令行上傳審閱請求，但是這個過程非常簡單，至少我們還沒有這樣做。

我的總體建議是引入一個手動系統並將其自動化，並且可能在預處理腳本滿意後執行它。特別是對於一個小團隊來說，最好是在同伴壓力執法方面犯錯，因爲您希望儘量減少小生產力查殺流程的數量。

Answer 4

我們最近在我們的流程中引入了ReviewBoard。在我們添加ReviewBoard之前，我們已經完成了以下工作：

1. SVN通過電子郵件自動發送給所有開發人員進行每次簽到。
2. ViewCV集成以允許在瀏覽器提交後查看差異。
3. SCM-bug腳本與SVN集成在一起，因此開發人員必須在他們的checkins中包含一個大的id。
4. Buildbot與SVN集成在每次簽入後自動運行測試。

既然我們已經有了覆蓋相當好與其他的東西后提交的東西，我們使用ReviewBoard作爲一個pre-commit工具，只有經過我們打「功能完善」一個給定版本。

Answer 5

在大型開發中，功能分支是不可避免的。使用SVN，不可能從工作副本更新中繼的功能分支。但是，您可能會頻繁合併和創建新分行。

順便說一下，R​​B知道處理預先提交評論。

Answer 6

我同意第一種觀點：從樹幹

預提交審查因爲使用的代碼審查工具，確保在庫中沒有未查看的代碼，並保持你結帳乾淨