The Helpful Tips
- Limit your review to the scope of the work. An effective review is laser-focused on the problem that is being worked on. Create follow-up action items (e.g., tickets) for any out-of-scope work that you think needs additional consideration.
- Make your review specific. Address specific lines, or components in your review. Avoid making general, sweeping statements.
- Make your review actionable. If it’s not immediately obvious how to implement the change you’ve requested, leave it out of your review.-
- Deliver your review in a timely manner. The longer you wait to give your review, the more the creator will have to draw from their memory on why certain decisions may have been made. I’ve started scheduling review times with one of my co-workers so that we can go through the work together. This isn’t always possible, or desirable, but it can be effective for small teams.
- As part of your review, be sure to acknowledge the time spent by the coder on the issue. Sometimes a three line change can take hours and hours of work. Take the time to be a human being and acknowledge the time that’s been spent on the issue.
- Be thankful. Especially on open source projects where contributors are generally not *required* to submit anything. And especially at work where co-workers are sometimes forced to work on parts of the project they genuinely hate. Take the time to say “thanks”. It can make all the difference.
Six Ways to Make Your Peer Code Reviews More Effective
http://radar.oreilly.com/2013/07/six-ways-to-make-your-peer-code-reviews-more-effective.html
Types
- Over-the-shoulder – One developer looks over the author's shoulder as the latter walks through the code.
- Email pass-around – Source code management system emails code to reviewers automatically after checkin is made.
- Pair Programming – Two authors develop code together at the same workstation, such is common in Extreme Programming.
- Tool-assisted code review – Authors and reviewers use software tools, informal ones such as pastebins and IRC, or specialized tools designed for peer code review.
Four ways to a Practical Code Review
http://www.methodsandtools.com/archive/archive.php?id=66
For your convenience, here are the 11 practices in a simple list that's easy to keep on file:
- Review fewer than 200–400 lines of code at a time.
- Aim for an inspection rate of fewer than 300–500 LOC per hour.
- Take enough time for a proper, slow review, but not more than 60–90 minutes.
- Be sure that authors annotate source code before the review begins.
- Establish quantifiable goals for code review and capture metrics so you can improve your processes.
- Use checklists, because they substantially improve results for both authors and reviewers.
- Verify that the defects are actually fixed.
- Foster a good code review culture in which finding defects is viewed positively.
- Beware of the Big Brother effect.
- Review at least part of the code, even if you can't do all of it, to benefit from The Ego Effect.
- Adopt lightweight, tool-assisted code reviews.
11 proven practices for more effective, efficient peer code review
http://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/
Effective Code Reviews Without the Pain
http://www.developer.com/tech/article.php/3579756/Effective-Code-Reviews-Without-the-Pain.htm
What Makes a Good Code Review?
http://humblecoder.co.uk/blog/2010/10/13/what-makes-a-good-code-review/
10 ways to be a faster code reviewer
http://blog.codacy.com/top-10-faster-code-reviews/
Three tools that make Java code review painless and effective
http://www.techrepublic.com/article/three-tools-that-make-java-code-review-painless-and-effective/
How We Code Review
http://inside.unbounce.com/team/code-review-2
- Limit your review to the scope of the work. An effective review is laser-focused on the problem that is being worked on. Create follow-up action items (e.g., tickets) for any out-of-scope work that you think needs additional consideration.
- Make your review specific. Address specific lines, or components in your review. Avoid making general, sweeping statements.
- Make your review actionable. If it’s not immediately obvious how to implement the change you’ve requested, leave it out of your review.-
- Deliver your review in a timely manner. The longer you wait to give your review, the more the creator will have to draw from their memory on why certain decisions may have been made. I’ve started scheduling review times with one of my co-workers so that we can go through the work together. This isn’t always possible, or desirable, but it can be effective for small teams.
- As part of your review, be sure to acknowledge the time spent by the coder on the issue. Sometimes a three line change can take hours and hours of work. Take the time to be a human being and acknowledge the time that’s been spent on the issue.
- Be thankful. Especially on open source projects where contributors are generally not *required* to submit anything. And especially at work where co-workers are sometimes forced to work on parts of the project they genuinely hate. Take the time to say “thanks”. It can make all the difference.
Six Ways to Make Your Peer Code Reviews More Effective
http://radar.oreilly.com/2013/07/six-ways-to-make-your-peer-code-reviews-more-effective.html
Types
- Over-the-shoulder – One developer looks over the author's shoulder as the latter walks through the code.
- Email pass-around – Source code management system emails code to reviewers automatically after checkin is made.
- Pair Programming – Two authors develop code together at the same workstation, such is common in Extreme Programming.
- Tool-assisted code review – Authors and reviewers use software tools, informal ones such as pastebins and IRC, or specialized tools designed for peer code review.
Four ways to a Practical Code Review
http://www.methodsandtools.com/archive/archive.php?id=66
For your convenience, here are the 11 practices in a simple list that's easy to keep on file:
- Review fewer than 200–400 lines of code at a time.
- Aim for an inspection rate of fewer than 300–500 LOC per hour.
- Take enough time for a proper, slow review, but not more than 60–90 minutes.
- Be sure that authors annotate source code before the review begins.
- Establish quantifiable goals for code review and capture metrics so you can improve your processes.
- Use checklists, because they substantially improve results for both authors and reviewers.
- Verify that the defects are actually fixed.
- Foster a good code review culture in which finding defects is viewed positively.
- Beware of the Big Brother effect.
- Review at least part of the code, even if you can't do all of it, to benefit from The Ego Effect.
- Adopt lightweight, tool-assisted code reviews.
11 proven practices for more effective, efficient peer code review
http://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/
Effective Code Reviews Without the Pain
http://www.developer.com/tech/article.php/3579756/Effective-Code-Reviews-Without-the-Pain.htm
What Makes a Good Code Review?
http://humblecoder.co.uk/blog/2010/10/13/what-makes-a-good-code-review/
10 ways to be a faster code reviewer
http://blog.codacy.com/top-10-faster-code-reviews/
Three tools that make Java code review painless and effective
http://www.techrepublic.com/article/three-tools-that-make-java-code-review-painless-and-effective/
How We Code Review
http://inside.unbounce.com/team/code-review-2
