使用持續集成時，您在代碼審查中尋找什麼樣的內容？似乎很多關於代碼評論的文獻都提到了編碼風格，拼寫錯誤，資源使用情況，錯誤處理等問題（可能不是這樣的順序:-)然而，像FxCop和StyleCop這樣的工具似乎最能挑選出的微不足道的問題。代碼評論與CI
我認爲儘可能多的檢查應該推入CI以節省時間並確保這些檢查一致地完成。如果你採取這種方法，似乎在審查中尋找的主要內容是設計不佳，未能正確使用現有代碼結構，可能在測試中錯過的微妙缺陷等。
其他人在CI的地方進行評論？您在評論中還有哪些其他內容？
差不多，不管不能由機器自動測試（也許除了對於性能/安全問題，但它們對於人類來說更容易檢測）。
在我的經驗中，代碼評論更多的是確保以最好的方式完成任務。通常審查的結果是一些重構。如果代碼有點不禮貌，可能需要修正其他問題。像FxCop和ReSharper這樣的產品可以提高代碼質量。
代碼審查的一個關鍵方面是確保所有的馬都朝着相同的方向前進：即代碼與團隊哲學一致。在選項A或選項B合理但不應混合的情況下，有任何一些小的變化和辯論。例如單元測試getter/setters 100％的代碼覆蓋率，或使用構造函數與setter初始化的春天。我們可以辯論這些，但一旦確定下來，團隊應該堅持一致的決定。
由於選擇合理（或模糊），所以很難測試CI中的違規情況。通過評論來感受「同儕壓力」要容易得多。
過去我已經有blogged on this關於某些細節：代碼覆蓋率，國際化和數據版本化。這些只是一些與團隊哲學的一致性很重要的問題。
代碼的可讀性和未來的可維護性是一個很大的問題，從自動化解決方案中被遺漏。無證的副作用和對方法的要求急劇增加。稱爲changeX()的方法不會更改X，並且稱爲getFoo()的方法返回foo的值，並且還祕密地將7添加到對象的內部狀態。
該代碼提供了儘可能最佳的商業價值。此外，代碼評審不僅僅針對已編寫的代碼，而且還有助於塑造將來編寫的代碼。使用目前可用的工具，我們過去尋找的許多工具已經（至少大部分）由時間代碼致力於源代碼控制。至少我認爲這是應該完成的。詳細說明這裏是我之前就這個主題寫過的東西的一小部分。
「。近年來，網絡代碼審查工具不斷改進，取消了代碼審查的一些傳統必要性，但不是最有價值的方面。有像FxCop這樣的靜態分析工具可以自動查看所有代碼確定性行業標準指南。有像微軟最近發佈的源代碼分析（a.k.a. StyleCop）等源代碼分析工具來檢查所做的所有源代碼樣式選擇。通過持續集成和TDD代碼進行審查，以確保其構建並滿足預期的業務場景。最近推出了像NDepend這樣的產品來審查代碼並提供統計信息，以幫助確定設計是否遵循導致可持續性的原則。所有這些類型的工具都增強了我們審查軟件的生態系統。但是，他們都沒有提供任何關於代碼審查最關鍵方面的幫助 - 「這個代碼是否爲業務領域提供了最佳價值？」這個問題的答案僅僅是因爲代碼通過FxCop，StyleCop在NDepend中看起來不錯並通過自動化測試並不意味着它提供了最佳的商業價值。這些工具是無領域代碼審查生態系統的一部分，他們對我們創建軟件的任何業務或我們的代碼爲該域提供服務的程度沒有任何洞察力。 「最佳價值」問題的答案在某種程度上是主觀的，但最有能力提供答案的人是該領域的編碼人員使用他們僅保留的隱性技術和商業知識。代碼審查是應用和共享隱性知識，並找到答案的「最佳價值」問題的方式。」 - TeamReview - New Business Value From Code Review
這一點，再加上（或許更重要的？）的測試覆蓋率 – metao 2008-09-22 03:24:50