marocanu2001

This is how we do code review in my actual team:

Rules:

1. No check-in without a code review (unless we paired on the task)
2. Let the others know half an hour earlier that you might need a code review (so they can put up with the thought :D )
3. Try to change the reviewer as often as possible, so you should not care that the person who reviews you is in blue or red team
4. Try to code review small amount of code, as it is easier (and this relates to another rule that we try to follow, no to leave code unchecked in over night)

Code review steps:

1. All files have to be Resharper green (unless of course you have a good valid reason to leave it orange)
2. All tests have to pass
3. Code review has to start with reading the stories that are affected by the pending code changes
4. A good thing is to also have a look at the service and data contracts affected by the code changes
5. Take the pending changes files and go through them one by one reviewing the changes line by line (even the csproject and solution files, as it might reveal forgotten unwanted references)
6. Simple things that come up in the code review can be fixed on the spot, if the reviewer is not too busy and you have enough time allocated to the code review task
7. If things that are rather complex changes come up, then the code review should be interrupted, and doe again when the changes are done.

Other unwritten rules that we follow:

1. We discuss stuff that we don’t agree until we come to a an agreed upon solution
2. If we can not agree on something, we escalate the problem with the technical leader so he can decide what has to be done
3. Whoever decided the changes, the reviewer, or the technical leader, the changes are always done
4. We don’t have a code guidelines document, so the code review relates a lot to the knowledge in the team and the known convention (lot of them discovered in the code reviews actually J )

On thing that I find handy is if the reviewer does not have enough time to attend my changes during the code review, I write in code TODOs comments with the code reviews observation which I fix before checking in.

There are several really good things that come out of code review:

-          sharing the business logic, knowledge,

-          spotting business logic problems,

-          neat code,

-          learning from the other people in the team in an informal way,

-          Reduce bugs found in testing

-          Become better friends!

posted @ Thursday, November 05, 2009 10:27 AM | Feedback (0) |