Make code reviewers life easy
Code review is a very important aspect in a software developement lifecycle but its not given due importance unfortunetly in most cases. General concept in the industry is that code review is for finding bugs, design flaws and coding style non-adherence issues. But the most important aspect of a code review I believe is knowledge transfer and sharing information with peers who may have to support the code they are trying to review.
What I learned from all these years of development is that - take code review seriously. Make sure you are well prepared for the review presentation and make it a point that either you have convienced the reviewer about the correctness of your code or understood what reviewer is suggesting the changes. Here are the list of things to keep in mind before you try to setup a code review.
1) Is your code ready. Does it even complie? Okay this is not silly, I have reviewed code myself which will even not compile. Usually happens when a third party/consultant writes a code and sends out the packet via email for reviewing. Please please make sure that it complies.
2) Have you unit tested your code base before review? This is next most important thing to do before review. Note that your reviewers are not only techincal director but some times end users who may have to integrate with the code base. So make sure you don't have many TODO's in the comments. Ideally you want to have a JUnit testcase with all the uses cases running before the code is reviewed.
3) I usually like to go QA lead for the project and handoff the JUnit testcases I prepared before review and ask him to run and make sure it works. Don't be surprised if QA folk comes back with couple of critical bugs which you would have never caught yourself.
4) Don't give a chance for reviewer to comment on coding style. Most of the oragnizations have thier own coding standard if you don't have one follow java coding standard. Don't take coding style lightly as it shows your seriousness for the coding and project overall.
5) Give reviewer enough time to prepare for the code review. Well most of the time reviewer don't prepare and just show up. But that is thier problem. Make sure that such reviewer don't get a chance to say , "hey you did not send out the code packet in time".
6) I can't stress this more but make code review easy for reviewer. Attach class diagrams of code being reviewed , no pointers to old design documents. Firstly because reviewer don't look at pointer , secondly old design diagram in most cases will be outdated.
7) Use merge tools. This is a very helpful way to make your reviewer happy so they don't ask questions trying to figure what changed and what not. I found Araxis code merge tool to be pretty good for such purposes. Integrates well with Clear case and other popular version control system.
8) Take notes and make sure you understood what changes reviwer changes.
Cheers
Anand
What I learned from all these years of development is that - take code review seriously. Make sure you are well prepared for the review presentation and make it a point that either you have convienced the reviewer about the correctness of your code or understood what reviewer is suggesting the changes. Here are the list of things to keep in mind before you try to setup a code review.
1) Is your code ready. Does it even complie? Okay this is not silly, I have reviewed code myself which will even not compile. Usually happens when a third party/consultant writes a code and sends out the packet via email for reviewing. Please please make sure that it complies.
2) Have you unit tested your code base before review? This is next most important thing to do before review. Note that your reviewers are not only techincal director but some times end users who may have to integrate with the code base. So make sure you don't have many TODO's in the comments. Ideally you want to have a JUnit testcase with all the uses cases running before the code is reviewed.
3) I usually like to go QA lead for the project and handoff the JUnit testcases I prepared before review and ask him to run and make sure it works. Don't be surprised if QA folk comes back with couple of critical bugs which you would have never caught yourself.
4) Don't give a chance for reviewer to comment on coding style. Most of the oragnizations have thier own coding standard if you don't have one follow java coding standard. Don't take coding style lightly as it shows your seriousness for the coding and project overall.
5) Give reviewer enough time to prepare for the code review. Well most of the time reviewer don't prepare and just show up. But that is thier problem. Make sure that such reviewer don't get a chance to say , "hey you did not send out the code packet in time".
6) I can't stress this more but make code review easy for reviewer. Attach class diagrams of code being reviewed , no pointers to old design documents. Firstly because reviewer don't look at pointer , secondly old design diagram in most cases will be outdated.
7) Use merge tools. This is a very helpful way to make your reviewer happy so they don't ask questions trying to figure what changed and what not. I found Araxis code merge tool to be pretty good for such purposes. Integrates well with Clear case and other popular version control system.
8) Take notes and make sure you understood what changes reviwer changes.
Cheers
Anand
posted by Anand @ 12:13 AM
0 Comments:
Post a Comment
<< Home