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.
- 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.