什么是敏捷开发？ 九十年代末，几种方法学开始不断获得公众的注意。每种方法学都是对已有开发方法、新开发方法以及转变后的已有开发方法进行不同组合。但是它们都强调研发团队和业务专家之间的紧密协作、面对面的沟通（因为比文档更高效）、频繁地交付新的可部署的商业价值、紧密的自我管理的团队、精致开发代码和管理团队的方法，以使不可预见的需求不再是一场灾难。 敏捷开发的历史 2001年2月11日到13日，在美国犹他州Wasatch山的滑雪圣地Snowbird的一幢大楼里，17位轻量级过程专家通过这次会议形成了敏捷软件开发运动，其中包括了：极限编程（eXtremeProgramming, XP）、Scrum、动态系统开发方法（Dynamic SystemsDevelopment Method，DSDM）、自适应软件开发（AdaptiveSoftware Development，ASD）、Crystal方法、特性驱动方法（Feature-DrivenDevelopment，FDD）、实用程序设计等。这些业界专家概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，目的是推进敏捷开发方法的研究和应用。会议的结果是17名与会者共同签署并发布了“敏捷软件开发宣言”（TheManifesto for Agile Software Development）,敏捷联盟（AgileAlliance）由此诞生。 敏捷开发的核心价值-特点和优势 个体和交互胜过过程和工具 人是获得成功的最为重要的因素。如果团队中没有优秀的成员，那么就是使用好的过程也不能从失败中挽救项目，但是，不好的过程却可以使最优秀的团队成员失去效用。如果不能作为一个团队进行工作，那么即使拥有一批优秀的成员也一样会惨败。团队的构建要比环境的构建重要得多。许多团队和管理者就犯了先构建环境，然后期望团队自动凝聚在一起的错误。相反，应该首先致力于构建团队，然后再让团队基于需要来配置环境。 可以工作的软件胜过面面俱到的文档 没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。然而，过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间，并且要使这些文档和代码保持同步，就要花费更多的时间。如果文档和代码之间失去同步，那么文档就会变成庞大的、复杂的谎言，会造成重大的误导。虽然从代码中提取系统的原理和结构信息可能是困难的，但是代码是惟一没有二义性的信息源。在团队成员的头脑中，保存着时常变化的系统的脉络图（roadmap）。人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。 客户合作胜过合同谈判 不能像订购日用品一样来订购软件。你不能够仅仅写下一份关于你想要的软件的描述，然后就让人在固定的时间内以固定的价格去开发它。所有用这种方式来对待软件项目的尝试都以失败而告终。有时，失败是惨重的。告诉开发团队想要的东西，然后期望开发团队消失一段时间后就能够交付一个满足需要的系统来，这对于公司的管理者来说是具有诱惑力的。然而，这种操作模式将导致低劣的质量和失败。成功的项目需要有序、频繁的客户反馈。项目的需求基本处于一个持续变化的状态。大的变更是很平常的。在这期间，也会出现整个功能块被减掉，而加进来另外一些功能块。然而，合同和项目都经受住了这些变更，并获得成功。成功的关键在于和客户之间真诚的协作，并且合同指导了这种协作，而不是试图去规定项目范围的细节和固定成本下的进度。 响应变化胜过遵循计划 响应变化的能力常常决定着一个软件项目的成败。当我们构建计划时，应该确保计划是灵活的并且易于适应商务和技术方面的变化。计划不能考虑得过远。 敏捷开发的十二条原则 我们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 围绕被激励起来的个人来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。 可以工作的软件是首要的进度度量标准。 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 不断地关注优秀的技能和好的设计会增强敏捷能力。 简单——把无需做的工作最大化的艺术——是最根本的。 最好的构架、需求和设计出于自我组织的团队。 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整 敏捷开发的一些方法 完整团队XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。 计划游戏计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。 客户测试作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。 结对编程所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。 测试驱动开发 编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功能能验证方面的反馈循环。自动单元测试可以使研发工作和测试工作并行化。 改进设计随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。 持续集成团队总是使系统完整地被集成。只要有可能就进行代码集成，周期可以在几个小时，最好不要超过一天。持续集成可以避免错误的积累，可以增加可重用的代码。在一个结对小组认为适当的时候并通过了所有的单元测试，就可以进行集成，集成后的代码必须通过测试。 集体代码所有权任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。 不要加班 尽可能不要加班，大多数加班并不能挽回已有的延迟，连续超过两个星期的加班说明有问题存在。向一个已经延迟的项目填加人员也不是一个好的选择。 附录-极限编程 1999年KentBeck提出的ExtremeProgramming（XP）是轻量级方法中最引人注目的一个。XP基于沟通、简单、反馈、勇气四个核心价值提出了完整团队（WholeTeam）、计划博弈（PlanningGame）、隐喻（Metaphor）、小规模交付（Smallrelease）、单元测试（Unittest）、简单设计（SimpleDesign）、结对开发（PairProgramming）、重构（Refactoring）、持续集成（ContinuousIntegration）、代码集体所有制（Collective codeOwnership）、编码标准（CodingStandard）、可持续步调（SustainablePace）等十二个核心实践。XP是目前发展应用得最活跃的方法，适用于需求模糊和挥发性强的场合。从2000年起，关于XP研究的年会年年召开，对XP方法的过程、原则、适用性等各方面的讨论大大丰富了XP的方法和理论。Mark C.Paulk提出XP是CMM的一个截面，LaurieWilliams在结对编程方面进行了深入的研究，Roy W.Miller对XP实践进行了修订，提出XP的19个实践。 附录-SCRUM 1993年KenSchwaber和JeffSutherland提出SCRUM，是对迭代式面向对象方法的改进。SCRUM提出的SCRUMMeeting、Sprint等模式。SCRUM将工业过程控制中的概念应用到软件开发中来，认为软件开发过程更多是经验性过程（EmpiricalProcess），而不是规约性过程（DefinedProcess）。 附录-Crystal 1999年Alistair Cockburn提出CrystalMethodologies。与其它敏捷方法的提出者不同，Cockburn的研究基于对IBM公司近四十个项目案例的调查。他认为不同的项目需采用不同的开发方法，并随着开发，进行连续不断的过程改进。据此他提出了一系列方法（CrystalClear、CrystalYellow、CrystalOrange、CrystalRed等）。Crystal方法强调以人和沟通为中心，强调对方法的选择和调整要考虑两个因素，一是充分发挥考虑人的特长，二是满足待开发软件的可靠性要求。刚好够用的方法论成为Crystal的基本原则之一。相对于人和团队，过程是第二位的，因此，过程应该被最小化，即“刚好够用”。 附录-DSDM 1994年DynamicSystems Development Methodology（DSDM）由英国16家公司的联盟发起，应用范围也不再限于IT行业。DSDM的基本观点是，任何事情都不可能一次性的圆满完成，在时间进度和可用资源预先固定的情况下，力争需求的最大化满足，提出了时间框（TimeBox）技术、MoSCoW（MustdO，Shoulddo，CoulddO，Won’tdo）优先级排序、工作间（Workshop）等方法。 附录-FDD Feature DrivenDevelopment（FDD）是由PeterCoad、Jeff deLuca、EricLefebvre共同开发的一套针对中小型软件开发项目的开发模式。所谓的特征点（Feature）是一些用户认为有用的小功能项，一个特征点能在两周或更短的时间内被实施，且产生可见的、能运行的代码。FDD将开发过程分为五个过程，每个过程指南采用ETVX（EntryCriteria，入口准则；Task，任务；Verification，评审确认；eXitCriteria，出口准则）方法描述，并明确了哪些角色参与哪些子任务，哪些子任务是可选的、哪些是必须的。 附录-自适应软件开发 1994年J.Holland在圣达菲（SantaFe Institute，SFI）研究所正式提出了比较完整的复杂自适应系统（ComplexAdaptive System，CAS）理论，认为在一定环境中的主体相互竞争和合作，导致系统产生突变。JimHighsmith基于复杂自适应系统理论提出了自适应软件开发（AdaptiveSoftware Development，ASD），旨在通过提高组织的自适应力以应对极度变化、难以预测的快速软件开发要求。开发组织的首要目标是快速响应变化，即提高适应力，而适应力只能孕育，不能通过命令和控制来获得，ASD提出“领导—协作”模型来提高组织的自适应力。Highsmith提出了基于有机原则的模式概念以区别于机械的过程，认为过程的实现方式必须能让项目团队成为一个有机的活跃的生态系统。他给出了一种过程分类方案：严密过程、灵活过程、问题求解过程，并强调问题求解过程是软件开发的创新核心。

S.O.L.I.D S.O.L.I.D是面向对象设计和编程(OOD&OOP)中几个重要编码原则(ProgrammingPrinciple)的首字母缩写。 SRP :The Single Responsibility Principle单一责任原则 OCP :The Open Closed Principle 开放封闭原则 LSP :The Loskop Substitution Principle里氏替换原则 DIP :The Dependency Inversion Principle依赖倒置原则 ISP :The Interface Segregation Principle接口分离原则 单一责任原则： 当需要修改某个类的时候原因有且只有一个（THERE SHOULD NEVER BE MORE THAN ONE REASONFOR A CLASS TOCHANGE）。换句话说就是让一个类只做一种类型责任，当这个类需要承当其他类型的责任的时候，就需要分解这个类。 比如：报表的内容和报表的格式都会变化改变，但是这两种变化的性质不同，一个是实质内在，一个是表面上的，SRP认为这是问题的两个方面，其实代表不同的职责，应该将它们分离放入不同的类或模块中，而不应该放在一起，否则的话，因为不同原因发生变化，导致对方变动，比如报表格式变新的样式，这个变化是不应该涉及到内容的。 反模式: 一个类处理的事情太多了, 应当进行分解 开放封闭原则 软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。这个原则是诸多面向对象编程原则中最抽象、最难理解的一个。 反模式: 一个模块的修改将导致其他模块的修改 里氏替换原则 当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有is-A关系 子类可以代替基类, 客户使用基类, 他们不需要知道派生类所做的事情. 反模式: if(a instanceof TypeA) {…} 这是一个针对行为职责可替代的原则，如果S是T的子类型，那么S对象就应该在不改变任何抽象属性情况下替换所有T对象。这里的抽象属性是指对象的字段属性。 我们使用接口时经常碰到一个问题，需要使用接口子类中的方法，而接口中没有这个方法，那么只能要么修改接口，要么将接口downcast为具体子类。为什么会出现这个尴尬现象？有几种情况导致，其中一种情况是是将当前的类重构到接口时，没有将类中所有方法extract到接口中，可能因为这些被你漏掉的方法不属于当前接口，那么，它又违背了单一职责原理，说明你当前这个类的方法设计得又不合理。 所以，如果单一职责设计的足够好，那么LSP原则则是检验的方法。LSP原则是对对象职责和协作的一种检验约束方法，此外还有DBC(designby contract)原则，为了保证实现接口的子类职责行为的约束，DBC三要素都必须被重视满足： Preconditions前置条件不能在子类中被强化。 Postconditions后置条件不能在子类中被弱化。 子类自身不变性Invariants必须在子类自己中封装满足。这也是前面“不改变任何抽象属性”的意思。 依赖倒置原则 高层模块不应该依赖于低层模块，二者都应该依赖于抽象 抽象不应该依赖于细节，细节应该依赖于抽象 要针对接口编程，不针对实现编程。 接口分离原则 不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。 反模式：肥类(fat class), 有成堆的方法, 而且用户很少使用 SOLID原则如今在DCI架构中能够得到真正实现和发展。