Code review approaches [closed]

Question

Just going out on a limb here. Is doing a code review by sampling a few classes and units of code by a developer good enough to judge what he has done wrong to provide inputs? This is just in case you are pressed for time and can't review every single line written by them. I am working on the assumption that the developers might duplicate the same type of mistakes everywhere. Is this an effective approach? or partially effective, or not at all effective?

What other approaches are better? Sitting with each developer who has written the lines of code and asking them why they did that a particular way? or doing it by yourself and then sending a synopsis of your findings via email?

How do you approach reviewing code written by junior developers/peers when you have to review all the code base in a typical 15 day sprint?

Answer 1

Aiming for 100% code review of every line of code produced is probably unrealistic. Doing so would require a great deal of developer/tester time, reducing the effort spent on actually producing software. There are two things that you need to decide upon - what you want to review and how you want to review it.

What you review depends on a lot of factors. For example, you probably want to review the code that is involved in your most critical features. If you have a new developer on the team, that's some other code that you want to review to ensure the new developer is following coding guidelines and is producing a quality product. Once you have a methodology for determining how important it is to conduct a code review on a given unit, that methodology should be documented (perhaps as a checklist) so that others can evaluate their own code and know when to ask for a review and when it's not necessary.

There are many methods of conducting a code review. They range from pair programming to formal inspections. The methods used often depend on how critical the code is. If it's a life-critical block, then perhaps you want to use a formal inspection process, with multiple reviewers who read the code, annotate it, then have a meeting with the developer. If it's a bug fix produced by a new developer, then one other person sanity checking it might be sufficient.

For your specific case of reviewing a new developer's code, I would use a lighter weight approach, such as an over-the-shoulder code reading. If you have the people, pair programming might be better, since it would not only accomplish the goals of ensuring they aren't making mistakes, but also let them work closely and get to know a member of the team. I would definitly try to go with something more personal, though, with human interaction and not just an email, to improve the team-bonding experience when still accomplishing the goals of the review.

The best approaches vary by team, but if you consider your options with regards to the criticality of the code, the purpose of the code review, and how much time and money you have, you can come up with a code review process. Also note that the same general guidelines can be applied to any work product - requirements, designs, user manuals...