Mariusz, Gorzoch tech Blog

TFS 2012 Code review how to start

leave a comment »

Most common question when it comes to „code review” process is „how to start” ? In nut shell there are two approaches to do code review in TFS 2012 and Visual Studio 2012:

A. Not blocking approach (recommended for now)

In that approach you first check-in the code and then request review (post code review). Going for that way you ask for an feedback on things with you already placed in TFS.


How to do it :

1. Complete work around work item and check-in your changes

2. Go to history and find changeset associated with check-in from point 1



3. Request review


A: Enter people with you would like to do review of your code

The best people to choice to do code review are team members of your own project. Anyway if they are too busy then you can try to ask people from outside your project to do it for you. Not being member of your team project is not blocking code reviewers for proving you feedback.

B: Provide description of the change

C: Submit request

4. Done

Your request review should now be submitted to the reviewer and they should :

– Get email with information that review is pending for them

– They should see it in “My work” tab


B. Blocking approach

In that approach you don’t check in your changes but instead of that you request for review of changes with are pending.


In nut shell this process looks like this:

1. You complete your work and when you are ready to check-in then instead of using option “Check-in” you use “Request review”

2. You fill the “request review” form in similar way as described in point A.3 and submit your review

3. You suspend your work (all current changed) with help of new “suspend” feature in “My work” panel.

4. Now you can start working on new feature/work item

5. After a while you get feedback around code review.

6. You suspend your current work

7. Now you need to resume changes suspended in point 3

8. You review changes, adjust your code and check-in code or go for the next code review round

9. Once changes are check-in you resume your work from point 6

As you can see that approach is much more tricky and complex. This is the reason why I recommend to start from option A. Moreover that approach strongly relay on quick feedback around code review as it block your check-in and exposes you to long and boring marge process.

So, to do or not to do code review ? If you are still not sure if it is worth to go for it let me give you few proven reasons:

1. Finding bugs early, when they are cheap to fix.

2. Coding standards compliance. Code review helps to maintain consistent coding style across the company.

3. Teaching and sharing knowledge. During review team members gain better understanding of the code base and learn from each other.

4. Consistent design and implementation. Peer review helps to maintain a level of consistency in software design and implementation.

5. Higher software security. Applications that require a high level of security benefit from targeted security reviews.

6. Team cohesion. Review discussions save team members from isolation and bring them closer to each other.

7. Confidence of stakeholders. You build confidence of stakeholders about the technical quality of the execution.


Written by Mariusz Gorzoch

17 October 2013 at 18:55

Posted in TFS

Tagged with ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: