Home
Blog
Obfuscation
Reversing
Reflector
Archive
Contact
Subscribe
Jason Haley
Ramblings of a .Net developer
.ver 3:0:0:0
Good code review process?
by
Jason Haley
22. July 2008 13:26
I'm trying to find some good practices for code reviews, anyone have any tips or good practices they would like to share?
Comments (8)
|
Post RSS
|
Categories:
Tags:
Related posts
Html Encoder, Url Encoder and Xml Encoder
This is a link for me to find the htmlecode.html page on my site that I put together a long time ago...
Code Camp 14 Slides and Source Code
Last weekend I presented three talks as the New England Code Camp 14 on three completely different t...
Book Review: Obfuscating .NET: Protecting your code from prying eyes
Book Review Obfuscating .NET: Protecting your code from prying eyes By Dan Appleman Back in 2...
Comments
Alfred Thompson
(
website link
)
July 22. 2008 13:45
Don't companies send developers out for code review training anymore? I had to take a pretty serious course in it in my days as a full-time developer. A couple things I rememeber were.
Someone takes good notes and it is NOT the person whose code is being reviewed. Someone else reads the code and moderates the discussion. The person whose code it is should be answering questions not running the review. Also the whole process has to be non judgemental. If someone starts beating up on the programmer the moderator needs to step in and stop it. The experience should be a learning one not a painful one. Well not any more painful then required.
Reviewers should read through the code before the meeting. They can bring questions if they want but not ask them until the meeting gets to that part of the code.
If there is a manager in the meeting they should be there because of technical expertice not to evaluate any of the individuals in the meeting.
Lancelot Dunnehoo
July 22. 2008 15:21
I'm quit interested in this as well. I've been tasked with getting code reviews going on my current project and I have no clue how to do so without coming off as a code nazi.
Richard Gardiner
July 22. 2008 19:07
I have found this book is good (and free) -
www.smartbear.com/codecollab-code-review-book.php
" rel="nofollow">www.smartbear.com/codecollab-code-review-book.php">
www.smartbear.com/codecollab-code-review-book.php
" rel="nofollow">www.smartbear.com/codecollab-code-review-book.php. Don't know anything about the software from the company but the book is really only pushing code reviews not their software.
We've only just started doing code reviews but so far they've been working well. No confrontations yet but not everyone on the team has been through the process yet!
One minor addition I did add, was to link the need for a code review to a basic points system. Adding points for complex code and core libraries, subtracting points for pair programming - once it hits a threshold, a code review is triggered.
Phil Denoncourt
(
website link
)
July 23. 2008 05:08
Hi Jason,
I put together a few posts on my blog a year ago on this kind of stuff.
blog.philknows.net/CategoryView,category,Code
" rel="nofollow">blog.philknows.net/CategoryView,category,Code%2BReviews.aspx">
blog.philknows.net/CategoryView,category,Code
" rel="nofollow">blog.philknows.net/CategoryView,category,Code%2BReviews.aspx
Phil
Jason Haley
(
website link
)
July 23. 2008 06:54
Alfred: Thanks for the info. It is kind of odd that code reviews aren't more popular these days.
Richard: Thanks for the pointer to that book, I'll check it out - especially since it is free
Phil: Thanks for the link, I'll read it today.
Travis Illig
(
website link
)
July 23. 2008 08:40
What I've found when trying to come up with a code review process is that there are a lot of different things that people try to accomplish in a code review that may not actually match what your definition of "code review" is. Might be good to level-set on what everyone wants out of the process before defining it. Some of the things I've found people want:
* Design review
* Architectural review (in context of the code that was written)
* Education for junior developers
* XML API documentation review
* Unit test review
* Integration test review
* Interface/contract review
* Detail-oriented line-by-line review of code (make sure i's are dotted, t's are crossed)
Some of these, to me, belong in code review, and some don't. Some people also think a code review should be something that happens before code gets committed to the main production codeline, some people think it can happen after that - scheduled as a separate task with a separate priority.
Oh, and think about some of the "non-functional requirements," too. Are you working with a distributed team? Getting everyone in a room, even a virtual room, all at the same time may not be feasible.
In the past I've used the Smart Bear "Code Collaborator" product and like it. It addresses the points that I feel should be in a code review and answers a lot of the non-functional things like scheduling and team distribution. The new 4.x version of the product is superb for working with Subversion, too.
Jason Haley
(
website link
)
July 23. 2008 19:26
Travis: Very true, hadn't really thought about that.
Gary C.
July 29. 2008 09:10
Code reviews usually don't happen unless a scheduled block of time is planned in advance for the meeting(s) (hopefully at the start of the project), all participants are available to attend, reviewers are given time to review the code (each reviewer is assigned to look for a specific problem to cover different scenarios) etc. So it's a big scheduling problem plus the problem when the developer under the microscope gets defensive. You definitely need an experienced moderator.
I'd stick to unit tests and let everyone else learn how to be an architect on their own time.
Comments are closed
TextBox
Search
Include comments in search
Tag cloud
Category list
Azure (7)
BlogContent (1)
Community (11)
Independent Consultant (9)
Innovation (1)
Interesting Finds (813)
Obfuscation (1)
Open Source (1)
Reflector (4)
Silverlight (1)
Utility (1)
Log in