| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Making code reviews easier with Review Board
Making code reviews easier with Review Board
Posted Jan 18, 2008 1:19 UTC (Fri) by quotemstr (subscriber, #45331)Parent article: Making code reviews easier with Review Board
I've heard many say that code reviews are best done with pen and paper so that the mind sees the code in a different context and hopefully sees more bugs. We're instituting code reviews at my job (pushed by me), and so far, we've planned on using the pen-and-printed-diffs approach. Any suggestions on how to best go about code reviews when you have the luxury of everyone being in the same physical place?
(Log in to post comments)
Review pointer
Posted Jan 22, 2008 23:10 UTC (Tue) by Max.Hyre (subscriber, #1054) [Link]
Any suggestions on how to best go about code reviews when you have the luxury of everyone being in the same physical place?Make sure everyone has already reviewed the code before the meeting. People should show up with their lists of comments, ready to start talking.
The alternative (everyone is reading the code for the first time) leaves people
- distracted from understanding one section of code by someone starting to discuss another,
- thinking a section is OK because it's been
discussed by others,
and, probably worst,
- unwilling to hold things up because they want to look more deeply into something that the rest are already finished with. It takes guts to say ``Wait a minute...'' when everyone else is ready to go on to the next page.
Such ``show and go'' reviews are much better than nothing, but it's a vast improvement if each reviewer has gone over the code before the get-together.
Making code reviews easier with Review Board
Posted Jan 24, 2008 9:16 UTC (Thu) by renox (guest, #23785) [Link]
[[ Any suggestions on how to best go about code reviews when you have the luxury of everyone being in the same physical place? ]] Having done some group review of code or specification, I think that there are two important points: - break the document to review into manageable thunk (otherwise the end is rushed) - have someone in charge to ensure that one particular point doesn't take 90% of the time. If one point takes too long, it should be put aside with someone in charge to ensure that it is resolved (a dedicated meeting can be done).