討論:極限編程

改名為極限編程

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)