我正在嘗試爲我的團隊找到一個很好的代碼評審工作流程。大多數類似於SO的問題都是圍繞使用擱置的更改進行審查，但我很好奇這是如何適用於大型團隊的人員的。使用TFS的大型ASP.NET MVC團隊的代碼評論
我們通常有2-3個人在講故事（UI人員，Domain/Repository人員，有時候DB人員）。我推薦了架子的想法，但我們都關心如何管理多人使用同一功能。那麼你怎麼能在多個程序員之間共享一個架子呢？我們擔心它會很笨重，我們可能很容易在這個工作流程中產生意想不到的後果。
當然，移動到每個功能的擱板上可以避免每個功能有10個左右的checkins（因爲開發人員需要共享代碼），使得在代碼檢查時看到差異是痛苦的。
有沒有其他人能夠成功地處理這個問題？除了TFS架子（最好是開源）之外，有沒有人發現有用的工具？
團隊是否分佈？如果沒有，那麼也許只是嘗試一些XP技術，如配對編程（即使不是所有的時間），並讓開發人員在功能上一起工作。當發現問題時，連續溝通通常比指定特定事件（如代碼評論）更好。
，即使團隊分發了，那裏有一些非常好的工具用於遠程對編程 – 2010-10-15 12:04:36
與TFS一起使用擱架的主要注意事項是，您不能在不同分支上的擱架之間進行差異。您只能對由shelveset創建的分支進行區分。
此外，通過其他人對shelveset所做更改來更新當前更改的支持並不好。當您將擱架組拉到本地機器上時，默認操作是覆蓋本地內容，而不是合併。我不確定在那裏是否支持合併。
因此，從服務器進行更新時，多人對同一個shelveset進行更改可能會很尷尬，並且有可能覆蓋本地工作。
對於TFS，您可能會更好地爲每個迷你團隊使用分支，因爲您可以通過這種方式在各個方向獲得完全合併支持。
一些其他版本控制系統（GIT，可能是StarTeam）具有「個人分支」的概念。這就像TFS的shelveset，但它的行爲更像是一個真正的分支，因爲你可以將它合併到TFS中，不像TFS shelveset。
附註：不要害怕多個更小的簽到。您可以一次區分簽入範圍，以將多個簽入合併爲一個差異。作爲個人風格的問題，我更喜歡經常檢查小編輯，而不是坐在怪物修訂版上幾天或幾周（或幾個月！）。大的修改需要更長的時間來審查，產生更大的風險，即某些事情會被忽略或中斷，導致更高的可能性，因此您將不得不手動解決合併衝突，並且會失去1個錯誤1：1的跟蹤原子性。
保留一個大簽入的修訂有時被稱爲「便祕」工作流程。 ;>
一些後續問題;你同時運行多少個故事，整個團隊有多大，你可以做更小的迭代（即使你沒有發佈）？
還不知道答案我會說;
如果故事的複雜性不需要不同的分支，那麼只需在迭代結束時對所有更改進行完整的代碼審查，如何？這樣你不僅可以看到所有的變化，而且可以看到它們如何一起工作。如果人們無法接受他們在審查過程中所做的更改，則您始終可以找到變更集（但在此時您確實遇到了更大的團隊問題）。根據你的團隊的規模，這可能不實際。
最後一個想法;良好的測試覆蓋率和持續集成是救命稻草。
我得到了TFS和ReviewBoard的工作。
http://blogs.pinet.ca/tim/2010/08/24/code-review-goodness-with-reviewboard/
添
只要有一個人取消擱置另一個補充擱置。 – 2010-03-12 19:41:28
爲什麼不用功能分支去分享人們之間的變化？這會導致分支太多嗎？ – Ryan 2010-03-12 20:23:03
@Ryan分支可能會難以維護。我們通常每個迭代有一個月的迭代和7-10個特徵。 @John如果從架子上拉下來的人必須擱置另一個人才能重新找到它，那麼這有多好呢？在共享代碼的幾次復飛之後，這會不會變得混亂？ – Parrots 2010-03-13 15:47:22