1.
学习快捷键
明显而又简单,但是节省时间,尤其是对于那些你每天都要执行上百次的操作,例如构建和调试。下面是一些每个Visual Studio都应该知道的一些基本的快捷键:
- 构建: CTRL + SHIFT + B
- 单词完成: CTRL + SPACE
- 开始调试: F5
- 执行: CTRL + F5
2.
使用GhostDoc生成XML注释
让GhostDoc帮您生成XML注释而不是手动输入。虽然使用宏和代码段看起来也比较有效,但是我推荐Ghost Doc而不是其它方案。这个免费的插件基于上下文使用自定义模板生成连贯的英文文档。要使用它,右击(或者使用CTRL + SHIFT + D)为当前元素添加文档。例如:
![](https://p-blog.csdn.net/images/p_blog_csdn_net/lynnlin1122/1.png)
这会生成下面的文档(注意
GhostDoc
将属性名拆分为单词并创建一个语句):
![](https://p-blog.csdn.net/images/p_blog_csdn_net/lynnlin1122/2.png)
3.
自动完成属性
利用C#的一个新特性:auto-implemented properties.让编译器而不是你亲自为属性创建一个后台私有域吧。下面的例子展示了这个语法:
![](https://p-blog.csdn.net/images/p_blog_csdn_net/lynnlin1122/3.png)
使用代码段更为有效。输入prop(自动完成属性的快捷键),然后连续敲击TAB TAB。然后填入数据类型和属性名字:
![](https://p-blog.csdn.net/images/p_blog_csdn_net/lynnlin1122/4.png)
4.
Refactor
Visual Studio
中的重构可以完成很多任务,特别是重命名,但是我更喜欢的一个更有效率的特征是Encapsulate Field。如果你没能使用自动完成属性,而是声明了一个私有域,那么让VS帮您生成属性吧。要使用这个特征,右击域,并选择Refactor > Encapsulate Field...
![](https://p-blog.csdn.net/images/p_blog_csdn_net/lynnlin1122/5.png)
它会为你生成如下的属性:
5.
向
VS2008
添加命令
安装
PowerCommands for Visual Studio 2008
以添加几个提高生产率的命令,例如:
- 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) 拷贝和粘贴引用(包括项目引用)
安装以添加几个提高
TFS
生产率的命令,例如:
- 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 > External Tools
- Click Add
- Name it Reflector and browse to the executable
- Enter $(TargetPath) for the Arguments
6.
使用项目配置加快编译
在一次编程中你可能编译数十次,因此不要使能那些不是必不可少的东西例如代码分析和XML文档。在Debug配置下开发,只是在check-in之前切换到Release配置以运行代码分析和生成XML文档。在一个大的解决方案中,这会节省不少时间。
下面的代码展示了在Debug配置中禁止代码分析:
![](https://p-blog.csdn.net/images/p_blog_csdn_net/lynnlin1122/7.png)
下面的代码展示了在Release配置中使能代码分析:
![](https://p-blog.csdn.net/images/p_blog_csdn_net/lynnlin1122/8.png)
7.
让Visual Studio生成单元测试代码
虽然VS还不能全部自动化单元测试(
check out Pex
),但是VS可以生成
positive unit test
代码,从而为你提供一个起点。为了使用这个特征,右击一个想测试的元素并选择
Create Unit Tests...
![](https://p-blog.csdn.net/images/p_blog_csdn_net/lynnlin1122/9.png)
VS
生成下面的测试方法:
![](https://p-blog.csdn.net/images/p_blog_csdn_net/lynnlin1122/10.png)
8.
使用接口驱动设计
你可能从没将一个接口作为一个提供生产率的方法,但 是如果由契约而不是实现来驱动你的开发过程,那么它的确是。让我举一个简单的例子。一个开发者开发业务层,另一个开发数据访问层,并且他们需要在如何实现 一个新的特征达成一致。在一些业务对象设计中,业务组件将初始化数据组件(或者调用一个静态方法)。站在设计的角度这会产生问题,因为二者是紧耦合。站在 生产率的角度看也有问题,因为业务层开发者依赖数据访问层的实现。接口驱动设计解决了这个问题。
不是让业务组件开发者等待数据组件开发者,而是让他们一起设计和实现接口。于是两个开发者可以并行实现他们的组件。IDD也让业务开发者可以mock数据访问组件,因此消除了任何计划依赖。下面展示了设计:
![](https://p-blog.csdn.net/images/p_blog_csdn_net/lynnlin1122/11.png)
9.
Make a Mockery of Dependencies
虽然你的组件可能依赖于不同的开发者开发的层或者特征,但是不要让这成为减缓你开发脚步的理由。假设你负责业务逻辑层,它依赖于数据访问层,访问层又依赖于数据库表和存储过程。Mock数据访问层而不是等待,于是你可以实现和对业务层实现单元测试。顺便说一下,你应该使用mocks:否则你的单元测试看起来更像是集成测试。我推荐Rhino Mocks.
下面是一个使用mocks的单元测试示例:
![](https://p-blog.csdn.net/images/p_blog_csdn_net/lynnlin1122/12.png)
10.
数据驱动单元测试
如果你的单元测试需要多个输入才能进行完全的测试,那么你可能需要为每个可能的组合都编写一个测试方法,但是数据驱动单元测试更有效率。当运行单元测试时,它从表中装载数据,为每行调用单元测试。你可以使用TestContext.DataRow属性访问当前行的数据。
![](https://p-blog.csdn.net/images/p_blog_csdn_net/lynnlin1122/13.png)
一旦测试完成,你可以查看结果:
![](https://p-blog.csdn.net/images/p_blog_csdn_net/lynnlin1122/14.png)