What does code review help achieve
- It helps teams get familiarized in different areas of the code base.
- This makes each team member a generalist instead of a specialist in particular domain. No individual team member becomes a bottleneck (sick leave, vacations, etc..) as others within the team can fill in for their tasks.
- It helps establish common coding standards and gives common look and feel in the entire code base.
- Ensures that every one is generating enough documentation, writing unit tests for their classes, and functions.
The traditional way of code reviews resorts to email or some bug tracking tool like ClearQuest. In traditional code review, the reviewers have to switch between emails and bug tracking and it is kind of time consuming as well as at times a nuisance.
In my team we use open source tool Review Board. Review board is web-based and helps reviewers collaborate. It provides interface to enter comments on the code and has a summary page which lists comments from all reviewers. In addition, it maintains a history of submitted code reviews -- a tool worth exploring.
I have seen overall Agile development experience as well as productivity of scrum team improve over time by promoting code review as one of the essential attributes before a story can be marked complete/Done.
There are plenty of good resources on the web to help you and your team get started with code review.
2 comments:
As for code reviews, it completely makes sense. ReviewBoard seems to work well, but, code submitted must be small enough for someone to review easily. In some instances, developers deliver a large chunk of code and that makes it hard to review.
I think pair programming is a powerful way to get the benefits of code review. It's basically an interactive code review, so it has the additional benefits of: getting answers 'on the spot' to questions about the approach taken; having a much better chance of improving the quality of the code (the coder is much more likely to incorporate good ideas from a 'reviewer'/partner when they are actually in the process of coding the story than a week later); and being much more natural (how many people have the aptitute/inclination to analyze written code, write up decent comments, etc., vs. actually discussing code face to face).
It can be hard to sell to managers, however.
Post a Comment