极限编程的12个实践原则
1.计划的制定
制定计划的目的是确定本次迭代的范围。
本步骤的重心应该放在决定什么是对客户来说最重要的任务和如何首先完成这些任务。 计划的制定包括客户选择的项目大小、程序功能的优先级、各个版本的合成和发布日期。
2.小版本
小版本这一实践背后的观点是:用最少的代码工作量带来最大的业务价值。 程序的特性必须有原子性(不可分解)。 一个特性必须实现足够的功能来实现它的业务价值。 这个步骤可能是违反直觉的,但这样做是为了使项目尽快转化为产品。
发布小版本可以从客户那儿得到反馈和通过让客户确认,这就是他们需要的软件来降低项目的风险。 基本上,这个步骤使用Paredo规则:20%的努力能带来80%的业务价值。 小版本在计划的制定下,一版接一版地发布来决定何种特性将带来巨大的影响, 同时这也配合保持简单设计这一实践的实施。
3.简单设计
简单的设计能保证代码的简单。
- 最简单的设计并不通过预测未来的需求来尝试未来的问题。
- 最简单的设计将软件的一个可测试版本交付给用户。
- 最简单的设计通过所有测试,没有重复和费解的逻辑代码,但能够表达每一个程序员的意图。
这个步骤伴随着小版本的发布。 如果你的系统架构不能够很好的表达和满足预期的需要,你将不能够尽快的交付。
我们是程序员,不是占卜者。 我们没有水晶球,所以预测客户未来的需求最好的方法是给他们一个可以工作的系统, 并且从他们那儿得到反馈。 大多数客户不知道如何准确表达他们的需要,你交付一些他们能够切实可用的东西有助于缓解这种问题。 记住,一幅图片胜过千言万语,一个工作模型抵得上一千幅图片。
4.测试
测试是极限编程的核心。
测试应该是自动的,这样你会有信心和勇气来改变和重构代码,同时不破坏系统。 这与瀑布开发模型正好相反。
5.持续集成
持续集成是一个至关重要的概念。
为什么我们要等到项目的最后才检查系统的每一部分是否都能正常工作? 每几个小时(至少一天一次)系统必须构建和测试一遍。...