Chapter 17
Introduction to Software Development
What's In This Chapter?
- Application lifecycle management features of most interest to developers in Visual Studio 2012
- Learning how My Work surfaces the items you care most about
- Managing interruptions using suspend and resume
- Seeking peer feedback on your code using the new code review capabilities
Visual Studio originally came into popularity in the 1990s by providing individual developers with the tools they needed to build great software. Most applications in that timeframe were created by individuals or relatively small teams working at a common location. However, over the course of many years, organizations developed increasingly larger and more complex code bases. The code is typically edited by a number of developers from all over the world, and teams must embrace rapidly changing requirements in order to keep up with the pace of business opportunities.
Simply having the tools at your disposal to create applications as an individual developer is no longer enough. You need tools to help you to analyze large code bases, and to help you to identify hot spots that might be causing you problems. You need tools that will provide you with the confidence that not only does the application still work after making your changes, but that it is more efficient, and the quality of the code is improving as your team matures. This is where Visual Studio 2012 comes in.
Visual Studio 2012 is also very useful for new “green field” development, on the rare occasions that you are starting a project from scratch. From day one you can use the same tools that help you work with large code bases to ensure that all newly created code maintains the same standards you envisioned during the project kick-off meeting. As the code base grows, and more developers come onto the project, you can ensure that you are not spending time prematurely optimizing code, but rather easily identifying new performance bottlenecks as they occur.
Visual Studio 2012 provides developers of both managed and unmanaged code with an enhanced set of advanced tools for identifying inefficient, insecure, or poorly written code. You can specify coding best practices, and ensure that those are checked with every build, as well as ensuring that the code is fully unit tested every time.
With Visual Studio 2012, Microsoft also recognizes as the transition of teams transition to become more agile to support evolving requirements and business opportunities comes at a price with regard to helping developers stay “in the zone” writing code. A developer who's agile might be frequently changing context from one priority to the next. In this chapter you learn about the new suspend and resume capability that can help developers more efficiently manage their development workspaces during the transitions.
You also learn about how Visual Studio 2012 and Team Foundation Server 2012 introduce new code review tooling that facilitates peer review of source code in a transparent, traceable manner.
The chapters in this part of the book dive deeper into the additional functionality provided by Visual Studio 2012 for the developer.
What's New for Developers in Visual Studio 2012
Visual Studio 2012 introduces hundreds of new and improved features for developers. Across Visual Studio you will find improvements to languages, frameworks, project types, usability, performance, extensibility, documentation — the list goes on and on. This book is by no means comprehensive across all of these categories. However, there are several categories of new and improved application lifecycle management capabilities that relate directly to developing complex software in team environments, which are covered in this section, including the following:
- Overhauled unit testing experience
- Code analysis, code metrics, and code clone analysis
- Profiling and performance
- Advanced debugging with IntelliTrace
- The new My Work view, which includes suspending and resuming work and facilitating code reviews
Unit Testing
Unit testing is a popular approach for improving code quality by writing small tests that validate small blocks of code. Unit tests are especially important in complex or evolving code bases, where one small change may have cascading consequences on functionality elsewhere in the code base. By writing and maintaining a suite of unit tests, developers can quickly be alerted that a change they just made affected a piece of functionality that was previously working correctly.
Visual Studio has supported built-in unit testing capabilities since Visual Studio 2005. Visual Studio 2005 introduced a new proprietary unit testing framework known as the Visual Studio Unit Testing Framework. Developers welcomed the addition of unit testing to Visual Studio, but this integration didn't support the more popular unit testing frameworks such as NUnit or xUnit.net.
With Visual Studio 2012, Microsoft has completely overhauled its support for unit tests. The entire unit testing framework is extensible now, which means that third parties such as NUnit and xUnit.net can publish adapters that enable their respective testing types to run within Visual Studio. The makers of NUnit and xUnit.net have already announced plans to provide these adapters. At the time of writing, several other unit testing adapters were being planned as well, including unit testing adapters for JavaScript.
Visual Studio 2012 continues to provide support for tests built with the traditional Visual Studio Unit Testing Framework, and it adds support for unit tests written in C++. You can even run tests from a variety of these frameworks across the same solution.
Visual Studio Ultimate 2012 has also introduced a capability known as Microsoft Fakes, which is similar to mocking frameworks. Microsoft Fakes allows you to test “untestable” code by creating stubs and shims which effectively simulate environments or other artifacts which may not, in fact, be available from within your development or test environment. This allows you to write unit tests which test parts of your application which interact with, for example, a SharePoint farm, without actually having a SharePoint farm present, since the SharePoint farm in this case can be faked. Or you can test code which relies on the system date, but you can override the actual system date that your application code is aware of by faking it to be any time in the past or future.
The overall experience for viewing, running, and debugging tests has also been improved. You learn all about the improvements to unit testing with Visual Studio 2012 in Chapter 18.
Improved Code Analysis
Earlier versions of Visual Studio shipped with code analysis rules to enable developers to analyze .NET source code to check for common issues and security flaws. In Visual Studio 2012, support for analyzing C++ source code has been added, as well as some overall tooling improvements to make code analysis easier to configure and view the results from. Chapter 19 focuses on code analysis.
Code Metrics
Code metrics can be calculated by Visual Studio 2012 to provide you with detailed quantitative measurements of your source code. This ranges from basic calculations — such as number of lines of code — to more advanced metrics, such as depth of class inheritance or cyclomatic complexity (which is essentially the number of possible paths through your code's logic). These and other metrics can make it possible for you to better understand the overall maintainability of your code, and they can offer clues about where you might benefit from refactoring or other architecture changes to improve the maintainability of your code over time. Code metrics are especially helpful when maintaining large or complex code bases. Code metrics are covered in Chapter 19.
Code Clone Analysis
A new capability from Microsoft Research known as code clone analysis has been introduced in Visual Studio 2012 to help developers discover semantically similar blocks of code. As developers, we are often guilty of copying blocks of code from one class or project into another class or project if it provides all or most of the same functionality we need. Unfortunately, this usually creates a problem where we find ourselves independently maintaining two pieces of code that were designed to do the same thing. Most of the time, these blocks of code would benefit from being refactored into a single location. For older code bases, how do you find such refactoring opportunities?
Code clone analysis is the answer to this question. With code clone analysis you can look across your entire solution for blocks of code which are similar in structure and composition. They don't even need to be identical; code clone analysis is adept at finding blocks of code that might have started out the same and evolved over time to become slightly different. You can learn all about code clone analysis in Chapter 19.
Profiler
The Visual Studio 2012 profiler enables you to pinpoint possible performance bottlenecks within your application. You can use the profiler while running your application or while running tests. You can even capture performance baselines to help you easily determine if performance is getting better or worse as you check in new code. Chapter 20 covers use of the Visual Studio 2012 profiler.
Advanced Debugging with IntelliTrace
IntelliTrace is an advanced debugging capability introduced in Visual Studio 2010 that enables you to capture a full historical stack trace of an application's execution. It's very helpful to “rewind” the debugger and understand the historical state of your application. Developers could use IntelliTrace whenever they debugged a local application, or testers could enable IntelliTrace in test environments so that an IntelliTrace file could be attached to a bug — which further aided the developer understand exactly what took place when diagnosing the issue.
With Visual Studio 2012, Microsoft has further extended the usefulness of IntelliTrace by enabling organizations to capture traces from applications running in production environments. This provides developers with greater insights into bugs coming from production environments and enables teams to again improve the overall health and quality of their code.
IntelliTrace is covered in depth in Chapter 21.
My Work
In previous chapters you worked with Team Explorer, which is the interface within Visual Studio that provides developers with access to Team Foundation Server (source control, work items, builds, reports, and so on). You may have noticed a new area of Team Explorer titled My Work. My Work is new in Visual Studio 2012 and provides developers with a personalized view into the work that matters most to them.
To open My Work, open Visual Studio ⇒ Team Explorer. If Team Explorer is not visible, click View ⇒ Team Explorer. Click the Home icon if you are not already at the Team Explorer home page. Click My Work to see a view similar to that shown in Figure 17.1.
My Work is a personalized view for each developer. Using My Work, a developer can:
- See work in progress, including pending changes
- Suspend and resume work (more on this later in this chapter)
- View any work items that are currently assigned to him
- Request code reviews and respond to code review requests from others (more on this later in this chapter)
Suspend and Resume
With Visual Studio 2012, Microsoft provides an easy way for developers to suspend their in-progress work if they get interrupted. An interruption might be an important bug fix that a developer needs to make, or it could simply be that the developer is shutting down her machine for the evening.
Interruptions have historically been very costly for developers. Team Foundation Server has always made it easy to quickly shelve file edits for later, but for a developer to be productive it often means setting breakpoints, declaring watch variables, and opening several specialized tool windows from within Visual Studio. Thankfully, the new suspend and resume capabilities are designed to help developers preserve all of this state information and then quickly get back in the zone when they are ready to resume this work.
Refer to the top of the My Work pane in Figure 17.1; note that there are three pending file edits and work item 57 is in-progress. If this developer gets interrupted, he can quickly press Suspend & Shelve to back up all the pending changes as a shelveset on Team Foundation Server 2012 and take note of the Visual Studio 2012 environment. The suspended work appears in the Suspended & Shelved Work category of the My Work pane. When the developer is ready to work on this again, he can simply click Resume. Visual Studio unshelves the pending file edits, resets any breakpoints, and opens all the same files and tool windows (even across multiple monitors). This can be a very valuable tool for developers to quickly switch contexts with minimal overhead.
Code Review
Most seasoned developers have grown to appreciate the value of peer reviews of source code. Code reviews are quite simply a process whereby developers inspect each other's changes to look for possible bugs or missed optimizations prior to committing those changes to the repository. Code reviews are also a great way to teach junior developers, and it provides a way to educate more people on your team about sections of your code base that they may not otherwise be exposed to.
Code reviews have now been built into Visual Studio 2012 and Team Foundation Server 2012 to facilitate this process. One advantage of using these tools to facilitate code reviews is that they become traceable and reportable — a team can audit a code change later on to discover whether it was properly reviewed before being committed. By managing code reviews with Team Foundation Server, it also means that team members who are geographically distributed can easily participate in code reviews without the need to meet in person or on a teleconference.
To initiate a code review, click on Request Review within the My Work pane of Team Explorer. You are presented with a dialog similar to what's shown in Figure 17.2. You can specify one or more team members who should be asked to review this code, along with a title and description for the code review. Any related work items that were In Progress from your My Work view are automatically associated with this code review request as well, which can provide additional context for the reviewers into the intended edits. Click Submit Request when you are finished. You return to the My Work view, and a new Code Review Request work item appears in your Code Review & Requests category of this view. You can monitor this Code Review Request work item to see its status.
Likewise, your team members see your Code Review Request work item in their My Work view. When they open this Code Review Request they see a dialog similar to Figure 11.3.
Figure 17.3
This dialog includes several pieces of functionality:
- Send Comments enables you to save your in-progress comments for this code review. This is primarily intended to be used when you want to have a dialog with the person who submitted the code review request, such as to ask clarifying questions before you continue your review.
- The Accept and Decline links enable you to indicate to others whether or not you will work on this request. For quick code reviews, there is no need to formally click Accept for a code review, but doing so is helpful to signal to others that you are working on a longer code review or you plan to work on it later.
- Send & Finish submits your code review and removes it from your list of pending code reviews. Use this when you are finished with your code review.
- Add Reviewer enables you to add other people from the team to this request. Use this when you are unable to complete a code review request or when you know that another team member has expertise for a specific type of code change.
- There are three levels of comments that you can leave as part of a code review. Overall comments are meant to capture impressions of the overall set of changes being reviewed. You can leave file-level comments by right-clicking any given file and clicking Add File Comments. You can also open any file, select some text, right-click the text, and select Add Comment to leave line-level comments. These three levels of comments enable you as a reviewer to be very specific with the type of feedback you are giving to the originator. The checkboxes next to each file also provide you with an easy way to ensure that you have reviewed each file in the Code Review Request.
After you have submitted your response, the originator sees the response in his My Work pane. Figure 17.4 shows the result of this response. The originator can choose to reply to any specific comments, which is useful if this code review is audited later on. He can also continue to add or remove reviewers until he is satisfied that the code has received an adequate level of review. Finally, clicking Close Review closes the Code Review Request work item. When these changes are checked in, the Code Review Request work item is automatically included in the changeset, along with any linked Code Review Responses.
Summary
This chapter provided a quick look at the areas of Visual Studio 2012 that will be of most interest to developers and provided a preview of what to look forward to in this next section of the book.
Chapter 18 focuses in detail on the unit testing, why you should care about it as a developer, and what tools Visual Studio provides to help you create and run unit tests.