Peer Code Review with Team Foundation Server 11 – Part 1
I’ve always felt code reviews by one or more of your peers should be a critical part of software development. Most importantly, it’s a great way to learn – not only for the reviewer, but for those with the opportunity to participate in the review. It’s great to see how others approach a problem and since application development has become such a team effort, it’s good to know what changes others are making that could affect your effort immediately or down the road. In some organizations, code reviews are a required part of the process with the purpose of reducing bugs and/or increasing maintainability.
Code Review Request work items have a very simple workflow. They begin as Requested and can be Closed. Period.
Figure 1 – Code Review Request workflow
Code Review Response work items are a bit more complicated due to a third state option. If a reviewer declines a code review request, they can skip the Accepted state. They can also be Reactivated from a Closed state.
Figure 2 – Code Review Response workflow
The rest of this series will focus on the user stories in our code review feature:
Part 2 – As a developer, I want to request a code review so that selected reviewers can comment on my proposed changes.
Part 3 – As a reviewer, I want to accept or decline a code review so that I can alert the requester to my desired participation.
Part 4 – As a reviewer, I want to comment on the proposed changes so that my feedback is communicated to the requester.
Part 5 – As a requester, I want to read and respond to any comments so that I can complete a code review.