As the Visual Studio family of products (Visual Studio, TFS, Test Professional) nears its 2012 release, I thought I’d bring some short hits – tidbits, if you will – to my blog. Some of these are pretty obvious (well-documented, or much-discussed), but some may be less obvious than you’d think. Either way, it’s always good to make sure the word is getting out there. Hope you enjoy!
There’s been great hype about the new built-in code review capabilities in TFS 2012, and for good reason. The process is easy, effective, and most of all, audited.
But did you know that “My Work” is not the only place from where you can kick of a code review? You can also do a review on code that’s already been checked in. Go to the file in Source Control Explorer, then view its history. In the History window, right-click on the changeset/revision and select “Request Review”.
This will load up the New Code Review form in Team Explorer:
Notice that it not only brings in the files from the changeset (5 of them, in this example), but also any work items that were related to this changeset as well. The check-in comments are used to populate the title of the code review, as well as the optional description.
Off ya go!
Steven, I have two follow up questions about TFS Code Reviewing:
1. Is it possible to request a code review only for some of the files in the change set? (I might have changed spelling in one of the files, which has no relevance to the work item I was working on)
2. After my peers have reviewed my code and posted some suggestions, is it possible to submit another changeset to the same code review? It makes sense to make bug fixes part of the same code review.
Thanks for your note!
1. As far as I know, this feature will include all files in a changeset, not a subset. Perhaps what you can do is include a note in the description of the code review explaining which specific files to look at? Hopefully the changed files that are relevant will be somewhat more obvious than the others if the work item to be reviewed is well-built. And of course if there's no work item associated with the changeset you'd want to include some instructions in the review description anyway!
2. If I read your question properly, you'd need to submit a second code review. In my opinion, the design of a code review in TFS is to target a specific CODE change. So if you have a second changeset to review, that warrants a second code review. Assuming the two changesets are associated with the bug, you should be able to still see all the reviews associated with the bug, which is the most important thing from a visibility and acceptance perspective. While this does add a couple extra steps, it does create more specific auditability.
Hope this helps!
Wow, really nice
I have a doubt like, I have made a code review task for a particular set of files. But sooner I identified that a few more modifications are yet to be done. So I did that also. But is it possible to include those modifications in the existing code review task itself. The files are same. Or the only option is to start a fresh code review task ?
Your best option is going to be to run a fresh code review. Code Reviews are for specific code changes, and are tracked accordingly. If you modified a file a second time (same file, just a content change), that's still a modification which, in my opinion, invalidates the original intent of the first code review. So a second code review should be used.
Thanks for reading!
Is there a way to print the code review into a report? I have a need to print a report or export to word/pdf for all code reviews in a release. Yeah for regulated industries!
A poor-man's way to print/report on code reviews would be to use the Excel integration with TFS work items.
1. Create a work item query (tree of work items) that shows your code review requests and all the linked code review response work items.
2. Run the query, and select to open the query in Excel (if you set up the query as a "Tree of Work Items" -type query you'll get a hierarchical result set in Excel).
3. Save the Excel report (do any formatting if you need to) as a PDF, or whatever.
When looking at your query results in Visual Studio, you can also select a subset of work items and dump those to Excel also (if you need to report on just one or a few code reviews).
I'm hoping to do a quick blog on this in the next few days, time-permitting.
I hope this helps!
Hi When you create a new code review request.. and open the same work item in using TFS queries we don't find who is the reviewer.. instead we have context owner and it has some random generated value.. can you give me idea where to find who is the reviewer
When you create a code review, a Code Review Request work item is created (as you know). For each person you've requested as a reviewer, TFS will also create a Code Review Response work item, linked as a child to the Code Review Request.
For example, if I create a Code Review Request named "Review this", and add two people (Dave and Sam) as reviewers, I'll get this (forgive my shorthand):
Code Review Request - Title=Review This, Assigned To=Me
\---- Code Review Response - Title=Review This (Dave), Assigned To=Dave
\---- Code Review Response - Title=Review This (Sam), Assigned To=Sam
So if you want to see who the reviewer(s) is/are, simply create a new query (not flat, but "Work Items and Direct Links") that shows parent Code Review Requests and any child Code Review Responses.
Hope that helps!
Seems like at least the dev has to request a code review from me, if I do that step myself I’m also the requester of the review.
So how can I add code review comments if I come from outside and look over the code in general from time to time and don't get requests by devs?
I don't find the 'My Work' in the Team explorer. How do I get it?
@Sri - "My Work" is part of Team Explorer 2012 with TFS 2012, the main TFS interface installed into Visual Studio 2012. There's no real setting that should prevent you from seeing it. Take a look and make sure you're using Visual Studio 2012 and Team Explorer 2012, talking to TFS 2012.
We're loving the new review process and have come up with a small question which you may be able to help us with.
We are in a position where a dev has submitted a section of code for review. The reviewer has requested that a small piece of it be changed so added notes and selected 'Needs work' (which removes the review from the my work section of the reviewer). The dev changes the small part of the code then requests a second review for the code. When the reviewer picks this up, is there any easy way to see the comments from the previous review so that he doesn't have to review the whole submission again?
We could ask the dev to add what he has just changed to the review description, but if there are a few notes this feels like duplicating the comments that were added in the initial review - and seeing the note history as you entered it is a useful memory jogger if you are reviewing a number of items. Alternatively we could just go back and check out the previous review - but having the comments alongside the files in the latest review request is nicer as it is all in one place (you're not jumping between review requests).
I didn't know whether we should just send the comments rather than select 'needs work', therefore keeping the initial review request open - although, then, after the changes have been made, the dev would have to overwrite the shelf set that the review process made initially rather than clicking on request review to share the changes he has made which feels wrong.
Any advice or suggestions would be great.
Thanks in advance,
As per AlanKell's comments, we are in the same position. In my opinion, any changes due to a code review should remain part of that review, and not become a second review. From my experiments, the original reviewer cannot check that changes made to their review have been made correctly.
I won't disagree with you on your desired process' validity. I will suggest that you let the TFS team know by posting it on our UserVoice site. It will allow the team to look at ways to provide more flexibility to the code review process.
This is the first iteration of code review in TFS, so there's always room for improvement!