【续】RUP模型与XP模型

　　接续上一篇文章的标题，本文主要分享一下XP模型的相关知识。

XP模型

　　1.XP模型简介

　　　　Extreme Programming（极限编程，简称XP）是由KentBeck在1996年基于增量模型发展而提出的。是一种近螺旋式的开发方法，将复杂的开发过程分解为一个个相对比较简单的小周期，将系统细分为多个可以在较短周期解决的子模块，且强调测试、代码质量和及早的发现问题。通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。【来自https://baike.baidu.com/item/%E6%9E%81%E9%99%90%E7%BC%96%E7%A8%8B/4690591?fr=aladdin】

　　 2.核心实践

　　　　所谓极限，就是所有环节都做到极致，花最短的时间，用最简单的方法做最好的软件。查询大量资料后，XP让我感觉它让软件开发变得轻松愉快并富有有活力。从它“沟通、简单、反馈、勇气和谦逊”的核心价值就可以看出。并且XP是基于敏捷开发的核心价值和目标的，而敏捷开发是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发的。基于这样的思想，XP也对开发团队作了13个核心实践的要求（如图所示，图片来源百度百科），挑选其中几条来做分享。

 

　　　　首先是团队合作。每种软件开发过程模型都强调团队合作，但XP与众多模型不同的是，只要是对项目作出贡献的人，都是团队中的一员，其中包括用户。因为从项目的计划到最后验收，用户才是最清楚自己需求的人。并且不是每个成员的工作别人不能插手，而是互相交流协作的。

　　　　结对编程。在XP中，所有的代码都是由两个程序员在同一台机器上一起写的。或许这一点很难理解，虽然我们常说人多力量大。但是在开发软件项目这件事情上，我们从来都不希望和别人一起编写同一段代码。因为每个人的想法和编程习惯都不一样。但使用XP模型确强行要求执行这一点，而后来事实也证明，这样极大地提高了工作强度和工作效率。毕竟这样做保证了所有的代码、设计和单元测试都至少被另一个人检查复核过。并且在项目开发过程中，对人员流动较大的项目，这是一条很好的策略。

　　　　集体拥有代码。在许多模型中，项目开发之初都会对开发人员进行功能模块的分工，对应功能模块的开发人员只负责维护自己功能，并且他们也不喜欢别人随意修改自己的代码。这就导致开发团队人员互相之间都不了解彼此的功能，也不熟悉彼此的代码。这就使得代码维护具有很大的局限性（因为可能由于负责某一功能的程序员技术的局限性导致维护困难）。但XP中却是大家共同拥有代码，在前面也已经提到，每个成员都可以阅读别人的代码，并发现和纠正其中的错误。这样所有代码都是整个团队共同开发完成的，而不是只是一两个技术较牛的人写的。并且由整个团队所有人开发出来的系统，代码质量都非常好。当然，这样做的基础是每个成员都严格遵循项目开发的代码规范。

　　 3.过程

　　　· 计划项目（PlanningGame）

　　　　　主要预测交付日期前可以完成多少工作，现在和下一步的工作内容有哪些。针对这两个问题，XP中又提出了软件发布计划和周期开发计划两个过程。软件发布计划主要是分析用户需求，制定一个大致的计划。而周期开发计划则是前面提到的，XP把复杂的系统划分为多个

　　　· 验收测试

　　　　　与瀑布模型不同的时，XP模型的验收测试不是在所有软件功能都完成之后再进行测试，而是用户对每个周期完成时所发布的系统进行评估，这样软件开发对用户来说更具有实际意义，也体现了XP作为一种近螺旋式开发方式的特点。同时，验收测试和测试驱动的开发也保证了各个周期所发布的产品的一致性和可靠性。

　　　· 小规模发布

　　　　　即前面提到的，XP模型把复杂的软件开发过程分解为多个周期，将系统分解为多个简单的活动或者任务。因此每个周期开发的需求都是用户需要的东西，XP模型就要求频繁地发布软件，可能的话，应该每天都发布一个新的版本，在对系统某一部分做了修改或者完善之后，也应该立刻发布新版本。

 

　　总的来说，XP模型就是为满足用户需求而存在的。不仅让用户参与到开发中来，并且其小规模发布和验收测试也让用户切实感受软件的存在。个人比较喜欢XP模型的核心实践，让人感觉软件开发的过程不那么枯燥和痛苦，而是积极向上。