介绍

　　2001年为了解决许多公司软件Software团队(Team)陷入不断增长过程泥潭批业界专家起概括出了些可以让软件Software开发团队(Team)具有快速工作、响应变化能力价值观和原则他们称自己为敏捷联盟敏捷开发过程思路方法很多主要有:SCRUMCrystal,特征驱动软件Software开发(Feature Driven Development简称FDD)自适应软件Software开发(Adaptive Software Development简称ASD)以及最重要极限编程(eXtreme Programming,简称XP)极限编程(XP)是于1998年由Smalltalk社群中大师级人物Kent Beck首先倡导

　　极限编程

　　设计和编程都是人活动忘记这点将会失去切

　　-- Bjarne Stroustrup

　　极限编程(XP)是敏捷思路方法中最箸名个它是由系列简单却互相依赖实战组成这些实战结合在起形成了个胜于部分结合整体

　　下面是极限编程有效实战:

　　1、完整团队(Team)

　　XP项目所有参和者(开发人员、客户、测试人员等)起工作在个开放场所中他们是同个团队(Team)成员这个场所墙壁上随意悬挂着大幅、显著图表以及其他些显示他们进度东西

　　2、计划游戏

　　计划是持续、循序渐进每2周开发人员就为下2周估算候选特性成本而客户则根据成本和商务价值来选择要实现特性

　　3、客户测试

　　作为选择每个所期望特性部分客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作

　　4、简单设计

　　团队(Team)保持设计恰好和当前系统功能相匹配它通过了所有测试不包含任何重复表达出了编写者想表达所有东西并且包含尽可能少代码

　　5、结对编程

　　所有产品软件Software都是由两个员、并排坐在起在同台机器上构建

　　6、测试驱动开发

　　编写单元测试是个验证行为更是个设计行为同样它更是种编写文档行为编写单元测试避免了相当数量反馈循环尤其是功功能能验证方面反馈循环员以非常短循环周期工作他们先增加个失败测试然后使的通过

　　7、改进设计

　　随时利用重构思路方法改进已经腐化代码保持代码尽可能干净、具有表达力

　　8、持续集成

　　团队(Team)总是使系统完整地被集成个人拆入(Check in)后其它所有人责任代码集成

　　9、集体代码所有权

　　任何结对员都可以在任何时候改进任何代码没有员对任何个特定模块或技术单独负责每个人都可以参和任何其它方面开发

　　10、编码标准

　　系统中所有代码看起来就好像是被单独人编写

　　11、隐喻

　　将整个系统联系在起全局视图；它是系统未来影像是它使得所有单独模块位置和外观变得明显直观如果模块外观和整个隐喻不符那么你就知道该模块是

　　12、可持续速度

　　团队(Team)只有持久才有获胜希望他们以能够长期维持速度努力工作他们保存精力他们把项目看作是马拉松长跑而不是全速短跑

　　极限编程是组简单、具体实战这些实战结合在形成了个敏捷开发过程极限编程是种优良、通用软件Software开发思路方法项目团队(Team)可以拿来直接采用也可以增加些实战或者对其中些实战进行修改后再采用

　　敏捷开发

　　人和人的间交互是复杂并且其效果从来都是难以预期但却是工作中最重要方面

　　敏捷软件Software开发宣言:

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

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

　　◆客户合作　　　　　　 胜过　　　合同谈判

　　◆响应变化　　　　　　 胜过　　　遵循计划

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

　　敏捷宣言遵循原则:

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

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

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

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

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

　　◆在团队(Team)内部最具有效果并富有效率传递信息思路方法就是面对面交谈

　　◆ 工作软件Software是首要进度度量标准

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

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

　　◆简单是最根本

　　◆最好构架、需求和设计出于自组织团队(Team)

　　◆每隔定时间团队(Team)会在如何才能更有效地工作方面进行反省然后相应地对自己行为进行调整

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

　　◆僵化性: 很难对系统进行改动每个改动都会迫使许多对系统其他部分其它改动

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

　　◆牢固性: 很难解开系统纠结使的成为些可在其他系统中重用组件

　　◆粘滞性: 做正确事情比做事情要困难

　　◆不必要复杂性: 设计中包含有不具任何直接好处基础结构

　　◆不必要重复性: 设计中包含有重复结构而该重复结构本可以使用单抽象进行统

　　◆晦涩性: 很难阅读、理解没有很好地表现出意图

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

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

　　单职责原则(SRP)

　　◆就个类而言应该仅有个引起它变化原因

　　◆开放-封闭原则(OCP)

　　◆软件Software实体应该是可以扩展但是不可修改

　　◆Liskov替换原则(LSP)

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

　　◆依赖倒置原则(DIP)

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

　　◆ 接口隔离原则(ISP)

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

　　◆重用发布等价原则(REP)

　　◆重用粒度就是发布粒度

　　◆共同封闭原则(CCP)

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

　　◆共同重用原则(CRP)

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

　　◆无环依赖原则(ADP)

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

　　◆稳定依赖原则(SDP)

　　◆朝着稳定方向进行依赖

　　◆稳定抽象原则(SAP)

　　◆包抽象程度应该和其稳定程度致

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

　　下面举个简单设计问题方面模式和原则应用举例:

　　问题:

　　选择设计运行在简易台灯中软件Software台灯由个开关和盏灯组成你可以询问开关开着还是关着也可以让灯打开或关闭

　　决方案:

　　下面图1是种最简单解决方案Switch对象可以轮询真实开关状态并且可以发送相应turnOn和turnOff消息给Light



　　图1

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