Code Review Guide » History » Version 2
Amber Herold, 03/04/2010 04:30 PM
1 | 1 | Amber Herold | h1. Code Review Guide |
---|---|---|---|
2 | |||
3 | [[Purpose of Code Reviews|What's the point of code reviews]]? |
||
4 | 2 | Amber Herold | |
5 | h2. The Process |
||
6 | |||
7 | # Developer writes code |
||
8 | # Developer checks code into Subversion |
||
9 | # Developer updates Redmine issue with: |
||
10 | ## the svn revision number |
||
11 | ## a description of the changes |
||
12 | ## a reference to test cases or a description of how to test the changes |
||
13 | ## set the Status to In Code Review |
||
14 | ## assign the issue to another person to perform a code review |
||
15 | # Code reviewer receives an email that they have code to review |
||
16 | # Code reviewer inspects the changes to the code using the review guide. |
||
17 | ## 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. |
||
18 | # If the reviewer finds a problem, the Redmine issue is updated with: |
||
19 | ## a description of the problem |
||
20 | ## the Assigned to field is set back to the developer and the process starts over. |
||
21 | # If no problems are found, the REdmine issue is updated with: |
||
22 | ## The Status is set to In Test |
||
23 | ## The Assigned to field is set to someone who can readily test it. |