前言：很多做开发的人都在不断的摸索着，积极的学习，试图找出一条走向架构设计的成功法则。每当有人问起我们的职业，我们也常常在说:”软件设计”。有时，我就在想:”设计”，这个已经被我们嚼烂了的词，到底有多少人真正懂”设计”的含义。
自动进入IT，走在开发这条路上，就一直在不断的摸索，寻找，苦思：如何能够才能成为架构师。于是在网络上不断的收集和阅读架构设计方面的书籍和资料，到处在找一些架构师的传记，文章和甚至是采访资料.....
同时一直不断的请教自己的一些前辈，或者同事，不同人都不同的说法，有人说：搞架构的，要懂很懂底层例如从汇编到C，要懂算法, 有人说：要懂很多语言，例如Java, C++,C#等，而且要懂很多的数据库SQL SERVER, Oracle，还有人说：对技术很因为我都要很熟，还有人说：架构师起码要搞十几年才行....最后给我的感觉就是：什么都要懂，要很精，那就是“简直神”级别的人物：无所不知，无所不通。
架构设计，被成真正的有技术的劳动，架构师，也几乎是神话般的职位，也是很多开发人员梦寐以求的目标。常常是谈架构就肃然起敬。每次只要看到比自己强的人，心里一阵欣喜：可以想他们学习，请教。 我想不仅仅是我，很多搞开发的朋友也正走在这条路上，也许这条路永远没有尽头。也许离“架构师“所需的水平还相差N远，但是有些东西需要分享给大家，共勉，学习。
本系列文章是将会介绍在项目中如何使用设计模式，面向对象设计原则以及best practice. 我将会以开发ASP.NET项目为例子来讲述，当然，因为模式等这些知识是语言无关性的，也就是说，在这里讲述的使用方法和经验技巧在WinForm，WPF，Silverlight同样适用。
经过半年的打造，本系列文章几十万文字的草稿已经完成，现在处于后期的整理和审稿中，并且会定期发布，本系列的特点是：实战的例子比较的多，每一个概念都有会展开的讲述。几乎每个概念都都有完整的代码例子，而且系列的最后将带领大家用这些知识开发一个比较真实的项目，希望大家多多的支持！
青涩的历程
编程很多的时候都是Hello World开始的，然后开始学习一些Demo，慢慢的学习一些示例项目，然后就开始在自己的项目中进行模仿。
记得当时PetShop出来之后，被称为了三层设计的典范，我看到很多的项目的结构都是完完全全的把PetShop"山寨"了一遍：代码的结构，类库的名字几乎都是一样。于是大家就在模仿中一步步的走了出来，在后头看看，有的人已经完全理解了PetShop的思想，懂得其"神"，也许还有的人还是停留在"形"。
后来设计模式被炒的火了起来，于是模式开始”横行”，常常听到有人听说“面向对象设计就是使用设计模式开发项目“。于是在项目中开始蹩脚的，刻意的使用设计模式。甚至拿着设计模式的书籍，对照自己的代码一步步的改，最后把自己的代码改为书上某个模式描述的结构。开始刻意的使用时在所难免的，如果仅仅只是停在设计模式中描述的的代码结构，即”形“上，而不理解背后的”神“，那么我们就很那达到那种应用自如，自然流露的地步。
我也看到也很多的项目采用TDD，TDD是的好东西。但是很多的项目中还是“望文生义“：测试驱动开发---就是要写测试。这个测试就用来测试功能代码的。于是项目中的每个方法都有对应的测试，很多人埋怨TDD就是体力活，而且使用了TDD，什么好的效果都没有看到，只是不断的无畏的拖延项目的时间，而且后来竟然还是先写功能代码，再补上测试代码。理解还是停在了TDD的”形”上，没有领会得其”神”。写测试很容易，写好的测试就不容易。会弹钢琴和会演奏是两码的事。
DDD开始被被推崇，于是项目中到处出现和DDD有关的一些词语:Entity, Repository, Aggregate, Service等。原本大家很熟悉的一些名字，例如BLL, DAL被这些”新”的词语冲乱了。而且常常在纠结：Customer是作为聚合，那么Order需要作为聚合吗？等等。
而且在项目一些的类库的名字就开始混乱：Present, BLL, Repository…等等，各种组合。这只是说明：对DDD的理解还是停在”形”上。
之所以说这个过程是“青涩“，因为不成熟，常常是硬套，结果是使用起来不爽，而且问题多----为了使用而使用。这个过程就好比买衣服：在买衣服的时候，不是从个人的身型和喜好出发，而是先看衣服，然后用衣服来”套”人，难免让人不舒服。
什么是设计
前面闲话了N多，来看看什么是设计。有一点，我想有一点大家是认同的：“设计”一定要把软件正确的实现。可是编程的现状不是这样的，编程被认为是没有思想的体力活，因为编程中没有加入思考。在建筑中，建筑工程师和民工的区别就在对建筑的“思考”上。
设计就是思考的过程。在这个过程中思考软件如何做出来。大家很多都看过Wrox出版的系列书籍：Problem-Design-Solution。请问为什么会是：Problem-Design-Solution。
对于每一个要实现的功能，就是我们要解决的问题，即为Problem.
要解决这个问题，实现功能，我们要经过思考，给出一些方案，这些方案往往不止一个，这个过程就是Design，寻求解决问题的方案。
经过选择，权衡，最后选取的Design就是成为这个问题的解决方案，即为Solution
其实任何功能的设计，基本上都是上面的三个步骤。其中在Design阶段，所提出的方案一定是可以解决问题的，但是方案之间肯定各有利弊。而且在Design阶段，基本上只要方案出来，实现的代码骨架和流程在头脑中起来有了70%-80%，也就是说，一旦Design中的某一个方案被定为最终方案，要做的事情只是把头脑中的想法”copy”到代码中而已。这样，起码代码是经过深思熟虑出来的，出错率降低，项目的可控性就增加了。
简单的说，设计就是：，在头脑中对于某个问题的清晰的实现过程。
走近设计
整个的项目的开发过程就是对已一个个划分的功能实现的过程，也是一次次重复Problem-Design-Solution的过程。在软件开发中，有很多的开发模式，例如TDD,BDD,DDD等，还有一些不知名的，这些开发模式在Problem-Design-Solution的基础上分别融入了自身的一些特性，例如DDD，就是把关注点放在建模上。但是不管采用那种开发的模式，思想还是一样的：提出问题，分析问题，解决问题（Problem-Design-Solution）。
就像当初我们在学习计算机编程的时候，虽然有很多的编程语言可以实现编程，但是教材往往只选择一种语言，例如Pascal，只要讲明编程的思想就行了。下面就以TDD为例子，来讲述如何设计。
本篇和下篇文章用TDD为例子，思想到了就可以了。相信很多朋友都看过"功夫熊猫”，熊猫的师傅从来没有教给熊猫那一招"一阳枯指"，但是熊猫最后自己却会使用，后来其他弟子问师傅为什么，师傅说“境界到了”。
统一基本概念
马上要以TDD为例子，尽管很多的文章已经讲述了TDD的一些理论和方法，个人认为有必要在此之前，先统一 一些概念，以便加深TDD中的理解。而且我还会讲述一些不一样的东西。接下来的文章不会纯粹的理论，都是实战结合的，做到言之有物。
Test: 测试。一个测试就是用一个系统的方法或者步骤来确保程序的一个功能是正确的。
Pass: 我们说某个功能Pass，就表明这个功能运行正确。在TDD中，常常用绿色来表示Pass.
Fail: 说明某个功能没有按照我们预期的运行。TDD中，常用红色表示。
xUnit:其实xUnit就是指从sUnit演化而来的那些Test Framework的统称，包含：nUnit（.NET中的一种测试框架）, jUnit（Java中的一种测试框架）,qUnit（.jQuery中的测试框架））等。
Test Fixture: 表示测试在被运行之前必须进入的一种状态。 这种状态就是代表在一个测试运行之前有一些对象要被准备。
Test Driven Development(TDD):是敏捷开发过程的一种，主要特定就是在写功能代码前先为它写测试代码。
Behavior Driven Development(BDD):建立在TDD的基础之上，BDD的主要目的利用TDD在设计和编档方面的优势来为用户的业务增值。
Test Double: 当我们在进行单元测试的时候，如果不能使用真实的组件的时候，我们用来替换真实组件的那个对象就称为 test double。
Stub:很多书上把它翻译为“桩”，其实它也是test double的一种，也是一种替换品，往往stub的对象不实现交互，只是作为一种输入或者输出来验证正确性。
Mock：可能大家对这个见的比较多，现在就有很多流行的mock框架。Mock，也是test double的一种，和stub意义很类似，但是mock往往被用来模仿行为比较复杂的对象。
Fake：它也是test double 的一种，与stub不同的是，fake的对象有实现了少量的交互功能，以便某个方法的测试更加容易。
今天就暂时写到这里：下一篇进入实战: 测试 & 设计
