This is the process that I created for our team to do code reviews.
Working on a User Story
After finding the next story in priority order, assign it and the tasks to yourself in TFS and put your name on the printed card and move it over to the Working On section on our task board.
The story will now show up on the My Work tool in VS under Available Work Items (If you haven’t yet customized your Available Work Items query, jump to that post first).
Drag the user story from the Available Work Items to the In Progress Work. Now it will be associated with your change set so that it will be easy to find during a code review. When you check in your changes, this story will automatically be marked as resolved for you.
If your user story has nested bugs or other user stories, add those, too (you do not need to associate tasks). Then, when you check in, the child bugs and stories will also be marked resolved and the bugs will be re-assigned to whomever reported them.
Each night suspend your changes before you leave for the day. This will create a shelf set for you in TFS so that if your computer dies your changes will not be lost. Be aware after you resume a suspended shelf set that shelf set is deleted from TFS, so if you want to keep a shelf set around, actually shelve it.
You can create more than one suspended work sets and each remembers all of your open windows, break points, and other VS context settings, which makes it really easy to jump around between tasks like code reviews, bug fixes, and different work items.
Requesting a Code Review
Before you request a code review, make sure to get latest, merge any changes, and run the tests to make sure they pass.
From the My Work tool under In Progress Work, click the link for Request Review. This will create a shelf set of your work in progress and associated user story. We code review all features prior to checking them in.
If this is your first time requesting a review, you will need to add each team member individually via the drop down list, but the next time you can just select the “Add Recent Reviewers” link. Enter a description if you like for the review and click the Submit Request button. You can see the shelf set this creates by going to File>Source Control>Find>Find Shelf Sets.
The team will receive an email about the request, and it will appear in their My Work tool under Code Reviews>Incoming Requests.
At this point you can undo your changes and do someone else’s code review, or grab the next story that needs to be worked on. You can review the status of your code review request by vising the “My Code Reviews & Requests” list in the Code Reviews section of the My Work tool.
Remember to move the printed card on the task board over to the Code Review section.
Accepting and Completing a Code Review
It’s important for everyone on the team to participate in code reviews because it is good practice to critique others code and learn from it at the same time, it helps improve understanding of the system, and it helps the team so that some members don’t get stuck doing more than their share of reviews.
You can find reviews either in the email list, or better, in the My Work tool in Team Explorer under the Incoming Requests.
1. Suspend your current work so that VS is cleared.
2. Double-click on a code review in the Incoming Requests list.
1. If no one else is marked as Accepted you can accept the review.
a. Generally we only have one team member do the review. You do not need to decline code review requests, they will fall off your list once the initiator closes the review.
2. By clicking on the file name you can see the difference comparison. Within the comparison, you can highlight sections of code, rt-click, and add comments to the developer. You can also check the box on the right to keep track of which files you have completed.
a. If it is a long code review, you can even send comments back before you finish your review so that the developer can start working on them (not shown above).
3. You can add an overall comment on the code review. We sometimes use the format:
* Unit Tests/Coverage Complete?
* User Story COA Met?
* UCP Mockups/Text/Validations Updated?
* Refactoring/Rework Needed?
4. Make sure you always get the shelveset and test out the code in your local browser. Do a little regression testing yourself and make the QA team’s job easier!
If there are any C# changes, make sure to run all of the unit tests. Use Test>Analyze Code Coverage>All Tests to check for code coverage in new code (we try to write tests for any code we create or update).
1. Double-click on a method that is not fully covered.
2. See in red highlight the code that is skipped. Leave a comment on it if there are just a few places missed, or an overall comment on the code review if there are many places missed.
After you are finished reviewing the code select a response from the Send & Finish drop down in the code review:
· Looks Good: go ahead and check this in
· With Comments: minor changes or maybe updating a document like UCP
· Needs Work: missed a requirement, missed some tests, something caused an error.
This will send the requestor an email to let them know it’s done, and the entire team will see the comments you added in their email. It will take the code review off of your list of incoming requests, but it will not be removed from the rest of the team’s list until the requestor closes the review.
Finally, open up the user story and record your name and hours under the code review task.
Only check in code that has been reviewed, unless it is a very minor tweak or you did pair programming while writing the code.
Suspend all pending work first, then open the completed code review from the “My Code Reviews & Requests” list in the Code Reviews area of the My Work tool.
1. Click the link to activate the change set so that you get all your changes into your work space. Review any comments provided and make any changes.
a. If you have questions about the review, it’s probably best just to go talk to the reviewer at this point.
b. We don’t generally send a second review request after changes unless the requestor feels there were a lot of changes and they would like them to be reviewed. In this case, create a new code review just for the developer who originally reviewed your code.
2. Close the review. This will mark the user story as resolved and remove the code review request from the teams’ list of incoming requests.
Now that your review is closed, make sure to check in your changes on the Pending Changes tool. Also, move the printed card from the In Review area over to the Completed/Merged area on the task board.