Performing Common Development Tasks

  • Article

You perform a set of common steps for each development task. Depending on the process used by your team, you might perform these tasks in a different order. For example, you might define your tests before you make code changes.

After you have identified a coding task and you have updated your local development computer with the correct version of the source code, you can make the necessary changes to your code. However, changing the code is only the first step, because you typically must test your changes.

After you have verified the behavior of your application, you might want to analyze your code to look for common design issues that are not obvious during testing.

If your application is behaving correctly but is no longer meeting your performance goals, you might want to collect profiler data. You can then analyze that data to diagnose the reasons for the loss of performance.

By using the features of Visual Studio 2010, you can reduce the risks and costs associated with performing these development tasks. For example, you can understand the test impact of code changes before you check them in to version control.

Common Tasks

In the following table, you can find descriptions of common tasks that support this scenario and links to more information about how you can successfully complete those tasks.

Task

Supporting Content

Identify work to be performed: Your work typically consists of one or more coding tasks that must be performed, or one or more bugs that must be resolved. You retrieve the highest-priority items that are assigned to you from your work item tracking database. You might also review the overall schedule for the current iteration to verify that you can complete your tasks in the expected timeframe. You should also review the dependencies that other team members might have on your tasks, to avoid blocking progress. If your team has full-time testers, you should discuss the work with the tester responsible for the affected feature areas so that the tester can begin any test planning that is required.

Prepare your development environment: After you have identified the work that you must perform, you might have to update your development environment so that you have the required source code. If you are fixing a bug in a released or deployed version of the application, you might update your environment to have a specific version of the sources instead of the latest version. If you are working with databases, you might also want to configure a local development server.

Identify the cause of code defects: Often, the first step that you take when you must fix a bug is to use the debugger to identify the cause of the issue. If the issue was recently introduced, you might check the historical data for the source files that contain the error to determine when and by whom the issue was introduced. In some situations, you might want to roll back the original change and consider a different code change.

Make code changes: You identify what changes have to be made, you make one or more code changes, you test those changes, and you verify that your changes meet the coding standards of your team.

Identify possible quality, performance, and other issues in your code: You can use Visual Studio Premium to analyze your code to find common design issues. You should conduct a peer review of your code to identify potential issues that are not caught by the tools.

Analyze performance issues in your code: You can run key scenarios in your application to gather profiling data, which you can then analyze to diagnose performance issues.

Complete the work: When you believe that your code changes are ready, you often review them with one or more peers, perform a final full build, and run check-in tests. After you have checked in your changes and resolved any merge conflicts, you resolve any related tasks, bugs, and other work items.

Set work aside: If you are modifying code and must set that work aside to fix a high-priority bug that might affect the same set of files, you can save your changes in a shelveset. After you have finished the other work, you can retrieve the shelveset and resume where you stopped.

  • Reviewing Existing Architecture and Design
    In many cases, the development work that you must perform requires that you change an existing application. Before you begin, you might want to review the architecture and design of that application to better understand where your changes must be made.

  • Setting Up Development Environments
    Before you can create or modify code, you must set up your development and test environments with the appropriate source code. If you are working with databases, you must also have access to the offline representation of those databases.

  • Managing Development Schedules and Work
    The changes that you must make are typically defined in a task, a bug, or another work item. All of these tasks, bugs, and work items can be used to create and manage your development schedule.