Code Review Guide » History » Revision 4
Revision 3 (Amber Herold, 03/04/2010 04:44 PM) → Revision 4/13 (Amber Herold, 03/04/2010 04:47 PM)
h1. Code Review Guide
[[Purpose of Code Reviews|What's the point of code reviews]]?
[[Code development process|Where do code reviews fit into the code development process]]?
h2. The Process
# Developer writes code
# Developer checks code into Subversion
# Developer updates Redmine issue with:
## the svn revision number
## a description of the changes
## a reference to test cases or a description of how to test the changes
## set the Status to In Code Review
## assign the issue to another person to perform a code review
# Code reviewer receives an email that they have code to review
# Code reviewer inspects the changes to the code using the review guide.
## Revisions that involve complicated logic or widespread changes are better done in person. In this case the reviewer can ask the developer to do a walk through.
# If the reviewer finds a problem, the Redmine issue is updated with:
## a description of the problem
## the Assigned to field is set back to the developer and the process starts over.
# If no problems are found, the Redmine issue is updated with:
## The Status is set to In Test
## The Assigned to field is set to someone who can readily test it.
# The fly server is updated nightly with the latest code in SVN. The code may be tested at http://fly/myamiweb the day after the code is checked in.
# If the tester finds a problem, the Issue is reassigned to the developer and the process starts over.
# If the tester does not find a problem the Issue Status is set to Closed.