但是现在我发现一个奇怪的问题,就是参数化查询比字符串拼接要慢,而且速度相关10倍之多.

ADO.Net会将参数化查询转化为:

exec sp_executesql N'
SELECT  ...  Where (NotificationID = @NotificationID) ', N'@NotificationID nvarchar(10)', @NotificationID = N'NS03300947'

这种形式,而我的参数是通过:            exps.Add(Expression.EqualTo("NotificationID", OpenSession().CreateParameter(PARM_NOTIFICATIONID, pdDeliveryNotificationInfo.NotificationID,DbType.String, 10, ParameterDirection.Input)));这个语句创建的.

但是为什么会慢呢?经过查阅资料和自己的分析后,得知,原来是字符类型的不匹配造成的.因为这个数据表是客户数据库中的,我只是提取数据,而我一般建数据表都使用NVarchar类型,而客户的这个表使用的是Char(10),拼接字符串的时候,查询优化器会选择聚集索引查询,而使用参数化后,因为字段类型错误导致了表扫描..找到问题会就简单了,使用

目的：对于以交互式的用户界面而言，假如要调用长时间运行的操作，那么可以使用以下模式让你的调用更方便。

问题：某个用户界面必须多次启动某个操作，开发人员希望将其从该接口的操作中分开。这里面可能有很多的理由，但最普遍的情形是多个操作需要被立即执行，或某个操作潜在地占用过多的时间，超过了用户所期望的等待响应时间。某写操作的完成总是要占用时间，在等待某个操作护照或者多个操作在后台执行时，用户界面应该允许用户继续做其他事情。对于web上的操作，现在流行的AJAX热得一塌糊涂，通过异步调用来获取服务器端信息并更新客户端。对于winform来说，当然也可以进行异步调用了。本文试图提供一个稍微通用一点的解决方法。

适用性：
在下列情况下可以使用：
采用胖客户端，WinForm实现。
操作被预期是长期的或者占用时间比较长的
多个操作必须立即被处理执行的

主要包括：
    public delegate void CompleteEvent<T>(T t);   //采用泛型委托，操作的结果被传递给调用方。
    public delegate void ExceptionEvent(Exception ExceptionThrown); //异常将被传递给调用方
    public NotifyingThreadManager<T> //通知线程管理

NotifyingThreadManager<T> 中
 public void ExecuteAsync(System.Windows.Forms.Control ControlToNotify, CompleteEvent<T> NotificationDelegate, ExceptionEvent ExceptionDelegate) 的目标就是存储需要用来通知的信息和启动封装线程的执行。我们需要知道将要同步的控件以及用来处理结果的两个委托。

线程的主要工作在 protected void DoExecution()中完成，可以进行相应的修改以适应实际操作。

 1using System;
 2using System.Collections.Generic;
 3using System.Text;
 4using System.Threading;
 5namespace com.tttick.NotifyingThreadManager
 6{
 7    public delegate void CompleteEvent<T>(T t);
 8    public delegate void ExceptionEvent(Exception ExceptionThrown);
 9    public class NotifyingThreadManager<T>
10    {
11        System.Windows.Forms.Control mControlToNotify;
12        CompleteEvent<T> mFactoringComplete;
13        ExceptionEvent mFactoringErrored;
14        Thread mExecution;
15        T t;
16        public NotifyingThreadManager(T t)
17        {
18            this.t = t;
19        }
20        public void ExecuteAsync(System.Windows.Forms.Control ControlToNotify, CompleteEvent<T> NotificationDelegate, ExceptionEvent ExceptionDelegate)
21        {
22            mControlToNotify = ControlToNotify;
23            mFactoringComplete = NotificationDelegate;
24            mFactoringErrored = ExceptionDelegate;
25            ThreadStart startThread = new ThreadStart(DoExecution);
26            mExecution = new Thread(startThread);
27            mExecution.Start();
28        }
29        protected void DoExecution()
30        {
31            object[] paramArray = new object[1];
32            try
33            {
34                //此处进行一个长时间的操作，请灵活使用
35                Thread.Sleep(10000);
36                paramArray[0]=t;
37                mControlToNotify.BeginInvoke(mFactoringComplete,paramArray);
38            }
39            catch (Exception ex)
40            {
41                paramArray[0] = ex;
42                mControlToNotify.BeginInvoke(mFactoringErrored, paramArray);
43            }
44        }
45
46    }
47}

 1 private void button1_Click(object sender, EventArgs e)
 2        {
 3            NotifyingThreadManager<string> f = new NotifyingThreadManager<string>("gadfg");
 4            f.ExecuteAsync(this.button1, new CompleteEvent<string>(FactoringComplete), new ExceptionEvent(FactoringErrored));
 5        }
 6void FactoringComplete(string Result)
 7        {
 8            this.button1.Text+= Result;
 9        }
10        void FactoringErrored( Exception ExceptionThrown)
11        {
12            this.button1.Text = ExceptionThrown.Message;
13        }

大家从各个开发语言的优缺点和适用领域，一直讨论到设计模式、框架、重构、单元测试，乃至敏捷编程，最后都讨论到了软件开发过程管理，甚至都谈到了盈利模式和中国软件

的悲哀。

最后不了了之，都觉得改善中国内地现在的软件生产状况不可能。

为什么呢？

我重新把这几天大家的讨论留言翻了一遍，发现大家的软件团队都存在着这样一种普遍现象

1大部分人所在的公司，开发人员仅3-5人，多的在10人。别看就这几条枪，还从售前支持，软件开发，测试、打包发布、文档编写、实施安装、培训、技术支持都做。
这还不算什么，而且几乎是一个人负责一个产品或一个项目，一个人从头跟到尾，而且负责多个客户的维护工作。
这还不算什么，而且随时老板会找来八竿子打不着的新活，要的还挺紧，突然要开发，打乱了所有的计划，最后都懒的按计划行事，每天撞钟，老板有事就吩咐，没事就上网，还不让听歌，当然更不让打游戏。甚至还不让看技术书籍，呵斥不干工作。只能上网装作在工作。

2老板和员工互相斗智斗勇，在年终奖、报销、出差、平时福利上啊，都明争暗斗。老板卡的紧，员工就在项目和产品上下药，还不知道是谁占了谁便宜，谁给谁打了工。

3员工一边在刻苦钻研各种开发工具，阅读源代码，学习做DEMO例子，阅读UML、设计模式、单元测试、敏捷编程等等，一边却懒的修改现在公司的产品，有问题就打补丁，客户不嚷嚷就懒的修改，代码不优化，界面不友好，架构没架构，代码不封装

但是，在讨论中，我时时都强烈感觉到，大家是想把产品开发好，把开发过程管理的井井有条，但是都心有余而力不足。阅读了N多软件工程的书籍，从重型方法到轻型方法都阅读了，但都无法把现在的开发状态一点点扭转好。

许多人想闹革命，把现在这些产品和团队都砸塌，然后重新来过，但这只是梦想，说说而已。只能希冀下一次跳槽，能找到一个好的公司，把自己平生所学全部发挥出来，但这好像也只是梦想，因为交流了一下，大家彼此的境况基本相同。

一些极端主义者自己开了公司，才发现不持家不知道油盐贵，现在自己和手下变成了老板和员工的关系，走了过去的老路。

更有一些极端主义者辞职，自己做软件，最后由于生活拮据或做做发现这个软件没什么意义，就丢弃了自己的梦想，随便找一家公司开始沉默撞钟。

一些聪明的家伙，有的入了外企，有的进了大的网游公司，有的进了外包公司，有的进了大网站公司，都是讲究大规模开发的公司，希望能找到一条中国式团队开发产品保证之路

作为小软件公司，我们真的无能为力了么？我们真的成为炮灰了么？

但是，中国软件行业大部分都是这样的公司。从每年的CSDN的程序员调查都可以看到，中国软件公司大部分都保持在这种开发团队规模，开发人员大部分都在毕业1-3年。

我们是在等待时间让人变得成熟么？我们是在等待时间让人变得技术综合实力增强么？

依笔者看，作为中国软件群体最大的小软件公司，需要的不是UML/RUP/CMM这些重型方法，不是前几年大家关注的小组开发方法，也不是敏捷编程这样的结对方法，我们都无法有这样的资源实现这样的方法。

但是，想想，星星之火可以燎原。红军能从爬雪山过草地起家，最后解放全中国。我们就没有方法？

那我们就需要想，就我们目前能拥有的权力和资源，我们如何一点点改进。我们需要的是从游击队到兄弟连，从兄弟连到正规军的方法。我们现在还处于游击队，一个队长领了一帮游兵散勇，有的人甚至没有枪还背着大刀，有的人还没杀过鬼子。

首先，要把我们自己变成兄弟连。

我常常观看国际著名的CS战队的比赛录像，他们配合的多好啊。如果他们都单兵作战，那么早就死翘翘了。这和咱们的软件开发多么相像。我们多么神往这种默契的配合，打的多么流畅。我们要的就是这个。他们也不几个人么。

那让我们来分析分析吧。

我们想好好专职的开发软件，但我们的时间都被实施安装、培训、技术支持占去了。为什么我们要做这些？是因为我们软件没有操作说明，其他部门人都不会用。而且我们也没有培训机制，其他部门人更不会用。而且我们的软件不稳定，其他部门人都拒绝实施。由于我们软件不稳定，老出问题，出了问题其他部门人也帮不上忙，只能我们自己去做技术支持。

从以上来看，主要矛盾就是在：操作说明、培训机制、稳定性。如何保证这三点。而且从以上来分析，稳定性是最重要的。不稳定，你即使有操作说明和培训机制，其他部门人都躲着实施，谁想去客户那里尴尬丢脸挨骂呀。所以，其他部门人会找各种理由向老板告开发部的状，以躲避实施，说软件太烂，根本无法拿出去。这也就是开发部往往和其他部门关系都不好，开发人员老抱怨自己就闷头辛苦开发解决问题，没有人说好，却被奸人陷害。天长日久，积怨颇深。其实说起来，根源还在开发部自己这里。

如何保证稳定性？

大家第一想到的就是招测试人员。当然，一些公司的老板是拒绝养测试人员的。另外，如果你只想到招测试人员，其他方法不配合测试人员，即使有了测试人员，软件稳定性仍然不会有提高。所以，有一些工作，是不管有没有测试人员，都必须是我们开发人员要做的：

每个人的技术水平都参次不齐的，每个人对自己代码的负责认真性也都是不一样的，所以要想提高稳定性，必须专门从队伍中找一个人，他作为公共代码开发员。每个产品或项目的修改需求，必须首先经过他的思考，能做成公共代码，能封装成函数，就他来做。其他的程序员只管调用函数，实现客户UI操作和辅助功能。这个公共代码开发员必须具备以下能力：
A参与过几个主要项目的开发、实施、支持。这样，他对客户需求有综合的把握。如果队伍中没有这样的人，只有开发经理一个人有这样的经理，那么接到客户需求，分析客户需求，分解析辨是公共代码员来做还是其他开发人员来做。
B公共代码开发员具有负责认真的工作态度，代码细心严谨考虑周详异常保护做的到位内存创建释放有头有尾，代码优美，代码可阅读，代码重构，代码性能和稳定都高
C公共代码开发人员的技术能力高，知道封装成什么样的函数接口，在灵活性，以后的修改变化性上最好

应该说，找一个技术能力好的，工作认真负责的人，应该是不难找到的。而且专门做这件事，不让他参与各种杂事，他是应该能干好这件事的，而且会越做越好，这就是术有专攻。

刚才还讲到一件事，那就是开发经理要熟悉客户需求，而且是深刻理解客户需求。

客户需求，客户需求。这个让开发部最头疼的字眼。每当想起客户需求，就想起了以下这些话：
1 程序员说：这是你们家个性的需求，太邪门，我们不做。客户说：不做我们找你们老板去，我们是花钱买了你们的产品的。
2 客户说：我不会用鼠标，你给我做一个语音输入吧。我们还想要一个类似QQ的东西供我们内部沟通，你们给我们做一个吧。程序员：我晕。
3 程序员说：等你们内部斗争完，你们协调完了，我再调研需求。

似乎，我们在需求上无能为力，我们永远在追赶客户的需求，满足他们的现状，把N多家的客户需求都加进软件中，只要能实现的，我们尽量咬牙实现了。

最后，我们发现，我们的软件无比复杂，谁也不会用了，连开发部门都不会用了，谁也不知道这个需求当时为什么是这样的。因为无比复杂，所以实施、培训、技术支持都成了问题，稳定性更成了问题。代码互相交叉，根本无法理清有多少交叉影响点。维护的程序员都快崩溃了，天天在祈求，千万别接到客户电话，千万别接到客户电话。

这个问题终归是问题，而且是软件开发最大的问题。虽然我们也动用了这样的技巧：
1 客户业务部门不能随便提需求。必须集中汇总到客户IT部门，由客户IT部门汇总过滤完，再集中报给软件公司
2 客户IT部门的需求，必须客户方负责IT项目的老板签字才能生效，才能报给软件公司
3 不能随时报，每3个月集中报一次
4 不能口头报（即使在现场实施支持也不行），不能电话报，只能MAIL或传真来报
5 必须按我们规定的格式报，要严格写清楚需要实现的功能的界面，输入数据或输出数据，输入输出数据的格式要求，谁操作，多长时间操作一次。
6 软件上线后只能免费修改3次。以后再有需求，就必须另签合同另收费，否则不予修改。

经过这么几招，客户也疲了。需求是不提了，开发部欢呼雀跃。但我们真的做好了么？难道客户真的满意了么？客户为什么要用我们的软件？难道仅仅是为了把他们现在手工做的，然后转到计算机去做。让计算机的查询统计计算速度代替人工？

客户为什么要提这样的需求？客户要根本解决什么问题？这些问题谁来想，谁来想解决办法？

OH，My God!我们无能为力，因为我们是技术人员，我们不懂业务。

那这个问题谁来解决？

程序员苦笑了：没有人解决，也没有人能解决。客户就要，你不做他就要给老板打电话。

噢，那就让程序员的噩梦继续吧。谁也救不了你，能救你的只有你自己。

要救我们自己，必须我们自己走出我们自己。谁让我们就处在这样的处境呢？我们都想过的好，只能我们自己救我们自己。

那我们就鼓足勇气，走出来，从我们的设计模式、OO、软件工程、虚拟接口、反射、持久化、框架中走出来。开发经理来承担起客户行业研究来：
1 客户行业这个群体有多大？大中小规模各有多少家，各分布在什么省？我们面对的最佳客户是什么规模什么信息化程度的？我们的次佳客户是什么规模什么信息化程度的？
2 我们的上层竞争对手、本层的竞争对手、下层竞争对手目前的产品怎么样？他们各自的优点是什么？他们各自的缺点是什么？我们应该突出的优点是什么？我们的缺点是什么？
3 客户行业的过去5年，现在2年，未来3年的发展历史和趋势是什么？他们面临哪些挑战和机遇？
4 我们现在所做的典型客户，他们的组织结构，人员规模，每个岗位每日业务流程、每个岗位每日每周每月每季每年的异常处理业务流程，每个岗位每日每周每月季每年的输入表格，每个岗位每日每周每月季每年的常用数据查询，每个岗位每日每周每月季每年的统计报表
5 针对以上的了解，客户面对未来挑战和机遇，未来应该如何变更他们的岗位和职责和流程，尽量流程少，效率高，运转快？

其实，开发经理就相当于业务架构师（因为我们还是游击队，不可能有专职的业务架构师），公共代码开发员就相当于技术架构师。

柳传志说的非常好：搭班子，定战略，带队伍。你班子不行，上什么需求管理软件、版本管理软件、项目进度管理软件、自动测试、自动集成软件，都是无法落地执行的。

有了夯实的业务+技术，功能实用、功能符合客户操作、功能稳定。这是软件最基本的要求，就都能满足了。这时候再招测试人员，就能把质量再夯实了。

而且，测试人员由于熟知产品，他们还能做技术支持呢，这样可以有更多的开发人员来专职开发，开发的专业性就能越来越提高了。

好的产品，还需要有好的文档和培训，否则其他部门还是不会接开发部的产品的。

那就招一个文案人员，写帮助说明，制作操作视频，制作学习版数据库，参与辅助测试（这个很重要，否则文案人员不熟知产品，无法写出有质量的文案）。有了这些文案的基础，最熟悉产品的非开发人员就有了两个岗位：测试兼技术支持，那么文案就兼起培训工作（由于他自己写文案自己用自己的文案做培训，在培训中会有各种提问，会更加增进他对文案和产品的理解，能写出更好的文案。而且他不是开发人员，他能站在使用者的角度上来写来讲，而且他属于开发部门，他会给产品开发带来更多更好的产品易用性建议）。

好了，开发部的四套马车终于起来了，这就是我要讲的开发模式：从游击队转变为兄弟连，从软件作坊走向

记住：业务架构、技术架构、测试兼技术支持、文案兼培训，四套马车。

我们一直用它，效果很好，搭建团队容易，循序渐进不革命。

有了这么好的团队，就能比过去产出更好的软件，软件的质量，软件的进度，软件的竞争力就都上来了，再上各种管理软件：如项目管理软件、版本管理软件、BUG管理软件、自动测试软件，就水到渠成了。

其他部门也愿意接软件了，软件的实施和培训和技术支持都被其他部门接过去了。开发部门也终于专职专业起来了，整个公司都很协调了，部门间也不互相陷害抱怨了。公司发展速度蹭蹭的。

老板看着形式这么好，也不抠门了。奖金福利随之而来。老板看着公司产品销售这么好，也不用再为公司生存发愁了，不用随处找单子养活了，给开发部门更带来了专业理顺的计

划发展。老板也开始重视研发部门了，研发部门在公司的地位高多了，给与研发部门的资源和支持也更多了。

OH，My God!

回头过来想象，觉得程序员是个可敬同样也很可悲的职业，至少我觉得在国内是这样。可敬的是，程序员可以为了解决某个技术难题，或者为了紧张的项目进度，常常废寝忘食，没日没夜的加班。技术水平与日俱增。很快到达一个高度，成为圈子中的高手，公司中不可缺少的万金油。可悲的是，随着无休止的加班，自己的生活全没了，程序就是生活的全部，每天除了吃饭睡觉就是写程序。很少有自己的生活，看看依然奋斗在第一线的同志们就知道了，好多连交女朋友的时间都没有。

每个人都需要好好规划自己的人生规划自己的职业，特别是程序员。如果不做规划，过些年年龄大了，有家有口的时候，再想加班去解决技术问题已经是很困难了。家庭不允许，生活不允许，身体也不允许。

那么程序员该如何规划自己的职业生涯呢？

前段时间，博客园里面大家都在写自己2008年的愿景与规划，可是又有多少人做到了自己长久的规划呢？前面我没有去写，因为那个时候转型过渡期，软件研发部门的事情需要去做，销售部门的事情需要去学习，忙的不可开交，现在终于空闲了，可以多和园子里面的朋友交流一下了。

其实我一直都很喜欢.NET程序，也一直都在这个圈子里面摸爬滚打，不做程序员了，不妨碍我仍然是个不错的程序员和项目经理。在客户谈项目的时候我不用向其他销售一样需要有售前工程师做支持，只要不开发我都可以和客户去沟通。技术方案也可以自己写，也可以详细规划好了之后交给售前咨询去写。自己的时间充裕了之后，也常常学习跟踪微软新的平台，还常常给软件研发部门做公司内训，交流自己曾经的心得体会。

至少我已经给自己做了规划，并且付诸行动，做了一名软件销售，你呢？

1.

书名：Microsoft .NET框架程序设计（修订版）

作者：Jeffrey Richter

译者：李建忠

出版日期：2003 年11月

出版社：清华大学出版社

推荐理由：框架设计是我看的第一本真正意义上的.NET书籍，之前看过很多，但都是工具类的。如果仅仅把.NET作为开发程序的工具，那些书就足够了。但是.NET绝不仅仅是个工具，它是一种思想、一个平台。要想深入学习，必须对其Framework有所了解。《Microsoft .NET框架程序设计（修订版）》无疑是学习.NET Framework最好的一本。李健忠老师的翻译通俗流畅，并且字里行间流露着他对.NET的深刻理解。这本书陪伴我度过了研究生期间很多无聊的课程。不过初学者看这本书开始也许会很费劲，有一次一个同搞.NET的同学拿过去翻了翻就扔给了我，说：看不懂。

2.

书名：重构：改善既有代码的设计（中文版）

作者：Martin Fowler

译者：侯捷，熊节

出版日期：2003 年9月

出版社：中国电力出版社

推荐理由： 重构，这个既简单又深奥的概念直到现在仍然吸引着广大设计爱好者。几年前当我几乎被这个名词弄晕的时候，我找到了这本书——重构的诞生地。它同样是我的“课堂书籍”。与《框架设计》不同的是，它的概念和理论十分简单，即使对编程只有一点点的认识，也能很惬意的阅读本书。因为它所阐述的，就是我们程序员平时所做的——修改代码。但如何更好的修改，使其更符合OO标准，又是一个非常复杂的过程。

3.

书名：敏捷软件开发：原则、模式与实践

作者：Robert C. Martin

译者：邓辉

出版日期：2003 年9月

出版社：清华大学出版社

推荐理由： Bob大叔最脍炙人口的作品。如果你看过《设计模式》与《重构》，那么推荐你接着看这本，对于设计模式的理解就会上升一个层次。熟练掌握各种设计原则，我们就不必再死记那些刻板的模式。只要我们的设计复合原则，就是一个良好的设计。《设计模式》、《重构》和《敏捷软件开发》是设计爱好者必读的三本书。

4.
书名：ASP.NET 2.0揭秘

作者：Stephen Walther

译者：谭振林，黎志，朱兴林，马士杰

出版日期：2007 年10月

出版社：人民邮电出版社

推荐理由：将近一年没有搞ASP.NET了，因此这本书买来也束之高阁。但此书1.1版本却令我印象深刻。当年就是那本绿皮的《ASP.NET揭秘》把我领进了ASP.NET的殿堂。我甚至一度认为其它的ASP.NET书都是垃圾（特别是清华大学出版的Wrox的红皮书，其实是翻译的太烂）。虽然2.0版本的中文版姗姗来迟，但是我仍然认为它值得收藏。特别是四位国内MVP的加盟，一定不会让人失望。越来越多的技术高手加入到写书译书的队伍中来，会彻底改变国内翻译书籍没法看的尴尬局面。

5.

书名：Head First设计模式（中文版）

作者：Eric Freeman，Elisabeth Freeman，With Kathy ierra，Bert Bates

译者：O'Reilly Taiwan公司

出版日期：2007 年9月

出版社： 中国电力出版社

推荐理由：这是一本让人拍案叫绝的书，它用浅显风趣的语言和别具一格的表现形式，把《设计模式》中天书一般的理论展现的精妙绝伦。如果你对设计模式还一知半解，或被《设计模式》中晦涩的文字搞得晕头转向，那么赶快来阅读本书吧。然而从某种意义上说，《Head First设计模式》是一本不能看的书，因为你一旦看过，会对其它的书倍感失望。所谓曾经沧海难为水是也。

6.

书名：重构与模式

作者：Joshua Kerievsky

译者：杨光，刘基诚

出版日期：2006 年12月

出版社：人民邮电出版社

推荐理由：很遗憾，我是在看完《Head First设计模式》后看得这本书，因此对其语言的易读性很是失望。甚至一度把它放回了书架上。但是这并不代表它不是一本经典书。它将重构与模式完美的结合，使我们明白了设计是按照设计原则将代码重构成模式的过程。

7.
书名：C#和.NET 2.0 实战:平台、语言与框架

作者：Patrick Smacchia

译者：施凡，李永伦，谭颖华，徐宁

出版日期：2008 年1月

出版社：人民邮电出版社

推荐理由：不管你使用什么语言进行开发，都希望手头有一本大而全的参考书。否则东一本框架、西一本语法，南一本WinForm，北一本ASP.NET，会把人搞得很崩溃。尽管Google和百度在绝大多数情况下可以解决问题，但是万一没有网络呢？《C#和.NET 2.0 实战》就是这样一本书，它包罗.NET的万象，编程时遇到任何问题都可以先翻开本书寻找答案。如果你是一个.NET程序员，案边放这样一本书是再适合不过了。我在读书小组推荐过这本书。

8.

书名：企业应用架构模式

作者：Martin Fowler

译者：王怀民，周斌

出版日期：2004 年7月

出版社：机械工业出版社

推荐理由： 秉承Martin Fowler一贯的通俗易懂的写作风格，用最浅显的语言描述复杂的概念。书中所列举的各种模式，我们肯定都或多或少使用过。本书是分层设计的指导书。

9.

书名：.NET 设计规范——.NET约定、惯用法与模式

作者：Krzysztof Cwalina，Brad Abrams

译者：葛子昂

出版日期：2006 年7月

出版社： 人民邮电出版社

推荐理由： 你是否修改过别人的代码？你是否因为混乱的命名规则和晦涩的变量名称抓狂？如果所有.NET程序员都读过《.NET 设计规范》，这一切也许就不会发生了。它虽然名称为“Framework Design Guidelines”，但实际上不仅仅是指导我们如何编写框架，它本身就是.NET Framework的设计规范。我们平时在做任何开发，哪怕是最简单的工具时，也应该遵循书中所提出的标准。

10.

书名：设计模式：可复用面向对象软件的基础

作者：Erich Gamma，Richard Helm，Ralph Johnson，John Vlissides

译者：李英军，马晓星，蔡敏，刘建中

出版日期：2004 年9月

出版社： 机械工业出版社

推荐理由：之所以最后推荐本书，并不是因为它不如前几本，相反，它应该是所有设计爱好者的第一本书。但它太晦涩了，它就像是一本武林秘籍，不是所有人都能参透其中的奥秘。然而幸好很多高手练成绝世武功后，把他们的心得写了出来，这些心得要好理解得多。因此《Head First设计模式》、《设计模式解析》、《Java与模式》等应该称为设计模式初学者的首选。