极限编程（XP）的12个实践原则
1.计划的制定
制定计划的⽬的是确定本次迭代的范围。
本步骤的重⼼应该放在决定什么是对客户来说最重要的任务和如何⾸先完成这些任务。 计划的制定包括客户选择的项⽬⼤⼩、程序功能的优先级、各个版本的合成和发布⽇期。
2.⼩版本
⼩版本这⼀实践背后的观点是：⽤最少的代码⼯作量带来最⼤的业务价值。 程序的特性必须有原⼦性（不可分解）。 ⼀个特性必须实现⾜够的功能来实现它的业务价值。 这个步骤可能是违反直觉的，但这样做是为了使项⽬尽快转化为产品。
发布⼩版本可以从客户那⼉得到反馈和通过让客户确认，这就是他们需要的软件来降低项⽬的风险。 基本上，这个步骤使⽤Paredo规则：20%的努⼒能带来80%的业务价值。 ⼩版本在计划的制定下，⼀版接⼀版地发布来决定何种特性将带来巨⼤的影响， 同时这也配合保持简单设计这⼀实践的实施。
3.简单设计
简单的设计能保证代码的简单。
最简单的设计并不通过预测未来的需求来尝试未来的问题。
最简单的设计将软件的⼀个可测试版本交付给⽤户。
最简单的设计通过所有测试，没有重复和费解的逻辑代码，但能够表达每⼀个程序员的意图。
这个步骤伴随着⼩版本的发布。 如果你的系统架构不能够很好的表达和满⾜预期的需要，你将不能够尽快的交付。
我们是程序员，不是占⼘者。 我们没有⽔晶球，所以预测客户未来的需求最好的⽅法是给他们⼀个可以⼯作的系统， 并且从他们那⼉得到反馈。 ⼤多数客户不知道如何准确表达他们的需要，你交付⼀些他们能够切实可⽤的东西有助于缓解这种问题。 记住，⼀幅图⽚胜过千⾔万语，⼀个⼯作模型抵得上⼀千幅图⽚。
4.测试
测试是极限编程的核⼼。
测试应该是⾃动的，这样你会有信⼼和勇⽓来改变和重构代码，同时不破坏系统。 这与瀑布开发模型正好相反。
5.持续集成怎样写代码 自己做编程
持续集成是⼀个⾄关重要的概念。
为什么我们要等到项⽬的最后才检查系统的每⼀部分是否都能正常⼯作？ 每⼏个⼩时（⾄少⼀天⼀次）系统必须构建和测试⼀遍。 通过经常这样做，你将能够知道何处的改变破坏了系统并作出调整， 从⽽避免浪费时间⼀直等到修改已堆积成⼭并且你⾃⼰都忘记了修改的细节。
6.重构
重构的使⽤确保程序员加⼊新的功能后代码仍保持简单， 从⽽保证简单的代码仍然能够运⾏所有的测试。
这个实践的思想是不复制代码，也不写“丑陋”、“发臭”的代码。 重构的重⼼在于测试能够验证代码仍然具备需要的功能。 测试和重构交替进⾏。 ⾃动单元级（unit-level）测试给你勇⽓来重构和保持代码的简单和表现⼒。
7.结对编程
结对编程⼤概是极限编程中最具⾰命性的实践—这通常是管理者最花时间来习惯的地⽅。
在表⾯上，他们的反应很容易理解：如果我们的项⽬进度落后了， 那么怎样在同⼀个任务中使⽤两个程序员来提⾼开发速度呢？ 为什么需要两个程序员使⽤⼀个键盘和⼀个显⽰器呢？
⾸先，它增加了团队成员之间的交流。 我们⼯作的很⼤⼀部分需要依靠其他程序员的⼯作。 这个程序员今天和你在⼀个团队，不⼀定明天还有必要和你在⼀个团队。 同样，如果⼀个⼈知道许多特定的技术（如：EJB或是Oralce）或者掌握专业领域的技能， 试问有其他更好的⽅法⽐和那个⼈结对能更好地向对⽅学习吗？ 什么是质量？ 结对编程能提供持续的信息反馈和确保正在编程的⼈进⾏重构、测试和遵守编码标准。
8.代码共享
代码共享这⼀极限编程中的实践表明任何⼀个⼈都能够对系统作出修改。
每个程序员都拥有系统的所有权和需要对系统负责。 如果没有⼈了解某⼀特定细节，那么单元测试负责检验API和检查你的改变有没有破坏系统。 因此，你没有必要等到团队中的另⼀个成员来修正这个错误。 如果不采⽤代码共享，并且在系统中有⼀些错误，那么每⼀个⼈必须停下来等待直到你将这个错误修复。
9.每周只⼯作40⼩时
充分利⽤时间。
这⼀规则的隐含意思是统计的时间是处于⾼效率⼯作的有效时间和必须从你的⼯作时间中得到最⼤的收益。 长时间的仁义应该避免。 任何妨碍在下⼀个发布版本中提供最⼤商业价值的⾏为都应该被避免。 劳累过度的程序员将犯下许多错误。
10.现场客户
如果有可能，客户应该与程序员直接接触。
客户必须阐明需求的功能。 客户也参与到计划的制定中，记录客户需求时，⽤程序员和客户都能理解的语⾔编写。
11.隐喻
记录客户需求时，⽤程序员和客户都能理解的语⾔编写。
12.编码标准
极限编程的实⾏者应该遵守编码标准这⼀实践。 你必须能够明⽩其他程序员写的代码。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。