我們目前是由4-5個開發人員組成的團隊，運行在敏捷過程中。爲了提高我們的代碼質量，我們制定了嚴格的代碼審查政策：除非另一雙眼睛審查代碼，否則任何代碼都不能推送到主分支。避免由代碼評論導致的上下文切換成本
儘管非常有幫助，但我們認爲審查會導致大量開銷。審覈時間不是問題，上下文切換是一個更大的問題;結合另一個小提交的最佳做法，結果是我們的編碼人員經常不能編碼超過一個小時左右，而不會被打斷來檢查某人的代碼。上下文切換是問題。
延遲代碼審查階段到專用的時間已晚，在實踐中的工作日是不是無縫的，因爲它聽起來可能。代碼中有很多依賴關係，必須在建立之前進行審查;所以這種情況也會導致頻繁的代碼審查。
我同意代碼評論是有用的。代碼完整，說，
設計和代碼檢查的平均效果是55％和60％。
但是，有很多事情你可以做，使他們更容易。
請評論小。一般來說，Frequency Reduces Difficultly以及代碼審查的情況下，通過經常審查您的代碼，它可以確保代碼審查永遠不會太大。複雜性通常不是線性的，您擁有的文件越多，複雜性就會呈指數級增長。
結對編程採用變頻原理減少在難到了極點（也許爲什麼XP的其一部分）。當你與某人結對編程時，你不需要進行代碼審查，因爲它總是被其他人看着。如果您將程序配對，則沒有上下文切換，因爲您的審閱者始終與您合作（並且您經常切換角色）。
自動化和單元測試直接幫助代碼審查（和促進結對編程）。他們幫助說明一段代碼的意圖是什麼，應該有助於理解。他們還將幫助您獲得即時反饋，並有信心進行重構和其他非功能性更改等建議的更改。
自動化編碼標準（如，靜態分析工具如FxCop的，NDepends和憲兵在.NET）可以幫助減少對什麼審閱需要尋找負載。如果需要，可以將它們擴展爲支持您自己的規則，如架構約束。如果你有一個遺留的代碼庫，我建議你將它設置爲只標記失敗，如果它們比以前的版本更差更差。這至少應該阻止事情變得更糟。
聽起來你並沒有像你應該使用你的Source控制系統。鼓勵小提議，它可以幫助您找到一個良好的關閉時間點，以便在出現問題時回退。但是，您不會向主分支（或主幹或任何您稱之爲的）提交/檢入。你做這些小的提交到你的本地分支，當時間到了推動整個事情主要（主幹），那麼你會做代碼評論。這就是我們的做法，我們最終每隔一兩天就完成一次代碼審查，這並不壞。
在這種情況下，我建議您查看故事作爲一個整體，而不是單獨的入住手續。通常情況下，我們的故事需要2到3天才能實現，我們發現整個堆棧的同行評審往往會發現比同行評審每項任務更多的問題（您只在您面前審覈代碼，而不是如何適合周圍的代碼和架構）。
然後你可以有你的功能分支和您的主線之間的柵其中規定，所有代碼都必須經過測試和同行評審。
如果您將Pair編程視爲連續代碼審閱，並且如果您配對編程，您的問題就解決了。這不是唯一的解決方案，但它可能是一個很好的解決方案。 –
這在小團隊中並不是很可行。我們不能在我的團隊中這樣做 –
當您擁有> 1位程序員時，Pair編程是可行的。 –