如何確定要查看哪些代碼部分？

我認爲這個堆棧交換[方案]（http://area51.stackexchange.com/proposals/11464/code-review?referrer=aWNm_PdciyFqjFW8CUacGw2「代碼評論」）可能會對你感興趣。如果它顯示你的支持，並幫助它進入測試版！ :) – greatwolf 2011-01-16 23:42:33

有人應該檢查每一行更改的代碼。如果單個變更中的代碼太多以至於無法檢查，那麼您的變化太大了，您應該考慮將變更分解爲一系列較小的變更。

不是每個人都需要檢查每一項變更，但每一項變更都應該由某人審查。沒有人寫完美的代碼。

來源

2009-11-12 14:16:37

這是否好與否取決於您的環境和您的應用程序。如果時間和金錢，無限或「正確地對待」是至關重要的（例如，如果金融交易或安全取決於它），那麼是的，但要意識到審查每一個變化是非常昂貴的（並且可以比奇怪的錯誤更多）。 – 2009-11-12 14:35:20

@Iain，問題是你不能知道「奇怪的錯誤」是否會導致你認真的問題，直到你理解它，直到你找到它才能理解它。 – 2009-11-12 14:50:12

@Dominic這就是爲什麼我說它的應用程序的性質。儘管聽起來並不令人滿意，但我們都知道有一些非常廣泛使用的應用程序是非常錯誤的（有些甚至定期崩潰），但它們非常成功，甚至非常受歡迎。其他系統，如計費平臺，本質上具有更小的容錯能力。 – 2009-11-12 16:12:52

我總是從「醜陋」的部分開始，因爲這裏有一點評論，像xx1這樣的糟糕的變量名稱選擇，或者任何決定它不想使用封裝的地方。那些幾乎總是把我當作需要審查的地方。之後，我同意上面的「最複雜」評論。

來源

2009-11-12 14:17:50 wheaties

+1一個簡單而明確的答案。我認爲這是一個很好的開始。如果沒有一個是這樣的話，那很好，你可以轉向「最複雜」/多毛的案例。 – 2009-11-12 14:43:02

您應該檢查當前開發迭代中已更改的代碼的區域/與特定的開發案例相關。

例如在我們使用Fogbugz的環境中，它的工作方式如下： - 開發人員使用fogbugz案例 - 開發人員進行代碼更改，檢入subversion，並將更改的文件鏈接到fogbogz案例中 - 開發人員分配代碼審查案例 - 代碼審查人員查看針對該案例更改的文件/所做的更改（通過與案例相關的「Checkins」列表列出），並檢查所做的更改是否合理/正確。 - 如果一切正常，代碼審查員將案件標記爲已解決/已完成，否則將其分配給開發人員並提出意見

來源

2009-11-12 14:19:19 AdaTheDev

代碼審查的一個動機是發現錯誤。另一個是讓更多的開發者接觸到他們通常不會看到的代碼庫的一部分。這有助於培養初級編碼員。這也有助於確保開發人員離開時不會遇到大問題 - 因爲他們是唯一知道如何工作的人。

所以：

查看可怕的應用程序的部分。特別是你會猶豫的部分，或告訴大三不要工作。

舊程序通常有由不再在公司工作的開發人員編寫的區域。通常這些東西變得非常殘酷，因爲新的開發人員在進行更改之前不會花時間去理解它。回顧一下。

查看只能由一個人處理的所有代碼。

回顧一切真的很複雜。

來源

2009-11-12 14:22:48

關於部門中不再存在的可怕部分或事物的觀點很好，正如首先避免這一點的人一樣。但是，我認爲沒有必要檢查一個人編寫的所有代碼，除非你有不可信的人首先編寫合理的代碼（並且恕我直言，最好他們不寫什麼都不做，或者與核心產品隔離開來 - 但如果你被這樣的人困住了，那麼是的，所有事情都會被審覈）。 – 2009-11-12 15:32:48

我的理由只有一個人編寫的代碼才能讓其他人理解代碼。否則，只要這個人離開，你就得到了你的開發人員都不熟悉的代碼。這不是一個真正的問題，你可能會發現多少錯誤，但知識如何分享。 – 2009-11-12 15:49:38

如果團隊正在使用TDD，則可以使用的代碼度量標準是代碼覆蓋率：測試覆蓋率低的類是可靠的候選對象。
像NDepend這樣的工具可以幫助您同時可視化代碼庫各個部分的複雜性，以及哪些部分取決於哪個部分。

來源

2009-11-12 17:24:43 Mathias

如何確定要查看哪些代碼部分？

回答

相關問題