Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm pretty new to code review, and I feel often overwhelmed by incoming changes.

I mean when there are serious code changes, coming from several developers I tend to accept everything without reviewing the whole, especially when I have lots of stuff to finish up.

What are the techniques to help in being efficient in this area ?

share|improve this question
add comment

4 Answers

up vote 4 down vote accepted

Plan code review for the first thing in the morning before you do any of your other projects. If you have several developers passing their code to you, then it will likely take you a few hours. It helps if the developer is there explaining why he did something the way he did. You should try to dedicate the time to the code review. If you are feeling overwhelmed, then you should go to your manager and tell him you need to lighten your workload because you can't handle it. Don't feel pressure to finish other projects because you are being overloaded.

share|improve this answer
add comment

For doing code reviews, you should be an expert in that code base. So you should have a fair idea of critical parts of the code. For example, details of logging may not be as important as say a new data structure being introduced. So if you have to skim some parts, skim over the less critical parts.

In languages like C or C++, starting with header file changes give an idea of significant changes. The key is data structure changes. New data structures added, new fields added to existing data structures etc. You can ask the implementor for details of data structural changes.

Also being an expert in the code base, you should have a fair idea of newbie mistakes that can happen. You can even document such easily made mistakes and use it as a check list. Others also will find it useful. Maybe it can be part of an internal wiki.

share|improve this answer
    
How to separate critical changes from cosmetic one when you receive several lot of 10 to 20 files ? Scanning the changes already takes precious time... –  Guillaume May 4 '11 at 14:14
    
@Guillaume - The author(s) of the change should document the reason somethign was done until the point it is accepted or review by you. This allows you quickly find cosmetic changes or functional changes. –  Ramhound May 4 '11 at 15:09
add comment

Are there code review guidelines in your workplace? How closely are you conforming to them? How is code review distributed - are you - by merit of being new/more popular/less popular/less unpopular etc - getting more than average code review? Is it possible that more of it is starting to come to you because you're seen as more lenient?

My policy would be to timetable your day for a while - set time aside for code review tasks in particular and try not to exceed it. Schedule it if you like, and keep to that schedule.

share|improve this answer
    
No guideline, no tools, no distribution: it is more a good practice set up by developers. Main idea is to proof reading incoming changes. –  Guillaume May 4 '11 at 14:05
    
@Guillaume: I think it's time you formalize your code reviewing process and run it by your team and your management. Everyone should be aware of what is being looked at, how it will be done and how it benefits everyone, which can justify the amount of time it takes to do. –  Bernard May 4 '11 at 14:41
add comment

Code reviews can be done in many ways, ranging from a simple reading of what one of your developers has written to a formal review where you (and a board of peers) are being guided through the changes.

While I believe strongly in an occasional formal code review, it sounds like you're going for an informal code review when code is checked in, is that correct?

Given that scenario, it has been mentioned before that there are some best practices and human factors that you can use to avoid being overwhelmed:

  • Define a specific time to do code review, such as first thing in the morning, for x hours. Preferably not more than 2 hours at a time, as it can get tiring very fast and your efficiency wanes quickly.
  • If you have too much work, tell your boss about the time you have set aside for code review and have them adjust the workload and estimates accordingly.

Human factors aside, do you currently use tools to assist in your code review? Some tools and best practices could include:

  • A diff tool, showing you clearly what changes have been made from one version to another. Eclipse even has a compare view built in that makes reviewing changes very easy.
  • Enforce comments in version control. Make sure everyone mentions on what they have worked on and gives an overview of their changes so that you do not waste time looking elsewhere.
  • Usage of code review tools. I recall Fogbugz had Kiln (but I have not used it in a long time) and Atlassian has Crucible, which can assist in structuring and distributing code review duties. A quick search online might help you find a tool to help you. However, remember that suck tools take time to learn and to adapt to, and will most likely not save you any time at first, especially if you are in the middle of a project.
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.