一个普遍的哲学问题是源代码是不是一个模型，更重要的，它是不是一个敏捷模型。如果你是在我们这篇文章之外问我这个问题，我会回答说，是，源代码是一个模型，虽然是一个高度细节化的模型，因为它是软件的一个抽象。同时我还认为，优秀的代码是一个敏捷模型。但在这里，我还需要把两者区分开来，源代码和敏捷模型还是有区别的——敏捷模型帮助你得到源代码。

 

敏捷建模者的个性

Alistair Cockburn指出：很多的方法学都定义了软件开发项目中开发人员所担任的角色，同时还定义个各个角色执行的任务，尽管入席，这些方法并没有定义这些角色最适合的人选。一个人要想成功的担任某个角色，他应当很好的适应它－－虽然这并不需要人们掌握所有的技能，但人们必须要慢慢的熟悉这些技术。我的经验告诉我，要成为一个成功的敏捷建模者，下面的列出的个性是必要的：

第一点，也是最重要的一点，敏捷建模者总是积极的寻求协作，因为他们意识到他们不是万事通，他们需要不同的观点，这样才能做到最好。软件开发可不是游泳，单干是非常危险的。在敏捷的字典中没有“我”这个词。

敏捷建模者都有良好的沟通技巧－－他们能够表达出他们想法，能够倾听，能够主动获取反馈，并且能够把需要的写出来。

敏捷建模者应当脚踏实地 他们的精力都集中在满足用户的需求上，他们不会在模型上画蛇添足，即便那双足是多么的好看。他们满足于提供可能的方案中最简单的一种，当然，前提是要能够完成工作。

敏捷建模者乐衷于研究问题，解决问题。

敏捷建模者看问题从不会至于表面，而是会打破沙锅问到底。他们从不会就想当然的认为一个产品或一项技术和它们的广告上说的那样，他们会自己试一试。

敏捷建模者都非常的谦逊，他们从不认为自己是个万事通，所以他们会在建立好模型之后，用代码来小心的证明模型的正确。

敏捷建模者应当愿意尝试新的方法，例如一项新的（或是已有的）建模技术。一般而言，他们也会接受敏捷建模开发技术，必要时，为了验证想法，他们愿意同传统的思想做斗争，例如在一个项目中减少文档数量。

要坚持不懈的遵循敏捷建模的实践。对你来说，你可能会在不经意间说，“加上这个功能吧！无伤大雅。”或是，“我比project stakeholder更了解。”在AM的道路上要想不偏离方向，是需要一定的纪律性的。

走出一般性的设计误区，迈向成功之途 无论你遵从的是重量级的方法，比如Enterprise Unified Process(EUP），还是轻量级的开发过程，如Extreme Programming(XP），建模在软件开发中都是不可或缺的。但不幸的是其中充斥着各种谬误与迷思。这来自于各个方面，有从理论家错误的研究、数十年来信息技术领域内的文化沉积、软件工具开发商天花乱坠半的市场宣传以及象Object Management Group (OMG）和IEEE这类组织的标准。下面，我们要揭示建模中的误区，指出其相应的事实真相。

建模就等于是写文档

这很可能是其中最具破坏力的一条，因为开发人员可以此为借口而完全放弃建模。许多优秀的软件开发人员会说他们不想把时间浪费在这些“无用的“文档上。他们沉溺于编码之中，制造着一些脆弱而劣质的系统。另外，甚至于许多尽责的开发人员现在也认为建模是一件讨厌的事，而不愿去学习相应的建模技术。

事实分析：“模型”与“文档”这二者在概念上是风马牛不相及的—你可以拥有一个不是文档的模型和不是模型的文档。一幅设计图就是一个模型，而不论是被画在餐巾纸的背面，或写在一块白板上，或在Class Responsibility Collaboration(CRC)卡片中，还是根据记录在报纸和便签纸上的流程图而生成的一个粗略的用户界面原型。虽然这些都不能说是文档，但他们却都是有价值的模型。

建模很象是作计划：作计划的价值在于计划编制的过程中，而非计划本身；价值体现在建模的活动中，而非模型本身。实际上，模型不是你系统中的一部分正式的文档，而且在完成它们的使命后可以被丢掉。你会发现值得保留的只有很少的模型，而且它一定是非常完美。

从开始阶段你可以考虑到所有的一切

这种说法流行于二十世纪七十年代到八十年代早期，现今的许多经理都是在那个时候学习的软件开发。对这一点的迷信会导致在前期投入可观的时间去对所有的一切建模以期把所有一切都弄正确，试图在编码开始前就“冻结”所有的需求（见误区四），以致于患上“分析期麻痹症” – 要等到模型非常完美之后才敢向前进。基于这个观点，项目组开发了大量的文档，而不是他们真正想要得到的—开发满足需要的软件。

事实分析：怎么才能走出这个误区呢？首先，你必须认识到你不能考虑到所有的细枝末节。第二，认识到编码员可能会对建模者的工作不以为然（这是可能的，事实上建模者所作的工作在实际价值中只占很少的部分），他们或许会说模型没有反应出真实的情况。第三，认识到不管你的最初所作的规格说明书有多好，但注定代码会很快地与之失去同步，即便是你自己建模自己编码。一个基本的道理就是代码永远只会和代码保持一致。第四，认识到迭代法（小规模地建模，编一些代码，做一些测试，可能还会做一个小的工作版本）是软件开发的准则。它是现代重量级的软件开发过程（如EUP），以及轻量级（如XP）的基本原理。

建模意味着需要一个重量级的软件开发过程

走入这个误区（经常与误区一有联系）的项目组常常是连建模都彻底地放弃了，因为这样的软件开发过程对他们来说太复杂太沉重了。这不亚于一场天灾。

事实分析：你可以用一种敏捷的方式取而代之。关于用简单的工具进行简单地建模的详细内容可参看Agile Modeling(AM）。而且，你可以丢弃你的模型当使命完之后，同样也可以很基本的方式进行建模（比如，从办公桌起来，来到白板前就开始构略草图）。只要你愿意，你就可以轻松地建模。

必须“冻结”需求

这个要求常常来自高级经理，他们确切地想知道他们从这个项目组能得到什么东西。这样的好处就是在开发周期的早期确定下需求，就可以确切地知道所要的是一个什么样的东西；缺点就是他们可能没有得到实际上所需要的。

事实分析：变化总会发生的。由于优先级的变化和逐渐对系统有了更进一步的理解，都会引起需求的变化。与冻结需求相反，估计项目成功的风险，尽量去接受变化而且相应地采取行动，就象XP所建议的一样。

设计是不可更改的

如同误区四，要求每一个开发人员必须严格遵从“设计“，导致开发人员为了符合“设计“而作了错误的事情或以错误的方式作正确的事情。或者是简单地忽略了设计，否定了所有设计可能带来的好处。冻结了设计，你就不能从在项目进程中所学到知识进一步获益。另外一个很大的趋势就是开发出大量的文档而不是实际的软件，使用面向文档的CASE工具而不是能给项目带来实际价值的面向应用的工具。

事实分析：事实上，设计会经常根据开发人员和数据库管理员的反馈进行修改，因为他们是最接近实际应用的人，通常他们对技术环境的理解要好于建模者。我们必须的面对这样一个事实：人无完人，他们所作的工作也不可能尽善尽美。难道您真的想将一个并不完善的设计固定下来而不再去修改其中的错误吗？另外，如果需求并没有被冻结，其实就意味着你不能冻结你的设计，因为任何需求的修改势必影响设计。对之，正确的态度是：只要你的代码还在改动，设计就没完。

必须使用CASE工具

建模常常被认为是一项复杂的工作，因此需要大量地使用CASE工具辅助进行。

事实分析：是的，建模可以是很复杂的。但你完全可以建立一个有效而简单的模型表述其中关键的信息，而不是将一些无关紧要的细节包括进来。

比如，我经常使用UML建立模型来表示类、它们的属性及一些关键的业务操作，但并不画出属性的存取操作（get和set），以及维护与其它类关系的框架代码，或者其他一些琐碎的实现细节。我通过建模寻找解决问题的方法，让我和我的同事能继续前进去实现这个模型。以这样灵活的方式，大多数情况下我并不需要一个CASE工具来支持建模工作，一块白板，或者一台数字相机足以。这样，我就不用花时间去评估CASE工具，不用去和工具供应商讨论许可证的问题，也免去了人员培训开销。CASE工具只有当它能体现最佳性价比时（相对你自己的情况而言），才值得购买。大多数情况下，我都能不用它而达到目的（完成建模）。我经常使用的工具有Together/J/) – 因为它能产生数目可观的Java框架代码；还有ERWin（） -- 因为它能规划数据库。这两个工具真正地帮助我实现了软件开发的目的 – 制造满足用户要求的软件。但我绝大多数得建模工作仍然使用的是简单的工具，而不是CASE工具。

建模是在浪费时间

许多新手都这样认为，这主要是因为他们所接受的教育仅仅局限于如何编写代码，对于完整的开发流程鲜有接触。而且他们的经验也仅限于如何实现代码，就如初级程序员。他们放弃了提高效率和学习技能的机会，这些技能能够使他们很容易地适应不同的项目或组织。他们应该为此感到羞愧。

事实分析：在大多数情况下，在开始编码之前画一个草图、开发一个粗率的原型或者制作一些索引卡片都能提高你的生产效率。高效的开发者在编码之前都要进行建模工作。另外，建模是一种很好的在项目组成员与项目负责人之间沟通途径。你们在这个过程中探讨问题，从而对所要的是一个什么样的东西可以得到更好的理解，涉及到该项目中的每个成员也可得到对该项目有一个充分的了解。

数据模型（Data Model）就是一切

许多组织基于数据模型就蹒跚启动新的开发工作，也许正如你所在的组织：IT部门对于数据有非常严格的规定，控制着你的开发项目；或者你以前的数据库是一团糟，别无选择。

事实分析：数据模型是一个重要的但不是最重要的建模，它最好是建立在另外的模型之上。（参见“Extreme Modeling”，Thinking Objectively，Nov.2000）。这即使在象数据仓库这类面向数据的项目中也如此。如果没有很好的理解用户是如何使用该数据仓库的（在数据模型中没有表示出来），这些项目经常是以可悲的失败而告终。你可以使用的模型有很多 – 使用案例（use cases），业务规则（business rules），activity diagrams，类图（class diagrams），component diagrams，用户界面流程图（user interface flow diagrams）和CRC，等等。数据模型仅仅是其中的一种。每种模型都有其长处和短处，应该正确地使用。

所有的开发人员都知道如何建模

我们现在面临照这样一个严重的问题：许多不是开发人员的人，包括高级经理和用户，不知道软件是如何建成的。其结果，他们不能够区分开熟练的开发者和一般的程序员（当然也分不清高级程序员和一般程序员），他们想当然地认为所有的开发人员都具备从头到尾开发整个系统的技能。

事实分析：这肯定是不正确的。建模的技能，是只有当一个开发者通过学习它，并经过长期的实践才能够掌握。一些非常聪明的程序员常常相信自己无所不能，毕竟他们终究只是程序员。正因为这样的狂妄自大，他们承当的一些任务是他们根本就没有相应的技能去完成的。软件开发是如此的复杂，单单一个人是很难具备所有的技能去成功地进行开发，甚至也不可能去配置有一定复杂程度的系统。开发者应该有自知之明，明白他们自己的弱点，学无止境。通过互相取长补短，建模者可从程序员身上学到一项技术的具体细节，程序员也可从建模者那里学到有价值的设计和体系结构的技术。我个人认为所有的人，包括我自己，都是新手。

 

个体和交互 胜过 过程和工具

可以工作的软件 胜过 面面俱到的文档

客户合作 胜过 合同谈判

响应变化 胜过 遵循计划

虽然右项也有价值，但是我们认为左项具有更大的价值。

 

n 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

n 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

n 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

n 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

n 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

n 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。

n 工作的软件是首要的进度度量标准。

n 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

n 不断地关注优秀的技能和好的设计会增强敏捷能力。

n 简单是最根本的。

n 最好的构架、需求和设计出自己组织的团队。

n 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

当软件开发需求的变化而变化时，软件设计会出现坏味道，当软件中出现下面任何一种气味时，表明软件正在腐化。

n 僵化性：很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其它改动。

n 脆弱性：对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。

n 牢固性：很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。

n 粘滞性：做正确的事情比做错误的事情要困难。

n 不必要的复杂性：设计中包含有不具任何直接好处的基础结构。

n 不必要的重复性：设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。

n 晦涩性：很难阅读、理解。没有很好地表现出意图。

敏捷团队依靠变化来获取活力。团队几乎不进行预先设计，因此，不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单，并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性，持续地改进设计，以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。

为了改变上面软件设计中的腐化味，敏捷开发采取了以下面向对象的设计原则来加以避免，这些原则如下：

n 单一职责原则（SRP)

就一个类而言，应该仅有一个引起它变化的原因。

n 开放-封闭原则（OCP)

软件实体应该是可以扩展的，但是不可修改。

n Liskov替换原则（LSP)

子类型必须能够替换掉它们的基类型。

n 依赖倒置原则（DIP)

抽象不应该依赖于细节。细节应该依赖于抽象。

n 接口隔离原则（ISP)

不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。

n 重用发布等价原则（REP)

重用的粒度就是发布的粒度。

n 共同封闭原则（CCP)

包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。

n 共同重用原则(CRP)

一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。

n 无环依赖原则（ADP)

在包的依赖关系图中不允许存在环。

n 稳定依赖原则（SDP)

朝着稳定的方向进行依赖。

n 稳定抽象原则（SAP)

包的抽象程度应该和其稳定程度一致。

上述中的包的概念是：包可以用作包容一组类的容器，通过把类组织成包，我们可以在更高层次的抽象上来理解设计，我们也可以通过包来管理软件的开发和发布。目的就是根据一些原则对应用程序中的类进行划分，然后把那些划分后的类分配到包中。

敏捷设计是一个过程，不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净和富有表现力。