極限程式設計（Extreme Programming）—實踐

march-bird lucian yjf taopin wl jazz韓偉 nullgate Simon[AKA](轉載自cutter.com)　　　　2003年09月15日

　　Practices

　　實踐

　　One thing to keep in mind is that XP practices are intended for use with small, co-located teams. They therefore tend toward minimalism, at least as far as artifacts other than code and test cases are concerned. The presentation of XP's practices have both positive and negative aspects. At one level, they sound like rules -- do this, don't do that. Beck explains that the practices are more like guidelines than rules, guidelines that are pliable depending on the situation. However, some, like the "40-hour week," can come off as a little preachy. Jeffries makes the point that the practices also interact, counterbalance, and reinforce each other, such that picking and choosing which to use and which to discard can be tricky.

　　應記住的一件事情就是我們應傾向于在小型的, 局部的團隊中運用XP。除了代碼與測試用例外, 盡量減少有些的影響。XP的實踐既有正面的表現,也有負面的。在某些方面看來，他們聽起來就像一堆規則，要做這個，不要做那個。對此Beck解釋道, 與規則相比, XP更像是指導方針，一個靈活的依賴于具體環境的開發方針。但是諸?quot;每周工作40小時"等看起來可能會感覺續續道道。Jeffries使得實踐也會互相作用的，平衡，互相加強。以至于挑選使用的同丢棄的都是棘手的事情。

　　

　　The planning game. XP's planning approach mirrors that of most iterative RAD approaches to projects. Short, three-week cycles, frequent updates, splitting business and technical priorities, and assigning "stories" (a story defines a particular feature requirement and is displayed in a simple card format) all define XP's approach to planning.

　　計劃的制定：XP中關于制定計劃的實作方法中可以反映出大多數疊代式RAD項目的特點。短期的，每三周為一個循環，頻繁地更新，按優先級劃分任務與技術， 配置設定stories（一個story定義了一個特殊的功能需求并以一種簡單的方式記錄在卡片上），所有的這些就是構成了XP中的計劃。

　　Small releases. "Every release should be as small as possible, containing the most valuable business requirements," states Beck. This mirrors two of Tom Gilb's principles of evolutionary delivery from his book Principles of Software Engineering Management: "All large projects are capable of being divided into many useful partial result steps," and "Evolutionary steps should be delivered on the principle of the juiciest one next."

　　小版本："每個版本應該盡可能的小，而且包含最有商業價值的需求"，Beck如是說。這也反映了Tom Gilb在他的<軟體工程管理原則>書中提到的關于漸進式釋出的兩點："所有的大的項目都可以被分為局部的, 有用的小的步驟"以及"進化的步驟會傳遞到下一級。"

　　Small releases provide the sense of accomplishment that is often missing in long projects as well as more frequent (and more relevant) feedback. However, a development team needs to also consider the difference between "release" and "releasable." The cost of each release -- installation, training, conversions -- needs to be factored into whether or not the product produced at the end of a cycle is actually released to the end user or is simply declared to be in a releasable state.

　　小型版本的釋出意味着具有在大型項目中經常缺少的頻繁的回報的實作.。 然而，一個開發小組當然需要考慮到"釋出"同"可釋出"的不同。無論是否是最終的版本釋出還是一個簡單的可發行版本的釋出, 都需要付出安裝，教育訓練，轉化等代價。

　　Metaphor. XP's use of the terms "metaphor" and "story" take a little wearing in to become comfortable. However, both terms help make the technology more understandable in human terms, especially to clients. At one level, metaphor and architecture are synonyms -- they are both intended to provide a broad view of the project's goal. But architectures often get bogged down in symbols and connections. XP uses "metaphor" in an attempt to define an overall coherent theme to which both developers and business clients can relate. The metaphor describes the broad sweep of the project, while stories are used to describe individual features.

　　隐喻：在XP中"隐喻"以及"story"的使用可能會讓人有一點不舒服。但是，這些術語的使用可以幫助我們以一種更人性化的方式加以了解，尤其是對客戶而言。從某種程度上來說，隐喻同體系結構是同意語――他們都着重于從全局描述一個項目。但是體系結構經常會陷于符号與連接配接的泥潭。而XP使用"隐喻"定義一個從開發者到商業客戶都可聯系的全面一緻的主題。隐喻用于描述項目全面的面貌，而Story用于描述個别具體的特征。

　　Simple design. Simple design has two parts. One, design for the functionality that has been defined, not for potential future functionality. Two, create the best design that can deliver that functionality. In other words, don't guess about the future: create the best (simple) design you can today. "If you believe that the future is uncertain, and you believe that you can cheaply change your mind, then putting in functionality on speculation is crazy," writes Beck. "Put in what you need when you need it."

　　

　　簡單的設計：簡單的設計包含兩個部分。一，為已定義的功能進行設計，而不是為潛在地未來可能的功能進行設計。二，建立最佳的可以實作功能的設計。換句話說，不用管未來會是怎樣，隻建立一個目前為止可以實作的最好的設計。"如果你相信未來是不确定的，并且你相信你可以很友善的改變你的主意的話，那麼對未來功能的考慮是危險的。"Beck寫到。"隻有在你真正需要的時候才去做"

　　In the early 1980s, I published an article in Datamation magazine titled "Synchronizing Data with Reality." The gist of the article was that data quality is a function of use, not capture and storage. Furthermore, I said that data that was not systematically used would rapidly go bad. Data quality is a function of systematic usage, not anticipatory design. Trying to anticipate what data we will need in the future only leads us to design for data that we will probably never use; even the data we did guess correctly on won't be correct anyway. XP's simple design approach mirrors the same concepts. As described later in this article, this doesn't mean that no anticipatory design ever happens; it does mean that the economics of anticipatory design changes dramatically.

　　在二十世紀八十年代，我發表了一篇有關自動化資料管理的文章"實際的同步資料"文章的意思是說資料的品質是使用功能，不是捕捉與存儲。此外，我說資料如果不是很系統的使用便會變壞。資料品質是系統使用的功能，不是可預料的設計。無論預期的對還是錯，試着設計一個我們從來都不會用到的資料，最終結果很可能我們一次也不會用到它們。XP的簡單設計方法反映了相同的觀點。如在本文後來所描述的那樣，這并不意味着不需要預測，而是說為預測的内容所做的設計一旦發生變化，其導緻的代價是十分巨大的。

　　Refactoring. If I had to pick one thing that sets XP apart from other approaches, it would be refactoring -- the ongoing redesign of software to improve its responsiveness to change. RAD approaches have often been associated with little or no design; XP should be thought of as continuous design. In times of rapid, constant change, much more attention needs to be focused on refactoring. See the sections "Refactoring" and "Data Refactoring," below.

　　重構：如果我不得不找出一個能夠将XP和其他方法差別開來的東西那就是重構――不斷的軟體再設計以改進它對于變化的反應。RAD方法常常很少甚至根本不與設計相關；XP應當被看作持續設計。當變化既快而且頻繁的時候，應投入更多的精力于重構之上。參見下面的"重構"和"資料重構"部分。

　　Testing. XP is full of interesting twists that encourage one to think -- for example, how about "Test　and then code"? I've worked with software companies and a few IT organizations in which programmer performance was measured on lines of code delivered and testing was measured on defects found -- neither side was motivated to reduce the number of defects prior to testing. XP uses two types of testing: unit and functional. However, the practice for unit testing involves developing the test for the feature prior to writing the code and further states that the tests should be automated. Once the code is written, it is immediately subjected to the test suite instant feedback.

　　測試：XP充滿發人深思的有趣的難題。例如：什麼是"先測試後編碼"？我曾經同軟體公司和一些IT機構一起工作，在那兒是通過代碼的行數來對程式員的績效加以考核，而測試的績效則是通過發現的缺陷的數量來考核的。這兩種方法都不能鼓勵減少測試前産生的缺陷的數量。XP使用兩種測試：單元測試和功能測試。單元測試要求在寫代碼之前就開發出相應功能的測試方法，并并測試應當是自動化的。代碼一完成，它就被立即用有關測試集加以測試，進而能立即得到回報。

　　The most active discussion group on XP remains the Wiki exchange (XP is a piece of the overall discussion about patterns). One of the discussions centers around a lifecycle of Listen (requirements) Test Code Design. Listen closely to customers while gathering their requirements. Develop test cases. Code the objects (using pair programming). Design (or refactor) as more objects are added to the system. This seemingly convoluted lifecycle begins to make sense only in an environment in which change dominates.

　　最活躍的XP讨論組仍然是Wiki exchange（XP是關于pattern總體讨論的一部分），其中的一個讨論圍繞聽取（需求）-> 測試 -> 代碼 -> 設計的生命周期。貼近客戶聆聽并收集他們的需求。開發測試用例（test cases）。完成對象編碼（使用配對程式設計）。當更多對象被加入系統時進行設計（或重構）。這個看起來混亂不堪的生命周期僅僅在經常變化的環境下才有意義。

　　Pair programming. One of the few software engineering practices that enjoys near-universal acceptance (at least in theory) and has been well measured is software inspections (also referred to as reviews or walkthroughs). At their best, inspections are collaborative interactions that speed learning as much as they uncover defects. One of the lesser-known statistics about inspections is that although they are very cost effective in uncovering defects, they are even more effective at preventing defects in the first place through the team's ongoing learning and incorporation of better programming practices.

　　配對程式設計：軟體（還是直接用Inspection為好？）（也稱審查或走查）也是被廣為接受（至少在理論上）和有效度量的少數軟體工程實踐之一。在最好情況下，Inspection這種協同互動的檢查能夠加速學習，同時發現缺陷。一個較少被知道的關于Inspection的統計資料是盡管它在發現缺陷方面非常有效，但通過團隊對于好的開發實踐持續的學習和協作，可以更好的在第一時間預防缺陷。

　　One software company client I worked with cited an internal study that showed that the amount of time to isolate defects was 15 hours per defect with testing, 2-3 hours per defect using inspections, and 15 minutes per defect by finding the defect before it got to the inspection. The latter figure arises from the ongoing team learning engendered by regular inspections. Pair programming takes this to the next step -- rather than the incremental learning using inspections, why not continuous learning using pair programming?

　　一家我工作過的軟體公司客戶引用一個内部研究結果，表明在測試階段發現一個缺陷需15小時，在Inspection階段發現一個缺陷則需2－3小時，而在Inspection之前發現缺陷隻需15分鐘。後面的資料來自于産生于正常審查的持續的團隊學習。配對程式設計将這個帶入下一步――與其用Inspection來遞增式學習，為什麼不用配對程式設計來學習呢？

　　"Pair programming is a dialog between two people trying to simultaneously program and understand how to program better," writes Beck. Having two people sitting in front of the same terminal (one entering code or test cases, one reviewing and thinking) creates a continuous, dynamic interchange. Research conducted by Laurie Williams for her doctoral dissertation at the University of Utah confirm that pair programming's benefits aren't just wishful thinking (see Resources and References).

　　"配對程式設計是兩個人試圖同時程式設計和了解如何更好程式設計的一種對?quot;，Beck寫道。讓兩個人同時坐在一台終端前面（一個人敲代碼或測試用例，一個人審查和思考）産生一種持續的、動态的交流。Williams在猶他大學進行的博士論文研究證明了配對程式設計不僅僅是一種美好的想法而且确有實效。（參見資源和參考）

　　Collective ownership. XP defines collective ownership as the practice that anyone on the project team can change any of the code at any time. For many programmers, and certainly for many managers, the prospect of communal code raises concerns, ranging from "I don't want those bozos changing my code" to "Who do I blame when problems arise?" Collective ownership provides another level to the collaboration begun by pair programming.

　　代碼共享：項目組中的每個人都可以在任何時候修改其他項目成員的代碼，這就是XP中所定義的代碼共享。。對許多程式員以及經理而言，，共有代碼的想法會引起一些疑慮，諸如"我不想讓那些笨蛋改我的代碼"，"出現問題我應該怪誰？"等等。共享代碼從另一個層面提供了對配對程式設計中協作的支援。

　　Pair programming encourages two people to work closely together: each drives the other a little harder to excel. Collective ownership encourages the entire team to work more closely together: each individual and each pair strives a little harder to produce high-quality designs, code, and test cases. Granted, all this forced "togetherness" may not work for every project team.

　　配對程式設計鼓勵兩個人緊密協作：每個人促使另一個更加努力以圖超越。共同所有鼓勵整個團隊更加緊密協作：每個個人和每個雙人更努力生産高品質設計、代碼和測試集。當然，所有這些強迫的"共同"不一定對所有的項目組适用。

　　Continuous integration. Daily builds have become the norm in many software companies -- mimicking the published material on the "Microsoft" process (see, for example, Michael A. Cusumano and Richard Selby's Microsoft Secrets). Whereas many companies set daily builds as a minimum, XP practitioners set the daily integration as the maximum - opting for frequent builds every couple of hours. XP's feedback cycles are quick: develop the test case, code, integrate (build), and test.

　　

　　經常內建：每日構造（build）在許多公司已經成為規範，模仿有關"微軟"流程的出版物上的東西。（參見，例如，Michael A. Cusumano和Richard Selby的Microsoft Secrets）許多公司将每日編鍊作為最小要求，XP實踐者将每日內建作為最大要求，選擇每兩個小時一次的頻繁編鍊。XP的回報周期迅速：開發測試集、編碼、內建（編鍊）和測試。

　　The perils of integration defects have been understood for many years, but we haven't always had the tools and practices to put that knowledge to good use. XP not only reminds us of the potential for serious integration errors, but provides a revised perspective on practices and tools.

　　對于內建缺陷危險的認識已有多年了，但我們并不是總能擁有相應工具和時間将這些知識好好用起來。XP不僅提醒我們有可能有嚴重的內建錯誤，而且從實踐與工具的角度提供了一種新的認識。

　　40-hour week. Some of XP's 12 practices are principles, while others, such as the 40-hour practice, sound more like rules. I agree with XP's sentiments here; I just don't think work hours define the issue. I would prefer a statement like, "Don't burn out the troops," rather than a 40-hour rule. There are situations in which working 40 hours is pure drudgery and others in which the team has to be pried away from a 60-hour work week.

　　每周隻幹40小時：XP有12條實踐的基本原則，但是有時候，比如象每周隻幹40小時的原則，聽起來更象規則。我同意XP中的觀點。隻是不認為有必要硬性規定工作小時數。相比起來，我更喜歡一句類似于"不要把部隊燒光"的話。在一些情況下，工作40小時太勞累，而在另外一些組裡，甚至需要一周60個工作時。

　　Jeffries provided additional thoughts on overtime. "What we say is that overtime is defined as time in the office when you don't want to be there. And that you should work no more than one week of overtime. If you go beyond that, there's something wrong -- and you're tiring out and probably doing worse than if you were on a normal schedule. I agree with you on the sentiment about the 60- hour work week. When we were young and eager, they were probably okay. It's the dragging weeks to watch for."

　　Jeffries提供了關于加班的更多思索："我們說的是加班被定義為我們不想在辦公室的時候呆在辦公室。而且你不應當加班超過一周。如果你超過了，就有什麼東西出了問題――你過于勞累，有可能比你按時下班幹的還差。我同意你關于60工作時一周的感受。在我們年輕和滿身幹勁的時候，這也許沒問題。值得注意的是拖沓的一周又一周。"

　　I don't think the number of hours makes much difference. What defines the difference is volunteered commitment. Do people want to come to work? Do they anticipate each day with great relish? People have to come to work, but they perform great feats by being committed to the project, and commitment only arises from a sense of purpose.

　　我不認為一周的工作時間會造成大的差别。決定差別的是自願的貢獻。人們願意來工作嗎？他們對每一天都充滿幹勁嗎？人們必須來工作，但是他們通過投入項目來創造巨大成就，而投入僅僅産生于目标感。

　　On-site customer. This practice corresponds to one of the oldest cries in software development -- user involvement. XP, as with every other rapid development approach, calls for ongoing, on-site user involvement with the project team.

　　現場客戶：這就對應到了最初軟體開發時所提出的問題――使用者參與。XP，同其他的快速開發一樣，要求客戶在現場持續地參與到項目組中。

Coding standards. XP practices are supportive of each other. For example, if you do pair programming and let anyone modify the communal code, then coding standards would seem to be a necessity.

　　編碼标準：XP實踐互相支援。例如，如果你進行配對程式設計并讓他人修改共有代碼，那麼編碼标準看起來就是必須的。