Monthly Archives: April 2012

Peer Code Review with Team Foundation Server 11 – Part 5

Back to Part 4

Action: Requester Closes the Review

Back in the requester’s Code Review pane, I can see the status of each reviewer’s responses and their finished response (e.g. Looks Good).

At a glance the requestor can see any overall comments made. (I like that you can see how long ago a comment was made as well.)

If a requester wants to inspect inline comments, they can click the file name to open the diff tool. Commented code is highlighted in yellow.

The requester can continue to make changes and submit new code reviews. As long as they haven’t committed any code, the reviewers will still be comparing all proposed changes to what’s stored on the server. (See example screenshot below.)

Under the Close Review hyperlink, the reviewer has the option to click Close or Abandon to finalize the code review.

Closing a code review sets the State and Reason on the Code Review Request work item to Closed. Any Code Review Response work items remain unchanged.

Abandoning a code review also sets the State and Reason to Closed, but the Closed Status field is set to Abandoned. Linked Code Review Response work items also have their State and Reason set to Closed, but the Closed
Status is set to Declined and a Closing
Comment indicates that the requester closed the code review.

My opinion

I think this is a great feature. There is a lot of value in having code review integrated within the developer’s IDE. Code reviews should be easy and encouraged. Frequent code reviews not only catch bugs and improve maintainability, but they reduce the all-too-common ego that comes with the craft of writing software. Today’s serious application development is a team effort and the ownership of any new feature or bug fix should not be on one individual.

Here are some other features I’d like to see considered for future versions. Some of these could probably be done by editing the work item types and/or utilizing the TFS API.

  • Mouse-over comments – I think it would be a better experience to be able to mouse over the code in the diff tool and see the comments.
  • Configurable enforcement – Some organizations want every change to an application reviewed prior to release. It would be nice to have some setting to require code review. E.g. One setting might enforce a closed code review prior to check-in. (I’m going to try to develop this type of enforcement for Part 6 in the future.)
  • A Reviewers group – Some organizations designate one or more individuals as mandatory reviewers. It might be nice to have a list of these reviewers that could somehow designate a change as reviewed. The add recent reviewers capability is similar, but an organization may want more control over this group.
  • Review merged changesets – I’ve always tried to encourage my development teams to check-in code very frequently. This keeps changes atomic, but I may not want to overburden reviewers with incomplete thoughts so it would be helpful to select multiple changesets (or by label).
  • Lync – It seems like Lync could be incorporated to provide richer conversation options. At its simplest, I could tell if a reviewer or requester were online. It’d be interesting to somehow attach those conversations to the code review as well.
  • Additional reporting – It’s probably fairly straightforward to build with Excel hitting the data warehouse, but I think it would be more usable to right-click a file and not only see its version history, but all of the associated code reviews as well.

What do you think? Did the product team hit the mark with this? Do you value code reviews by your peers? How do you execute code reviews today?


Peer Code Review with Team Foundation Server 11 – Part 4

Back to Part 3

Action: Reviewer Makes a Comment

The reviewer doesn’t need to accept the code review to look at the code, but once they have accepted, the requestor is most assuredly assuming they will.

The reviewer can click the name of a file and the diff tool will open to show the original file on the left and the proposed changes on the right.

There is a checkbox next to each file that allows the reviewer to track which files he/she has been through.

There are three primary ways to communicate through the code review tool.

  1. Comment at line-level – The reviewer can highlight any code in the diff tool, right-click, and select Add Comment. This will provide the requestor with the comment and its associated line number.

  1. Comment at code review-level – The reviewer can click Add Overall Comment at any time and enter more general comments on the code review.
  2. Respond to requestor comments – The reviewer can respond to requestor comments by clicking Reply and create a conversation chain. These replies are added to the overall comments.

Note that comment boxes support multiple lines and carriage returns. This means you have to hit Ctrl+Enter or click Save to save the comment. You can edit or delete comments as well.

All comments will remain unsent until the reviewer is ready and either clicks Send Comments or Send & Finish. Additional comments can still be added at any level after sending comments or finishing the code review.

Finishing a code review changes the State and Reason of the reviewer’s Code Review Response work item to Closed.

The Code Review Request work item is updated to reflect the reviewer’s comments. You can see this in the History field of the work item form, but you cannot inspect the actual comments. To see the comments, you must click the hyperlink at the top of the work item form labeled Open Code Review in Team Explorer.

Proceed to Part 5

Peer Code Review with Team Foundation Server 11 – Part 3

Back to Part 2

Action: Accept (or Decline) the Code Review

If reviewers have their email notifications set up to alert them to assigned work items, they will be sent an email for code reviews as well.

Getting the email isn’t necessary though. The list of any code reviews assigned to the reviewer will be displayed in the Code Reviews & Requests section of the My Work hub.

To examine a code review, the reviewer double-clicks a code review from the list.

Before accepting the responsibility of a code review, he/she may want to see what they are getting themselves into. There is quite a bit of information in the Code Review pane.

First, is the ability complete the review. The reviewer can simply click Send & Finish to close their review and post all of their comments back to the requestor. An easily overlooked option is to click the arrow next to Send & Finish and choose a quick comment (Looks Good, With Comments, or Needs Work) to summarize the changes.

The reviewer can click the View Shelveset hyperlink to peruse the shelved changes associated with this code review.

The Shelveset Details pane allows the user options like Unshelve Changes, Delete Shelveset. Unlike some other code review tools on the market, this one allows the reviewer to stay in Visual Studio so they can pull down the shelveset and run through the entire solution with full ability to compile, debug, execute unit tests, etc.

The Actions menu allows the reviewer to open the associated Code Revew Request work item. Doing so highlights another area where code review work items differ from others since the work item form is entirely read-only.

Reviewers can add other reviewers to the code review by clicking the Add Reviewer hyperlink.

Whether the reviewer utilizes any of this information or not, they should Accept or Decline the review which lets the requestor know if they need to search out another reviewer.

Accepting the code review changes the State and Reason of the reviewer’s Code Review Response work item to Accepted.

Proceed to Part 4

Peer Code Review with Team Foundation Server 11 – Part 2

Back to Part 1

Action: Request a Review

Although the code review feature is work item-based, you cannot create these work items as you would a User Story or Task. There are two means to initiate a code review:

1. Requester must have some pending changes in order to request a review.

2. Requester selects a committed changeset from Source Control Explorer.

NOTE: Because I believe it will be the more popular means of requesting a review, the first method is the workflow this post will focus on.

In My Work, under In Progress, click the Request Review hyperlink to navigate to the New Code Review pane.

The reviewer must enter at least one reviewer, but he/she can enter as many as they would like.

Requesters can also choose from a list of recent reviewers by clicking the arrow next to Add Recent Reviewers.

The Subject field will default to the Title field of the In Progress task, but it can be edited to provide more clarity.

The Area Path field can be used to associate this code review with a particular team, product, or component.

The Description field is not required, but it can provide some guidance to reviewers to ask a question or focus on a particular area.

Notice the code review is already associated with the In Progress work items to provide additional context to reviewers.

Don’t forget to click Submit Request before navigating away from this pane!

The pending changes will be automatically shelved.

At this point, a Code Review Request work item is created with the Title field matching the Subject entered. The initial State will be Requested with a Reason of New. The Assigned
To field will be the requester.

Child Code Review Response work items will be created for each selected reviewer. They too begin with a State of Requested and a Reason of New. However, each work item’s Assigned
To field is set to the name of the reviewer. At any point in time, the requester can add additional reviewers too.

Proceed to Part 3

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.

Update to VS 11 Beta

For those of you running Visual Studio 11 Beta, an update was just made available for download. You should get notified within Visual Studio and you can get the release notes here.

Besides a handful of performance and stability fixes, there are a couple of functional fixes when grouping tests in the new Unit Test Explorer and IntelliTrace now captures web request information!

Have fun!

Funniest April Fool’s joke I’ve seen!!

One of my colleagues sent out a link to this very funny video that almost looks plausible.

This one is pretty good too: