转载一篇VS2008的小技巧，提高工作效率必备啊！

It's an obvious and trivial thing, but the timesaving will add up, especially for those actions you perform tens or hundreds of times a day such as building and debugging.  Here are some basic bindings every Visual Studio developer should know:

Build: CTRL + SHIFT + B

Word completion: CTRL + SPACE

Start with debugging: F5

Start without debugging: CTRL + F5

<a href="http://blogs.msdn.com/blogfiles/johnwpowell/WindowsLiveWriter/10TipstoBoostYourProductivitywithCandVis_753E/image_2.png"></a>

This generates the following documentation (note GhostDoc split the property name into words and created a sentence from it):

<a href="http://blogs.msdn.com/blogfiles/johnwpowell/WindowsLiveWriter/10TipstoBoostYourProductivitywithCandVis_753E/image_4.png"></a>

<a href="http://blogs.msdn.com/blogfiles/johnwpowell/WindowsLiveWriter/10TipstoBoostYourProductivitywithCandVis_753E/image_6.png"></a>

Use the code snippet to make this even faster.  Type prop (the shortcut for an auto-implemented property) followed by TAB TAB.  Then fill in the data type and property name:

<a href="http://blogs.msdn.com/blogfiles/johnwpowell/WindowsLiveWriter/10TipstoBoostYourProductivitywithCandVis_753E/image_30.png"></a>

The refactor feature in Visual Studio is indispensable for many tasks, especially renaming, but one productivity feature I particularly like is Encapsulate Field. If you are unable to use an auto-implemented property, declare a private field and let Visual Studio generate the Property for you.  To use this feature, right-click on the field and select Refactor &gt; Encapsulate Field...

<a href="http://blogs.msdn.com/blogfiles/johnwpowell/WindowsLiveWriter/10TipstoBoostYourProductivitywithCandVis_753E/image_8.png"></a>

The property is created for you:

<a href="http://blogs.msdn.com/blogfiles/johnwpowell/WindowsLiveWriter/10TipstoBoostYourProductivitywithCandVis_753E/image_10.png"></a>

Close all documents

Copy and paste a class (automatically renames)

Remove and sort using statements project-wide

Copy and paste references (including a project reference)

Find in source control

Open source folder in Windows Explorer

Work item templates (can be used to set values on multiple work items at once)

Select Tools &gt; External Tools

Click Add

Name it Reflector and browse to the executable

Enter $(TargetPath) for the Arguments

You may build tens of times during a programming session, so don't enable anything that isn't absolute necessary such as code analysis and XML documentation.  Develop in Debug configuration, and switch to Release configuration just before check-in to run code analysis and generate XML documentation. In a large solution I recently worked on, this shaved a minute off compilation time.

The following shows code analysis disabled in Debug configuration:

<a href="http://blogs.msdn.com/blogfiles/johnwpowell/WindowsLiveWriter/10TipstoBoostYourProductivitywithCandVis_753E/image_12.png"></a>

The following shows code analysis enabled in Release configuration:

<a href="http://blogs.msdn.com/blogfiles/johnwpowell/WindowsLiveWriter/10TipstoBoostYourProductivitywithCandVis_753E/image_14.png"></a>

<a href="http://blogs.msdn.com/blogfiles/johnwpowell/WindowsLiveWriter/10TipstoBoostYourProductivitywithCandVis_753E/image_16.png"></a>

Visual Studio generates the following test method:

<a href="http://blogs.msdn.com/blogfiles/johnwpowell/WindowsLiveWriter/10TipstoBoostYourProductivitywithCandVis_753E/image_18.png"></a>

You probably never thought of an interface as a productivity feature, but it can be if your development process is driven by contracts instead of implementation.  Let me illustrate with a simplified example.  One developer owns the business layer and another developer owns the data access layer, and they need to agree on how to communicate to implement a new feature.  In some business object designs, business components will instantiate data components (or call a static method).  This is a problem from a design standpoint because the two become tightly coupled.  It is also a problem from the productivity standpoint because the business layer developer becomes dependent on the data access layer developer's implementation.  Interface-driven design (IDD) solves this issue.

Rather than the business component developer waiting on the data component developer, they meet to design and implement the interface.  Both developers are then free to go their separate ways and implement the components in parallel.  IDD also enables the business developer to mock the data access component, thereby removing any scheduling dependencies.  The following illustrates the design:     

<a href="http://blogs.msdn.com/blogfiles/johnwpowell/WindowsLiveWriter/10TipstoBoostYourProductivitywithCandVis_753E/image_24.png"></a>

Here is a sample unit test with mocks:

<a href="http://blogs.msdn.com/blogfiles/johnwpowell/WindowsLiveWriter/10TipstoBoostYourProductivitywithCandVis_753E/image_22.png"></a>

If you have a unit test that multiple inputs to fully test, you could write a test method for every possible combination, but data-driven unit tests are more efficient.  When the unit test is run, it loads data from a table and calls the unit test for each row.  You can access the data in the current row using the TestContext.DataRow property.

<a href="http://blogs.msdn.com/blogfiles/johnwpowell/WindowsLiveWriter/10TipstoBoostYourProductivitywithCandVis_753E/image_26.png"></a>

Once the test completes, you can view the results:

<a href="http://blogs.msdn.com/blogfiles/johnwpowell/WindowsLiveWriter/10TipstoBoostYourProductivitywithCandVis_753E/image_28.png"></a>

本文转自Jack Niu博客园博客，原文链接：http://www.cnblogs.com/skywind/archive/2008/03/31/1130640.html，如需转载请自行联系原作者