??xml version="1.0" encoding="utf-8" standalone="yes"?>
XP是勇气,交流Q反馈和单?br />XP是Y件开发过E中的纪律,它规定你Q必d~程前些试Q必M个h一LE,必须遵守~程规范……?br />XP是把最好的实践l验提取出来QŞ成了一个崭新的开发方法?/p>
2. XP适用范围:
极限~程Q也被叫做XPQ适用于中型团队在需求不明确或者迅速变化的情况下进行Y件开发的轻量U方法学?br />推荐使用范围?0人左右的团队
3.XP工作模式体现:
一、工作环?br />二、立式晨?br />三、结对编E?br />四、测试驱动开?br />五、重?br />六、持l集?br />七、频J地发布版?/p>
4.l对~程:
开发Q务会l化分解为很多TaskQ一个Task的开发周期一般不过2天?br />每个Task的Owner会寻找一个Partnerq行l对开发?br />Task开发的ơ序q序员们自己协商。他可以先作为Partner和其他Owner一起开发某个TaskQ然后再扑֏一个程序员作ؓPartner来共同开发自己承担的Task?br />l对开发时QTask的Owner主要负责~码Q?Partner负责在一旁看Owner~程q在其编写有错误提出自己的意见,当其遇到困难时一赯论、互相帮助完成Q?/p>
5.试驱动开?
在动手编码之前,必须先写功能试脚本、单元测试脚本?br />写好试脚本后,开始编码、重构、运行单元测试、集成、运行功能测试,以此循环
6.重构:
减少重复设计Q优化设计结构,提高技术上的重用性和可扩展性?br />XP提倡毫不留情的重构?br />M人可以重构Q何代码,前提是重构后的代码一定要通过100%试单元试后才能被Check-in
7.持箋集成:
试先行是持l集成的一个重要前提?br />持箋集成指不断地把完成的功能模块整合在一赗目的在于不断获得客户反馈以及尽早发现BUG?br />随时整合Q越频繁好Q集成及试q程的自动化E度高好?br />每次只有一个新增加部分在整合,而且必须q行功能试
8.频繁地发布小版本:
发布q程应该可能地自动化、规范化?br />不断地发布可用的pȝ可以告诉客户你在做正的事情?br />客户使用发布的系l,可以保证频繁地反馈和交流?br />保证客户有够的依据调控开发过E?增加、删除或改变需??br />降低开发风险?br />随着开发的推进Q发布越来越频繁?br />所有的发布都要l过功能试?/p>
9.XP的关键词:
试优先原则
l对~程
持箋集成
频繁版?br />不断重构
立式晨会
交流和沟通,“只有没有沟通不够的目Q没有沟通过度的目”
分解d、制定计划是关键一?/p>
10.XP作用:
一、^E的工作效率
q稳的工作效率指团队和个人在很长的时期内保持一定的开发效率?br />保证了项目速度和计划过E的有效性和准确性;
保证了程序员可以持箋地完成Q务,团队可以持箋地向客户交付可运行的pȝQ?br />l对~程已经加大了工作强度,q且和其它XP的规则一h高了工作效率Qɞ加班和l持q稳的工作效率可能而且可行?br />提倡^E的工作效率Q体CXP以h为本的hD?br />二、高质量
试优先、ƈ坚持单元试、每个版本进行功能测试的原则是保证了高质量的一个关键;
充分的沟通交进一步减了写低质量代码的风险;
l对开发模式在互相学习中会产出高质量的代码
三、Open
l对开发、每一处修攚w需要测试等{规则得实现集体拥有代码, “我们”的代码,而不?#8220;?#8221;的代码;
充分的沟通交可以将每个人的知识、思想׃nQ?br />让每个h都知道项目的设计、计划、进展情늭信息Q?br />大家都知道每个h都在做什么和怎么做;
四、对人的挑战
暴露自己的缺点,人的本?br />懒惰
自尊
闭
……
克服自己的缺?br />高效?br />不怕告诉别׃会,乐于问h
懂得重别hQ乐于帮助别?br />……
11.受益于XP:
一个曾l在XP模式下工作过的hQ回Cl开发模式下才深M会到XPl他带来的胦富?br />在传l开发模式下他坚持每天有计划、ȝQ坚持测试驱动开?#8230;…
发现他L按时下班甚至提前下班Q可是同事们来多且越来越晚下班,是自׃认真Q是同事们爱表现Q?#8230;…
都不是!Q?br />是XPl他带来的受益终w的开发方式,他的同事bug量远q比他多Q他只有不多的几?同事们Q务L延时Q而自己都是轻松按时完?#8230;…
首先是RUPQRUP有什么特点呢QP代性开发,用例驱动Q用UML对Y件徏模,提倡事先设计好以组件ؓ核心的体pȝ?以体pȝ构ؓ中心)Q不断的评估和测试Y件质量,Q用用例)控制软g的变化。在q些原则的基上,把Y件h员分成各U角?分析Q开发,理Q测试,工具支持Q配|?{等Q在软g开发过E中的各U品叫做工?Artifact)?/p>
再看TSPQTSP把h员分成小l领D、开发经理、计划经理、质量/生l理Q以及技术支持经?注意q点和RUP的雷同),要求各个人员严格记录在Y件开发过E中的每一步,比如E序的Bug率,使用的时间等{?/p>
最后一个是XPQXP的特点,双h~程Q简单用?User Story)QRefactoringQ以周ؓ基础的P代。持l集成,现场客户Q测试驱动,自动化测试,代码同步。同LQXP也把人员分成试Q交h员,设计师,技术作者,客户Q程序员{等?/p>
OKQ说了这么多长篇大论Q是Z把几个Y件过E拿出来比较。所有的软gq程无非是ؓ了避免风险,保证目的成功?/p>
拿交通工具做比方的话QTSP好比坐火RQ由于TSP是CMM那帮子h搞的Q所以TSP不强调P代性开发。TSP的是质量理和控Ӟ通过每个觉自愿的记录每天的行为,从而的得到严格的项目的数据Q缺乏了q种严格控制QTSP好比火车没有轨道,一点用处也没有。而在我们实验室一帮懒懒散散的学生中搞数据Q要他们每天填表Q从而知道项目消耗了多少人时QBug率ؓ多少Q不要做梦了吧,所以TSP那套方式肯定是行不通的?/p>
再看XP和RUP的差别,q代性开发,两者都Q不q两者的含义不同Q在RUP中,每次q代Q强调生的是一个个工gQ比如完成了用例。而在XP中,产生的是可用的Y件。ؓ什么RUP的P代里面可能没有生可用的软g呢?因ؓRUP的是用例驱动和体pȝ构ؓ中心Q所以RUP花在设计体系l构和用例上的时间会比较多,q样带来的好处是软g的后期变更会比较。而XP本n的是拥抱变化Q不三七二十一Q先开发出来一个能用的再说Q如果客户不满意Q别忘了QXP是现场客PQRefactoring之。所以在XP的开头的时候,Ҏ׃提倡太复杂的用例(客户在现场嘛Q不懂客L意思,现场交流啊)Q也不提倡过多的设计Q测试驱动嘛Q通不q的话Refactoring之)?/p>
然而RUP没有现场客户的概念,所以清晰的用例描述是RUP中很重要的一环。只有这些用例在客户和团队之间达成了pQ才能做下一步的工作Q同LQ需求的变更也必通过用例来体玎ͼRUP很强调变更管理,是q个意思?/p>
而在我们实验室做现在q个目Q不是和客户交流的问题,而是没有客户Q!Q?/p>
所以,在这U程度下Q我们的用例Q不是要让客L解,而是我们自己理解p够了。而体pȝ构,׃你们现在不用考虑分布式,q发Q事务等{一pd东西。这些东襉K由J2EE做了?br />
此外RUP在我们实验室很难办的一件事情是对各个阶D生的工g的质量监控,同学们互相哈哈哈Q很隑֯一个文性的东西q行评h?br />
那么要改善我们现在做的项目,最重要的是做什么呢Q第一是,P代,我们现在整个软g开发周期太长了Q应该羃短到2Q?周以内。第二,试Q我们现在的试很多都是手动的,需要自动化q个试q程。第三是Q快速构建,持箋集成。整个Y件的部v周期不能像现在这么长Q不能由同学们手工构建,而必L自动化的部v。这些都是在XP中强调的?br />
RUP的不同就好比是做BUS和自己开汽车的不同Q尽细微,但是Q开汽车更需要小心翼的调整方向Q而公交R毕竟有线路?br />
如果在一个大公司做部门经理的话,我更愿意采用RUP那套方式Q辅之于XP的各U实践,然而在实验室,我只有退而求其次Q因地制宜,XP能推q多是多少Q一些很难推q的东西比如风险理QBUG理只能暂时攑ּ了?/p>