In my previous article on Peer code reviews I mentioned I didn't like the idea of insisting on a code review before checking into source safe. Well, I still don't like it, but I have discovered one reason which supports the idea.
If developers are left to code and check in/check out as much as they like, and are only required to have a code review before a periodic label, then it becomes tempting to write large chunks of code before getting a code review. now if a reviewer, by definition another developer, is asked to review pages and pages of code, then as the reviewer is also undoubtedly a busy person, they will simlpy use the page down key to scan over vast amounts of code and not really look for anything in particular as to look intently at each peice of code requires significant effort. I guess the conclusion is review early, review often. However, I still believe that there should be very few barriers to checking in building code.
Subscribe to:
Post Comments (Atom)
Posts
What about a system where you check-in anything you like, but to go on the main trunk, you need a peer-review?
ReplyDeleteAnd then whenever you do a check in, an email or rss, or something is sent for the person responsible.
It would be a cool thing to do if you could just assign rss feed for a particular area of the application and then one person (or several) would subscribe to it and to go on the main trunk you would need approval from this person(s).
I beleive that the concept of "shelving" in Visual Studio 2005 Team System: Enterprise-Class Source Control and Work Item Tracking fixes this whole problem quite nicely.
ReplyDelete