极限编程
维库，知识与思想的自由文库
XP为管理人员和开发人员开出了一剂指导日常实践的良方；这个实践意味着接受并鼓励某些特别的有价值的方法。支持者相信，这些在传统的软件工程中看来是“极端的”实践，将会使开发过程比传统方法更加好的响应用户需求，因此更加敏捷，更好的构建出高质量软件。
[编辑] 历史极限编程的创始者是肯特·贝克（Kent Beck）、沃德·坎宁安（ Ward Cunningham）和罗恩·杰弗里斯（Ron Jeffries），他们在为克莱斯勒综合报酬系统（Chrysler Comprehensive Compensation System )(C3) 的薪水册项目工作时提出了极限编程方法。Kent Beck在1996年3月成为C3的项目负责人，开始对项目的开发方法学进行改善。他写了一本关于这个改善后的方法学的书，并且于1999年10月将之发行，这就是《极限编程解析》（2005第二版出版）。克莱斯勒在2000年2月取消了实质上并未成功的C3项目，但是这个方法学却一直流行在软件工程领域中。至今2006年，很多软件开发项目都一直以极限编程做为他们的指导方法学。 該書闡述了如下的極致編程的哲學思想 ：
把極致編程一般化並用於其它型別的專案稱為極致專案管理。 [编辑] 背景The 90s had seen the great promise of object technologies launch ambitious projects that in many cases ended in failure. Objects themselves, while conferring numerous advantages of reuse, were not the panacea that many had hoped they would be. Fluid, rapidly-changing requirements demanded shorter lifecycles, and did not go well with more traditional methods of development, which usually required extensive design up front and penalized later design changes with higher costs or missed deadlines. [编辑] 起源The Chrysler Comprehensive Compensation project was started in order to determine the best way to use object technologies, using the payroll systems at Chrysler as the object of research, with Smalltalk as the language and GemStone as the persistence layer. They brought in Kent Beck, a prominent Smalltalk practitioner, to do performance tuning on the system, but his role expanded as he noted several issues they were having with their development process. He took this opportunity to propose and implement some changes in their practices based on his work with his frequent collaborator, Ward Cunningham.
Beck invited Ron Jeffries to the project to help develop and refine these methods. Jeffries thereafter acted as a kind of coach to instill the practices as habits in the C3 team. Information about the principles and practices behind XP was disseminated to the wider world through discussions on the original WikiWiki, Cunningham's Portland Pattern Repository. Various contributors dissected and expanded upon the ideas, some becoming fervent advocates, others becoming critics, and yet others picking out ideas (see agile software development). [编辑] 現狀Beck edited a series of books on XP, beginning with his own Extreme Programming Explained, spreading his ideas to a much larger yet very receptive audience. Authors in the series went through various aspects attending XP and its practices, even a book critical of the practices. XP created quite a buzz in the late nineties and early two thousands, seeing adoption in a number of different milieus and environments radically different from its origins. [编辑] 未來的方向The high discipline required by the original practices often went by the wayside, causing certain practices to be deprecated or left undone on individual sites. Agile development practices have not stood still, and XP is still evolving, assimilating more lessons from experiences in the field. In the second edition of Extreme Programming Explained, Beck added more values and practices, and differentiated between primary and corollary practices. [编辑] XP的目標極限編程的主要目標在於降低因需求變更而帶來的成本。在傳統系統開發方法中（如SDM），系統需求是在專案開發的開始階段就確定下來，並在之後的開發過程中保持不變的。這意味著專案開發進入到之後的階段時出現的需求變更—而這樣的需求變更在一些發展極快的領域中是不可避免的—將導致開發成本急速增加。這一概念可以用下圖來表示：
極限編程透過引入基本價值、原則、方法等概念來達到降低變更成本的目的。一個應用了極限編程方法的系統開發專案在應對需求變更時將顯得更為靈活。下圖展示了這一降低變更成本的目的︰
[编辑] XP 核心的實踐極致編程實踐作業的核心，正如 Extreme programming explained 所描述的，可以被區分為以下四個範圍（12個實踐作業）: 小規模回饋
反覆性程序而不是批量的
共同認識（共識）
程式設計師的利益
在第二版的Extreme programming explained中，在主要實踐之外，還列出了一系列延伸的實踐。 核心實踐源自被廣泛接受的最佳實踐，並且被推向極至：
[编辑] XP的價值最初，极限编程技术只提出了四条价值标准，而在《极限编程解析》的第二版中又加入了第五条。以下就是这五条标准：
[编辑] 溝通构建一个软件系统的基本任务之一就是与系统的开发者交流以明确系统的具体需求。在一些正式的软件开发方法中，这一任务是通过文档来完成的。 极限编程技术可以被看成是在开发小组的成员之间迅速构建与传播制度上的认识的一种方法（Extreme Programming techniques can be viewed as methods for rapidly building and disseminating institutional knowledge among members of a development team）。它的目标是向所有开发人员提供一个对于系统的共享的视角，而这一视角又是与系统的最终用户的视角相吻合的。为了达到这一目标，极限编程支持设计、抽象、还有用户-程序员间交流的简单化，鼓励经常性的口头交流与反馈。 [编辑] 簡單极限编程鼓励从最简单的解决方式入手再通过不断重构达到更好的结果。这种方法与传统系统开发方式的不同之处在于，它只关注于对当前的需求来进行设计、编码，而不去理会明天、下周或者下个月会出现的需求。极限编程的拥护者承认这样的考虑是有缺陷的，即有时候在修改现有的系统以满足未来的需求时不得不付出更多的努力。然而他们主张“不对将来可能的需求上投入精力”所得到的好处可以弥补这一点，因为将来的需求在他们还没提出之前是很可能发生变化的。为了将来不确定的需求进行设计以及编码意味着在一些可能并不需要的方面浪费资源。而与之前提到的“交流”这一价值相关联来看，设计与代码上的简化可以提高交流的质量。一个由简单的编码实现的简单的设计可以更加容易得被小组中的每个程序员所理解。 [编辑] 反馈在极限编程中，“反馈”是和系统开发的很多不同方面相关联的：
反馈是与“交流”、“简单”这两条价值紧密联系的。为了沟通系统中的缺陷，可以通过编写单元测试，简单的证明某一段代码存在问题。来自系统的直接反馈信息将提醒程序员注意这一部分。用户可以以定义好的功能需求为依据，对系统进行周期性的测试。用Kent Beck的话来说：“编程中的乐观主义是危险的，而及时反馈则是解决它的方法。” [编辑] 勇氣极限编程理论中的“系统开发中的勇气”最好用一组实践来诠释。其中之一就是“只为今天的需求设计以及编码，不要考虑明天”这条戒律。这是努力避免陷入设计的泥潭、而在其他问题上花费了太多不必要的精力。勇气使得开发人员在需要重构他们的代码时能感到舒适。这意味着重新审查现有系统并完善它会使得以后出现的变化需求更容易被实现。另一个勇气的例子是了解什么时候应该完全丢弃现有的代码。每个程序员都有这样的经历：他们花了一整天的时间纠缠于自己设计和代码中的一个复杂的难题却无所得，而第二天回来以一个全新而清醒的角度来考虑，在半小时内就轻松解决了问题。 [编辑] 尊重尊重的价值体现在很多方面。在极限编程中，团队成员间的互相尊重体现在每个人保证提交的任何改变不会导致编译无法通过、或者导致现有的测试case失败、或者以其他方式导致工作延期。团队成员对于他们工作的尊重体现在他们总是坚持追求高质量，坚持通过重构的手段来为手头的工作找到最好的解决设计方案。 [编辑] 原则组成极限编程基础的原则，正是基于上面描述的那几条价值。在系统开发项目中，这些原则被用来为决策做出指导。与价值相比，原则被描述的更加具体化，以便在实际应用中更为简单的转变为具体的指导意见。 [编辑] 快速反饋当反馈能做到及时、迅速，将发挥极大的作用。一个事件和对这一事件做出反馈之间的时间，一般被用来掌握新情况以及做出修改。与传统开发方法不同，与客户的发生接触是不断反复出现的。客户能够清楚地洞察开发中系统的状况。他/她能够在整个开发过程中及时给出反馈意见，并且在需要的时候能够掌控系统的开发方向。 单元测试同样对贯彻反馈原则起到作用。在编写代码的过程中，应需求变更而做出修改的系统将出现怎样的反应，正是通过单元测试来给出直接反馈的。比如，某个程序员对系统中的一部分代码进行了修改，而假如这样的修改影响到了系统中的另一部分（超出了这个程序员的可控范围），则这个程序员不会去关注这个缺陷。往往这样的问题会在系统进入生产环节时暴露出来。 [编辑] 假設簡單假設簡單認為任何問題都可以"極度簡單"的解決。傳統的系統開發方法要考慮未來的變化，要考慮程式碼的可重用性。極致編程拒絕這樣作。 [编辑] 增量變化极限编程的提倡者总是说：罗马不是一天建成的。一次就想进行一个大的改造是不可能的。极限编程采用增量变化的原则。比如说，可能每三个星期发布一个包含小变化的新版本。这样一小步一小步前进的方式，使得整个开发进度以及正在开发的系统对于用户来说变得更为可控。 [编辑] 包容變化可以肯定地是，不确定因素总是存在的。“包容变化”这一原则就是强调不要对变化采取反抗的态度，而应该包容它们。比如，在一次阶段性会议中客户提出了一些看来戏剧性的需求变更。作为程序员，必须包容这些变化，并且拟定计划使得下一个阶段的产品能够满足新的需求。 [编辑] 活動XP 描述了在软件开发过程中四种基本的行为。 XP describes four basic activities that are performed within the software development process. [编辑] 編碼XP的提倡者争辩说在系统开发过程的产物中真正重要的只有编码（a concept to which they give a somewhat broader definition than might be given by others）。没有编码你一无所有。 The advocates of XP argue that the only truly important product of the system development process is code (a concept to which they give a somewhat broader definition than might be given by others). Without coding you have nothing. Coding can be drawing diagrams that will generate code, scripting a web-based system or programming an object-oriented C# program that needs to be compiled. Coding can also be used to figure out the most suitable solution. For instance, XP would advocate that faced with several alternatives for a programming problem, one should simply code all solutions and determine with automated tests (discussed in the next section) what solution is most suitable. Coding can also help to communicate thoughts about programming problems. A programmer dealing with a complex programming problem and finding it hard to explain the solution to fellow programmers might code it and use the code to demonstrate what he or she means. Code, say the exponents of this position, is always clear and concise and cannot be interpreted in more than one way. Other programmers can give feedback on this code by also coding their thoughts. [编辑] 软件測試沒有經過測試的程式碼什麼都不是。如果你沒有測試，客戶可能感覺不到，很多軟體在發佈的時候沒有經過完整的測試，它們還都在工作（或多或少的工作）。 在軟體開發程序中，極致編程認為，如果一個函數沒有經過測試就不能認為它可以工作。 This raises the question of defining what one can be uncertain about.
[编辑] 傾聽Programmers don't necessarily know anything about the business side of the system development. The function of the system is determined by the business side. For the programmers to find what the functionality of the system should be, they have to listen to business. Programmers have to listen "in the large": they have to listen what the customer needs. Also, they have to try to understand the business problem, and to give the customer feedback about his or her problem, to improve the customer's own understanding of his or her problem. Communication between the customer and programmer is further addressed in The Planning Game (see below). [编辑] 設計From the point of view of simplicity, one could say that system development doesn't need more than coding, testing and listening. If those activities are performed well, the result should always be a system that works. In practice, that will not work. One can come a far way without designing but at a given time one will get stuck. The system becomes too complex and the dependencies within the system cease to be clear. One can avoid this by creating a design structure that organizes the logic in the system. Good design will avoid lots of dependencies within a system; this means that changing one part of the system will not affect other parts of the system. [编辑] 實踐[编辑] 策劃遊戲在極致編程中主要的策劃程序稱為策劃遊戲。 本節將通過程序模型介紹這個程序。 策劃程序分為兩部分：
[编辑] Exploration phase – Release planningThis is an iterative process of gathering requirements and estimating the work impact of each of those requirements.
When business cannot come up with any more requirements, one proceeds to the commitment phase.
[编辑] 送出狀態 – 發佈計劃這一階段涉及成本、利潤和計劃影響這三個因素，包含四個部分：
[编辑] 價值排序業務方按照商業價值為使用者故事排序。它們會被分為三類：
[编辑] 風險排序程式設計師按照風險對使用者故事進行排序。他/她們將使用者故事的風險劃分成三類：低、中、高。以下是這種方式的一個範例：
為每個使用者故事增加所有這些索引後，給這些使用者故事指定一個風險索引：低（0–1），中（2–4），高（5–6）。 [编辑] 激勵狀態 – 發佈計劃在作業階段開發人員和業務人員可以「操縱」整個程序。這意味著，他們可以做出改變。個體的使用者故事，或是不同使用者故事的相對優先等級，都有可能改變；預估時間也可能出現誤差。這是做出相應調整的機會。 [编辑] 探索階段- 反覆計劃反覆計劃中的探索階段是關於建立任務和預估實施時間。
[编辑] 約定階段 - 反覆計劃在反覆計劃的約定階段以不同使用者故事作為參考的任務被指派到程式設計師。
[编辑] 作業階段 - 反覆計劃各個任務是在反覆計劃的作業階段中一步步實作的。
[编辑] 結對程式設計結對程式設計的意思是所有的程式碼都是由兩個人坐在一台電腦前一起完成的。一個程式設計師控制電腦並且主要考慮編碼細節。另外一個人主要關注整體結構，不斷的對第一個程式設計師寫的程式碼進行評審。 結對不是固定的: 我們甚至建議程式設計師盡量交叉結對。這樣，每個人都可以知道其它人的工作，每個人都對整個系統熟悉，結對程式設計加強了團隊內的溝通。 (這與程式碼集體所有制是息息相關的). [编辑] 集體所有制集體所有制意味著每個人都對所有的程式碼負責；這一點，反過來又意味著每個人都可以更改程式碼的任意部分。結隊程式設計對這一實踐貢獻良多：借由在不同的結隊中工作，所有的程式設計師都能看到完全的程式碼。集體所有制的一個主要優勢是提升了開發程序的速度，因為一旦程式碼中出現錯誤，任何程式設計師都能修正它。 在給予每個開發人員修改程式碼的權限的情況下，可能存在程式設計師引入錯誤的風險，他/她們知道自己在做什麼，卻無法預見某些依賴關係。完善的單元測試可以解決這個問題：如果未被預見的依賴產生了錯誤，那麼當單元測試執行時，它必定會失敗。 [编辑] 現場客戶在極致編程中，「客戶」並不是為系統付帳的人，而是真正使用該系統的人。極致編程認為客戶應該時刻在現場解決問題。例如：在團隊開發一個財務管理系統時，開發小組內應包含一位財務管理人員。 [编辑] 單元測試單元測試是用以測試一小段程式碼的自動測試（例如：類，方法）。在極致編程中，在程式碼編輯前就編輯單元測試。這種方式的目的是激勵程式設計師設想他/她的程式碼在何種條件下會出錯。極致編程認為當程式設計師無法再想出更多能使他/她的程式碼出錯的情況時，這些程式碼便算完成。 [编辑] 重構由於XP教條提倡編輯程式時只滿足目前的需求，並且以盡可能簡單的方式實作。有時會碰上一套僵硬的系統，所謂僵硬的系統，表現之一是需要雙重（或多重）維護：功能變化需要對多份同樣（或類似）的程式碼進行修改；另一種表現是對程式碼的一部分進行修改時會影響其它很多部分。XP教條認為當這種情況發生時，意味著系統正告訴你通過改變系統架構以重構程式碼，使它更簡單、更泛用。參見重構。 [编辑] 具爭議性的問題Extreme Programming also has its share of controversial aspects:
In 2003, Matt Stephens and Doug Rosenberg published a book under Beck's XP series imprint called "Extreme Programming Refactored: The Case Against XP" which questioned the value of the XP process and suggested ways in which it could be improved (i.e. refactored). This triggered a lengthly debate in articles, internet newsgroups and web-site chat areas. The core argument of the book is that XP's practices are interdependent but that few practical organisations are willing/able to adopt all the practices; therefore the entire process fails. The book also makes other criticisms and it draws a likeness of XP's "collective ownership" model to socialism (the authors appear to regard this as undesirable). Certain aspects of XP have changed since the book was published, in particular XP now accomodates modifications to the practices as long as the required objectives are still met. It also uses increasingly generic terms for processes. Some argue that these changes invalidate previous criticisms; others claim that this is simply watering the process down. Recently, authors have attempted to reconcile XP with the older methods that XP sought to replace (such as the waterfall method) in order to offer a unified method. See http://www.lux-seattle.com/resources/whitepapers/waterfall.htm for an example. [编辑] 極致編程的特徵極致編程方法的基本特徵是：
這些內容屬性來源於那些被認為是有效的原則，並把它們發揮到極致：
一般來說，極致編程被認為對於少於12人的小團隊很有用。一些人認為極致編程可以用於大的團隊，但是其它人認為統一軟體程序更適合大的團隊。然而,極致編程在一些超過100人的開發小組中獲得成功. 並不是極致編程不能夠推廣到更大的團隊,而是很少有更大的團隊來試著用它. 極致編程的人員也拒絕去隨便推測這個問題. [编辑] 爭論的觀點極致編程也有其被爭論的一面： 絕大多數設計活動都匆匆而過，並漸進式的，開始一個「最簡單的可能工作的東西」並當其需要時（測試失敗）才增加複雜性。單元測試促成為了設計紀律。 [编辑] 極致編程中的溝通建構軟體系統的一個基本任務是向系統的開發人員傳達系統的需求。在形式的軟體開發方法學中，溝通是通過文件完成的。 極致編程方法可以被看作為在開發團隊成員間快速建構和散佈統一的知識的一種方法。目的在於給所有開發人員一個共享的關於系統的看法，這個看法與使用者持有的看法相一致。為了這個目的，極致編程熱衷於簡單的設計，隱喻，使用者與程式設計師之間的合作，頻繁的口頭溝通和回饋。 參見: [编辑] 參考資料
[编辑] 外部連線
|
