Ask HN: How can I run an effective code review?
2 comments
There are a bunch of methods I've used over my software career. The one I found most effective was:
1)Create a review package with the code and a brief discussion of what it does. (if its an update then we'd provide code diffs).
2) Have reviewers (at least 3) submit a list of bugs to the person holding the review.
3)The reviewer could accept the comment or flag it to discuss.
4) Then everyone got together (meeting) and discussed the ones that where flagged to discuss. Generally this made the reviews themselves not last too long (going through every line of code thats fine is boring) and some interesting discussion could be had and a conclusion reached.
5)The moderator would write a ticket in the bug tracker for the items and then when the updates are made the moderator would verify the changes were made a close out the ticket.
1)Create a review package with the code and a brief discussion of what it does. (if its an update then we'd provide code diffs).
2) Have reviewers (at least 3) submit a list of bugs to the person holding the review.
3)The reviewer could accept the comment or flag it to discuss.
4) Then everyone got together (meeting) and discussed the ones that where flagged to discuss. Generally this made the reviews themselves not last too long (going through every line of code thats fine is boring) and some interesting discussion could be had and a conclusion reached.
5)The moderator would write a ticket in the bug tracker for the items and then when the updates are made the moderator would verify the changes were made a close out the ticket.
How and why: Read "Software Inspection" by Tom Gilb
Learn by doing: Read "A Discipline for Software Engineering" by Watts S. Humphrey. Skip to the exercises at the back, as 95% of the value is in the exercises, the main book is not that good (wants a re-write).
Often, people make the mistake of only doing a code review. While this helps, much better is possible. A review will typically remove 60-80% of the bugs, but to hit 99%, you need to compound your reviews. Capers Jones shows it is easy to hit 99% bug removal if you combine several quality control reviews, such as requirements, design and code reviews.
Quality control is not one innovation, it is a combination of several innovations. Several innovations that improve quality and there are many such innovations, more than 20.
Learn by doing: Read "A Discipline for Software Engineering" by Watts S. Humphrey. Skip to the exercises at the back, as 95% of the value is in the exercises, the main book is not that good (wants a re-write).
Often, people make the mistake of only doing a code review. While this helps, much better is possible. A review will typically remove 60-80% of the bugs, but to hit 99%, you need to compound your reviews. Capers Jones shows it is easy to hit 99% bug removal if you combine several quality control reviews, such as requirements, design and code reviews.
Quality control is not one innovation, it is a combination of several innovations. Several innovations that improve quality and there are many such innovations, more than 20.
I'm planning on doing my own research into what makes for a productive code review (my initial research has turned up 'Peer Reviews in Software: A Practical Guide'), but also wanted to ask the community.
(For clarification: - this is not an 'architectural review, per-se; rather, a more narrow scope into code after the architecture has been defined, vetted and approved - this is also in addition to the user of profilers and automated code checking tools).
Thank you in advance to those who take time to respond!