Code Reviews Mindmap

Code reviews. Very helpful if done right, completely useless if done recklessly.

Below you will find a mindmap of "code review" (using Xmind). I simply sat down and tried to gather everything related to code reviews. Hopefully you will find some food for thought here.

Click to see larger version.

Some comments:

  • I knew one team lead (hello Marcin! :) who had a very nice system of publishing code reviews by email to project's mailing list. He believed (and had some good results to support this belief) that by doing such "public" code reviews he educates the whole team, and not only the author of the particular code. It worked for him and his team pretty well!
  • Marking code with TODO and FIXME during the review works pretty well for me. Nope, I haven't used gerrit or any other tool like this yet.
  • IMHO code review should be a part of Definition of Done - no task is finished until someone else checked the code.
  • I don't like the idea of team lead doing code reviews for the whole team. He has probably no time for this. The other thing is that some people find it hard to discuss with your "boss" (so they will follow blindly what the reviewer says). I like much more the idea of peer reviews. Even if some junior guys are not capable of performing code reviews properly (at least from the very beginning).
  • There is a great discussion regarding code reviews here: http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-d... Worth scanning through.

Code review is a so necessary

Code review is a so necessary process during project. But, very few school can teach students to do code review. Why? This is because the teachers don't do project.

Code review has much advantages, not only find bugs, but help to learn from each other.

- Medical Articles | health articles | fitness articles

Some comments: The advantage

Some comments:

The advantage is not just finding bugs, but finding bugs earlier than later.

I'd also suggest that SmartBear Code Collaborator is another useful tool on par with, and superior to, Crucible. I'm a customer, not an employee, of SmartBear.

By using either CC, Crucible, or similar tools, you can often avoid the need to have a physical timeslot to do a review, as much of the review can be done asynchronously in discussion threads in the tool. When or if the physical review happens, it's more of a summary instead of a raw review.

I don't know about Crucible, but in CC the reviewer can file defects, and only the reviewer can close the defect, which hopefully they would only do after they see the fixed revision uploaded to the review.

David M. Karr (anonymous replies creep me out.)

sounds interesting

Hello David,

I admit I haven't used such tools. The teams I worked with never had a very detailed process of code reviews. We have them in our Definition of Done, and they are done like "hey, who wants to check issue #123? maybe you XYZ, huh?".
Probably we could benefit from the tools you describe, but there is also something very nice about simply talking about the code with your fellow developers without the barrier of tools.

Great, but missing social/attitude side

Great map, but I find one key aspect missing: social/cultural requirements. In some environments code reviews may lead to stalemates ("I won't check it in, it should be different!"), long quarrels etc. You can learn tools for analysis and get better at reading and maintaining code, but very often you can't fix the culture (and that can kill).

lucky me

Hello Anonymous,

I must be a lucky guy myself, cause I have always worked with people who tried to learn from code reviews, not fight against them. But I can believe the things you talking about can happen, especially if there is a tension already in the team.

Great Map

nice map worth taking a printout and attaching on desk. Code reviewer should also be some one who has extensive domain knowledge, who can think through common issues well before. See here for more code review best practices

thanks for the link

Hello Anonymous,

right, we should all keep an eye on the business purpose of things we implement - also during code reviews.

Please comment using