1. Code Reviews

2. Everyone Should Do Them
Code Reviews Are Good
Everyone Should Do Them

3. Code Review – An activity in which people other than the author of a software deliverable, examine it for defects and improvement opportunities

4. The Benefits of Code Review
Is a process that, in conjunction with other processes, can better strengthen QA.
Developers write better code when it will be reviewed.
Code base share.
Not as hard as selling unit tests.
Fosters communication.

5. A Good Reason to Code Review
software testing alone has limited effectiveness -- the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent [1]. Case studies of review results have been impressive.

6. Other Reasons for Implementing CR
New Employees – CR can help bring new employees up to speed with company systems because it will foster communication between the code reviewer and the new employee.
Engineers On Vacation – If a single engineer owns an area of code, then the responsibility of that code follows them outside of the office.
Team Culture – Code Reviews help keep everyone engaged and helps everyone to connect on a meaningful technical level

7. How Most Companies Do Code Review
In especially medium sized to large companies, developer teams use the workflow of reviewing entire branches. It is common courtesy to review code as soon as possible as the review Smaller companies tend to do reviews that compare changesets rather than branches since feature branches are less common in small teams

8. Code Reviewer Checklist
Does the changeset look like it solves the problem/fixes the bug?
Is the code clear to read and understand.
Does the code look maintainable?
Design Flaws.
How does the changeset possibly impact on other systems?
Is the code excessively complex? Is there room for simplification?

9. Review Methods
Deskcheck – The author of a work product sends a ‘copy’ of the work item to be checked by a peer, if there are defects, the peer comments on the review item and sends it back to the author.
Inspection – The author gets his/her work inspected by a team of reviewers or a reviewer. Once inspected they aggregate all defects into a document the author can then address these issues.
Walkthrough – The author informally presents the code to a party in a meeting. Presenting the code flow and changes while leaving the floor open to suggestions. It is up to the author to take notes during this session for review changes.

10. Type of Code Review Methods
Over The Shoulder – The developer calls for a peer to look over the shoulder of him/herself and then the author does a code walkthrough.
Pair Programming – Pair programming is not only a form of agile software development it is also indirectly a form of code review.
Tool assisted inspection– The author sets up a code review between two sets of changes and requests a peer to review the changes. This is the widely preferred method.

11. What Code Reviews Are Not For
Testing.
Criticizing personal style.
Optimization*
Reviewing entire systems. There are more formal methods for that.

12. How To Request Reviews On Changesets
Team Explorer
Source Control Explorer

13. How To Request Reviews
RightClick On Project
View History

14. How To Request Reviews
RightClick On Changeset
Request Review

15. How To Request Reviews
Add Reviewer
Submit Request

20. … A Better Way

21. In Closing
In VS/TFS Code Review Comments are actually “mini threads” each team member may comment on comments to start a discussion if need be.
Code Review Alongside other QA processes can help ensure better software quality.