讨论:极限编程

改名为极限编程

Google: 极限编程 vs 极端编程: 13900:6370

我的结果好象相反：

约有24,300项符合极端编程的查询结果， 约有116,000项符合极限编程的查询结果，

另外如果现在翻译的话，我倾向于极致编程 --用心阁 10:55 2004年12月24日 (UTC)

问题:XP有甚么“极限”呢？另外，极道程式设计亦有人使用。

我的理解是：XP可以把软件的灵动性（可适应性）提高到极限，可以把开发团队的效率提高到极限，可以把系统的质量提高到极限。当然这个极限是相对于传统软件方法而言的，是相对于过去的极限，而不是相对于未来的极限。--Windfast 16:38 2006年11月13日 (UTC)

重复的文字

这些内容属性来源于那些被认为是有效的原则，并把它们发挥到极限：

• 开发人员和客户之间的交互是有益的. 因此，一个极限编程的小组从理论上要求需要一个软体使用者在身边,这个使用者制定软体的工作需求和优先等级, 并且尽可能在各种问题出现的时候马上就能回答.
• 如果学习是好的, 那么就把它做到底: 这样减少了开发和回馈周期的长度,测试也能更早完成.
• 简单的程式码更可能工作。所以极限编程的程式设计师在一个软体专案中唯写出能够满足目前实际需求的程式码,这样或多或少降低了程式码的复杂性和重复性.
• 如果简单的程式码是好的, 那么把变得复杂的程式码改写成简单的.
• 程式码评审是好的。因此,极限编程的程式设计师以两人搭档的方式工作. 他们共享一个萤幕和键盘,增加了队员之间的交流,也让程式码在一被写出的时候就被人评审了.
• 测试程式码是好的。因此,在极限编程中,测试用例在实际程式码之前就被写出来了. 程式码只有在通过测试的时候才被认为完成了. (当然,需要进一步分解来降低复杂性). 整个软体系统用一种周期化的,实时的,被预先变好的自动化测试方式来保证它的确有作用.参看 测试驱动的开发.

一般来说，极限编程被认为对于少于12人的小团队很有用。一些人认为极限编程可以用于大的团队，但是其它人认为统一软体程序更适合大的团队。然而,极限编程在一些超过100人的开发小组中获得成功. 并不是极限编程不能够推广到更大的团队,而是很少有更大的团队来试著用它. 极限编程的人员也拒绝去随便推测这个问题.

以上的文字出现在极限编程#XP 核心的实践下半段和极限编程#极限编程的特征下半段，仅仅是前者用简体中文、后者用繁体中文，以及最后一段不知是否属于符号列表的一部份还是另一段落。请清理一下。 —Quest for Truth (留言) 2009年1月30日 (五) 15:04 (UTC)