设计模式实践之极限编程概述.pptVIP

设计模式实践 极限编程概述 2.1　极限编程实践 　　2.1.1　完整团队　 　　2.1.2　用户故事　 　　2.1.3　短交付周期　 　　2.1.4　验收测试　 　　2.1.5　结对编程　 　　2.1.6　测试驱动开发　 　　2.1.7　集体所有权　 　　2.1.8　持续集成　 　　2.1.9　可持续的开发速度　 　　2.1.10　开放的工作空间　 　　2.1.11　计划游戏　 　　2.1.12　简单设计　 　　2.1.13　重构　 　　2.1.14　隐喻　 2.2　结论 第 2 章 * 第一页，共十八页。 XP的价值观 （1）沟通 （2）简单 （3）反馈 （4）勇气  * 第二页，共十八页。 基本原则 （1）快速反馈 （2）简单性假设 （3）逐步修改 （4）提倡更改 （5）优质工作 * 第三页，共十八页。 极限编程的12条原则 1、小版本 为了高度迭代，与客户展现开发的进展，小版本发布是一个可交流的好办法，客户可以针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划。 2、规划游戏 就是客户需求，以客户故事的形式，由客户负责编写。极限编程不讲求统一的客户需求收集，也不是由开发人员整理，而是采取让客户编写，开发人员进行分析，设定优先级别，并进行技术实现。当然游戏规则可进行多次，每次迭代完毕后再行修改。客户故事是开发人员与客户沟通的焦点，也是版本设计的依据，所以其管理一定是有效的、沟通顺畅的。 * 第四页，共十八页。 3.现场客户 极限编程要求客户参与开发工作，客户需求就是客户负责编写的，所以要求客户在开发现场一起工作，并为每次迭代提供反馈。 * 第五页，共十八页。 4.隐喻 隐喻是让项目参与人员都必须对一些抽象的概念理解一致，也就是我们常说的行业术语，因为业务本身的术语开发人员不熟悉，软件开发的术语客户不理解，因此开始要先明确双方使用的隐喻，避免歧异 * 第六页，共十八页。 5.简单设计极限编程体现跟踪客户的需求变化，既然需求是变化的，所以对于目前的需求就不必过多地考虑扩展性的开发，讲求简单设计，实现目前需求即可。简单设计的本身也为短期迭代提供了方便，若开发者考虑“通用”因素较多，增加了软件的复杂度，开发的迭代周期就会加长。简单设计包括四方面含义： （1）通过测试。 （2）避免重复代码。 （3）明确表达每步编码的目的，代码可读性强。 （4）尽可能少的对象类和方法。由于采用简单设计，所以极限编程没有复杂的设计文档要求。 * 第七页，共十八页。 6.重构 重构是极限编程先测试后编码的必然需求，为了整体软件可以先进行测试，对于一些软件要开发的模块先简单模拟，让编译通过，到达测试的目的。然后再对模块具体“优化”，所以重构包括模块代码的优化与具体代码的开发。重构是使用了“物理学”的一个概念，是在不影响物体外部特性的前提下，重新优化其内部的机构。这里的外部特性就是保证测试的通过 。 * 第八页，共十八页。 7.测试驱动开发　 极限编程是以测试开始的，为了可以展示客户需求的实现，测试程序优先设计，测试是从客户实用的角度出发，客户实际使用的软件界面着想，测试是客户需求的直接表现，是客户对软件过程的理解。测试驱动开发，也就是客户的需求驱动软件的开发。 * 第九页，共十八页。 8　持续集成 集成的理解就是提交软件的展现，由于采用测试驱动开发、小版本的方式，所以不断集成(整体测试)是与客户沟通的依据，也是让客户提出反馈意见的参照。持续集成也是完成阶段开发任务的标志。 * 第十页，共十八页。 9.结对编程　 这是极限编程最有争议的实践。就是两个程序员合用一台计算机编程，一个编码，一个检查，增加专人审计是为了提供软件编码的质量。两个人的角色经常变换，保持开发者的工作热情。这种编程方式对培养新人或开发难度较大的软件都有非常好的效果。 　 * 第十一页，共十八页。 10.代码共有 在极限编程里没有严格文档管理，代码为开发团队共有，这样有利于开发人员的流动管理，因为所有的人都熟悉所有的编码。 * 第十二页，共十八页。 11.编码标准 编码是开发团队里每个人的工作，又没有详细的文档，代码的可读性是很重要的，所以规定统一的标准和习惯是必要的，有些象编码人员的隐喻。 12.每周40小时工作 极限编程认为编程是愉快的工作，不轻易加班，今天的工作今天做，小版本的设计也为了单位时间可以完成的工作安排。 　 　 * 第十三页，共十八页。 设计模式实践