花時間做同輩代碼評論？

Question

你花了多少時間做同輩代碼評論？

您是否查看全部？

我正在努力推動更多的代碼評論，我現在在工作，並試圖感受更廣泛的世界發生的事情。

Answer 1

我認爲您應該在開發早期進行高水平的評估，重點關注設計和體系結構，並在開發後期進行較低級別的評估，重點關注效率和技術。

也

When is the most effective time to do code reviews?

Code review process?

Answer 2

見雖然這將是很好的代碼審查的一切，這是很難得到人們就擺在適當的時候（特別是那些新的正式的代碼審查） 。從非正式評論開始（肩膀評論，評論簽到，同行編碼一些，...）然後在重要代碼塊中添加更多正式評論。

Answer 3

在我以前的地方，我們有專門用於代碼審查所有的新代碼的時間一大塊。這是一件正式的事情，我們通常會有幾位評論員看看每件作品。我們遵循一些指標 - 例如每小時審查250行，並將其分解成花費兩個小時左右的區塊。對於某些代碼片段來說，這可能是一個漫長的過程。我有一個應用程序有大約18K LOC，所以你可以想象幾個小時致力於查看。

回想起來，我不相信審查周總是花時間。當時，我們沒有進行單元測試，並花了很多時間在Rational Rose中處理UML圖表。我不相信這樣做也是值得的。

在我的店裏，我們有一個不太正式的代碼審查過程，但我確實在內部測試了很多，大概有3倍的測試代碼，我做生產的代碼行。 是等式中的一部分，至少對我來說，這似乎是最好的回報。我想，通過一系列的測試來驗證廣告中的事情是非常重要的。但是，這是一些人不會購買的理念。

我們處於代碼相互定期寫的很好，但我們沒有正式的代碼評論。我認爲這是一種文化事物，我誠實地認爲，儘管缺乏正式的審查流程，但我們在商店寫的代碼比我們以前寫的東西更清潔，更正確。這可能是我們在這裏開發的開發人員的素質。我們只是在這裏做了不同的事情，看起來工作得很好。

但是，如果你打算做代碼評論。他們的預算時間。不要讓它們成爲事後的想法或者試圖將它們塞進某個時間表。開發人員可能會對代碼做一個相當淺的研究，看他們是否因時間緊迫而超負荷工作，試圖完成「真正的工作」。當我們沒有很好地預算它時，我們最終沒有得到任何效用。

只是我的想法。

Answer 4

1）代碼審查必須計劃和時間表accomodated。

2）代碼概述/預視功能就是我們要做的。即代碼的作者首先解釋了他要進行審查代碼的功能。算法級別。 這爲審稿人提供了一個好主意和背景，他在實際代碼審查期間獲得了對代碼的各種觀點，即功能視角，優化（執行時間/內存）視角，可移植性，可讀性

3.）只需要審覈2小時的代碼。我們通過反覆試驗發現，2小時是一種極限情況（不少於，不多），保持評論質量/評論意見

4.）將代碼發送給評論者2-3天根據代碼的複雜性/ LOC，在預覽發生之後進行。

5.）審閱者可以在離線狀態下進行審閱，並參加他們的評論。

6）在會上筆者聽取各審查意見，接受/與相關的原因

這個過程一直擔任我行至今拒絕。

-AD