栖息谷-管理人的网上家园

标题: XP极限编程（中英文对照） [打印本页]
作者: 成成    时间: 2004-2-7 12:59
标题: XP极限编程（中英文对照）

Extreme Programming

作者 不详 来源 http://www.cutter.com/

审校 BigMac[AKA]
译者 march-bird lucian yjf taopin wl jazz韩伟 nullgate Simon[AKA]

As we have explored in several issues of eAD, the two most pressing issues in information technology today are:
　　正如我们在eAD的若干期中探究的那样，当今信息技术中最迫切的两个问题是:

Change is changing. Not only does the pace of change continue to accelerate, but, as the September issue of eAD pointed out, organizations are having to deal with different types of change -- disruptive change and punctuated equilibrium. Disruptive technologies, like personal computers in the early 1980s, impact an industry (in the case of PCs, several related industries), while a punctuated equilibrium - a massive intervention into an ecosystem or an economy -- impacts a very large number of species, or companies. The Internet, which has become the backbone for e-commerce and e-business, has disrupted a wide range of industries -- more a punctuated equilibrium than a disruption.
　　变化本身也在不断地变化中。不仅仅是变化的速度在不断地提高，而且，如eAD的10月中所指出的， 组织正在不得不应付各种类型的变化-- 剧变与不断被打破的平衡。 产生剧变的技术，象在80年代早期的个人计算机，冲击了一个工业(PC机以及若干相关的工业)而不时打断的平衡--一个对生态系统或者对整个经济产生巨大影响的介入--则 影响了无数的物种，或者说，公司。已经成为电子商务支柱的Internet, 就已使大范围的行业产生剧变--更多的是打断的平衡而不仅仅是一次剧变。 　 　 When whole business models are changing, when time-to-market becomes the mantra of companies, when flexibility and interconnectedness are demanded from even the most staid organization, it is then that we must examine every aspect of how business is managed, customers are delighted, and products are developed.
　　当整个商业模式正在发生变化，当"时间意味着市场"正成为公司的咒语，当适应性与互连性正在成为甚至是最呆板的组织的需要的时候，我们将有必要检查以下的每一个方面:商业是如何管理的，客户为什么而感到高兴，以及产品是如何开发的。 The Extreme Programming movement has been a subset of the object-oriented (OO) programming community for several years, but has recently attracted more attention, especially with the recent release of Kent Beck's new book Extreme Programming Explained: Embrace Change. Don't be put off by the somewhat "in-your- face" moniker of Extreme Programming (XP to practitioners). Although Beck doesn't claim that practices such as pair programming and incremental planning originated with XP, there are some very interesting, and I think important, concepts articulated by XP. There's a lot of talk today about change, but XP has some pretty good ideas about how to actually do it. Hence the subtitle, Embrace Change.
　　终极编程(Extreme Programming )运动成为面向对象编程这个团体的一部分已经有数年了， 但是直到最近才引起了越来越多的注意，特别是最近Kent Beck的《终极编程 释义:拥抱变化》(Extreme Programming Explained: Embrace Change)一书的出版。千万不要因为终极编程(业内人简称为XP)这一称呼而对它产生反感。 尽管Beck没有说象配对编程(pair programming)，增量式计划(incremental planning)之类的来源 于XP,但是仍然有一些非常有趣的，我认为也是很重要的概念可以借用XP来表达。现有有许多关于变化的讨论， 但是XP却有许多如何实际去做的非常好的想法。也就是这个副标题:拥抱变化。 There is a tendency, particularly by rigorous methodologists, to dismiss anything less ponderous than the Capability Maturity Model (CMM) or maybe the International Organization for Standardization's standards, as hacking. The connotation: hacking promotes doing rather than thinking and therefore results in low quality. This is an easy way to dismiss practices that conflict with one's own assumptions about the world.
　　有一种趋势，特别在那些严格的方法论者中，希望剔除那些与"能力 成熟度模型"(Capability Maturity Model CMM)或者是国际标准化组织的标准相比不那么笨重的方法，比如象hacking.注释: hacking推崇行动而不是思考从而导致了较低的质量。 剔除与某人关于这个世界的假设相冲突的实践，这倒不失为一种简单的方法。 Looked at another way, XP may be a potential piece of a puzzle I've been writing about over the past 18 months. Turbulent times give rise to new problems that, in turn, give rise to new practices -- new practices that often fly in the face of conventional wisdom but survive because they are better adapted to the new reality. There are at least four practices I would assign to this category:
　　从另一个角度来看XP，它倒可能是一个难题的某个潜在的部分，这个一个我在过去18个月中一直都在写的内容。混乱 的时期产生新的问题，而后者又导致了新的实践--新的实践公然违抗 传统的知识，但却得以幸存下来是因为它们能更好地适应这个新的现实世界。至少有四种实践方式我觉得是属于这个范畴的: Although there are differences in each of these practices, there are also similarities: they each describe variations from the conventional wisdom about how to approach software development. Whereas lean and adaptive development practices target strategic and project management, XP brings its differing world view to the realm of the developer and tester.
　　尽管这些实践中存在着差异，但是它们中也有相似的地方:它们都描述了与传统软件开发不同的方法。 虽然轻量级的开发与自适应开发针对的是战略与项目管理的，但是XP却用不同的视角将开发方法带入了程序员与测试员的领域。 Much of XP is derived from good practices that have been around for a long time. "None of the ideas in XP are new. Most are as old as programming," Beck offers to readers in the preface to his book. I might differ with Beck in one respect: although the practices XP uses aren't new, the conceptual foundation and how they are melded together greatly enhance these "older" practices. I think there are four critical ideas to take away from XP (in addition to a number of other good ideas):
　　XP中许多部分其实都来自于业已存在的那些优秀的开发实践。"XP中没有一个想法是全新的。大多数想法产生的时间实际上和编程一样古老"Beck在他书中的前言中这样说道。但是我在某一个方面考虑的也许与Beck有所不同： 尽管XP所用的实践方式不是全新的，但是概念的建立以及它们如何融合在一起极大地增强了 这些"老"的实践。我想(除了许多其它的好思想外，还)可以从XP中提炼出四个关键的思想: But first, I discuss some XP basics: the dozen practices that define XP.
　　但是首先，我们来讨论XP的基础:那十二个用于XP的实践方式。
作者: 成成    时间: 2004-2-7 13:00
XP－基础 I must admit that one thing I like about XP's principal figures is their lack of pretension. XP proponents are careful to articulate where they think XP is appropriate and where it is not. While practitioners like Beck and Ron Jeffries may envision that XP has wider applicability, they are generally circumspect about their claims. For example, both are clear about XP's applicability to small (less than 10 people), co-located teams (with which they have direct experience); they don't try to convince people that the practices will work for teams of 200.
　　我必须承认一件事情，就是我喜欢XP的原因应该是它没有其他的那些花哨的东西。支持XP的人们总是会向你指出XP适合的地方以及他的某些局限性。而XP的实践者Beck以及Ron Jeffties却相信XP会有更广泛的应用前景。他们通常对于自己的要求都是很谨慎的。例如：小的（小于10人），公司局部（他们有直接的经验）两者对于XP的适应性都是很清楚的；他们并没有试图让人们相信XP可以适用于一个200人的团队。

The Project
工程

The most prominent XP project reported on to date is the Chrysler Comprehensive Compensation system (the C3 project) that was initiated in the mid-1990s and converted to an XP project in 1997. Jeffries, one of the "Three Extremoes" (with Beck and Ward Cunningham), and I spent several hours talking about the C3 project and other XP issues at the recent Miller Freeman Software Developer conference in Washington, DC, USA.
　　最为著名的XP项目是克莱斯勒综合补偿系统（称为C3工程），它在上个世纪的90年代中期开始，到1997演变为XP。Jeffries,是"终极编程三人组"之一（另外两个是Beck同Ward Cunningham） 。我在华盛顿特区同自由软件人谈论了有关C3的以及其他与XP项目有关的东西。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
注解： Chrysler Comprehensive Compensation system 克莱斯勒综合补偿系统
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ Originally, the C3 project was conceived as an OO programming project, specifically using Smalltalk. Beck, a well-known Smalltalk expert, was called in to consult on Smalltalk performance optimization, and the project was transformed into a pilot of OO (XP) practices after the original project was deemed unreclaimable. Beck brought in Jeffries to assist on a more full-time basis, and Jeffries worked with the C3 team until spring 1999. The initial requirements were to handle the monthly payroll of some 10,000 salaried employees. The system consists of approximately 2,000 classes and 30,000 methods and was ready within a reasonable tolerance period of the planned schedule.
　　最初，C3是一个基于OO（面向对象技术）的开发项目，尤其是它采用Smaltalk语言进行开发。（Smaltalk ：Xerox公司开发的一种高级程序设计语言,它支持和鼠标合用的选项屏驱动式应用程序,有助于建立便于使用的计算机程序。）作为著名的Smalltalk专家，Beck被邀请来讨论有关SmalTalk性能优化的问题，并且在原项目被认为不可救要的时候将其变为一个采用面向对象OO（XP）方法的试验性项目。Beck并且带来了Jeffries用于帮助那些基本的东西，Jeffries在C3组一直干到1999年的春天。最开始的需求是要做一个对约10，000个雇员每月薪水发放进行管理的系统。这个系统由大约2，000个类以及30，000个方法构成，并且在计划方面提供有合理的容忍度 As we talked, I asked Jeffries how success on the C3 project translated into XP use on other Chrysler IT projects. His grin told me all I needed to know. I've been involved in enough rapid application development (RAD) projects for large IT organizations over the years to understand why success does not consistently translate into acceptance. There are always at least a hundred very good reasons why success at RAD, or XP, or lean development, or other out-of-the-box approaches doesn't translate into wider use -- but more on this issue later.
　　正向我们所谈到，我问Jeffries他怎样成功的将C3变为XP并应用到其他的克莱斯勒IT项目。他笑着告诉了我。多年来我为许多大型IT组织开发了不少RAD系统（快速原型开发），因此我知道为什么我们无法将成功的经验运用于其它项目中. 对于RAD, XP, 轻量级的开发以及其它一些未得到广泛应用的方法, 它们成功的原因至少有一百条.
作者: 成成    时间: 2004-2-7 13:00
XP－基础 I must admit that one thing I like about XP's principal figures is their lack of pretension. XP proponents are careful to articulate where they think XP is appropriate and where it is not. While practitioners like Beck and Ron Jeffries may envision that XP has wider applicability, they are generally circumspect about their claims. For example, both are clear about XP's applicability to small (less than 10 people), co-located teams (with which they have direct experience); they don't try to convince people that the practices will work for teams of 200.
　　我必须承认一件事情，就是我喜欢XP的原因应该是它没有其他的那些花哨的东西。支持XP的人们总是会向你指出XP适合的地方以及他的某些局限性。而XP的实践者Beck以及Ron Jeffties却相信XP会有更广泛的应用前景。他们通常对于自己的要求都是很谨慎的。例如：小的（小于10人），公司局部（他们有直接的经验）两者对于XP的适应性都是很清楚的；他们并没有试图让人们相信XP可以适用于一个200人的团队。

The Project
工程

The most prominent XP project reported on to date is the Chrysler Comprehensive Compensation system (the C3 project) that was initiated in the mid-1990s and converted to an XP project in 1997. Jeffries, one of the "Three Extremoes" (with Beck and Ward Cunningham), and I spent several hours talking about the C3 project and other XP issues at the recent Miller Freeman Software Developer conference in Washington, DC, USA.
　　最为著名的XP项目是克莱斯勒综合补偿系统（称为C3工程），它在上个世纪的90年代中期开始，到1997演变为XP。Jeffries,是"终极编程三人组"之一（另外两个是Beck同Ward Cunningham） 。我在华盛顿特区同自由软件人谈论了有关C3的以及其他与XP项目有关的东西。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
注解： Chrysler Comprehensive Compensation system 克莱斯勒综合补偿系统
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ Originally, the C3 project was conceived as an OO programming project, specifically using Smalltalk. Beck, a well-known Smalltalk expert, was called in to consult on Smalltalk performance optimization, and the project was transformed into a pilot of OO (XP) practices after the original project was deemed unreclaimable. Beck brought in Jeffries to assist on a more full-time basis, and Jeffries worked with the C3 team until spring 1999. The initial requirements were to handle the monthly payroll of some 10,000 salaried employees. The system consists of approximately 2,000 classes and 30,000 methods and was ready within a reasonable tolerance period of the planned schedule.
　　最初，C3是一个基于OO（面向对象技术）的开发项目，尤其是它采用Smaltalk语言进行开发。（Smaltalk ：Xerox公司开发的一种高级程序设计语言,它支持和鼠标合用的选项屏驱动式应用程序,有助于建立便于使用的计算机程序。）作为著名的Smalltalk专家，Beck被邀请来讨论有关SmalTalk性能优化的问题，并且在原项目被认为不可救要的时候将其变为一个采用面向对象OO（XP）方法的试验性项目。Beck并且带来了Jeffries用于帮助那些基本的东西，Jeffries在C3组一直干到1999年的春天。最开始的需求是要做一个对约10，000个雇员每月薪水发放进行管理的系统。这个系统由大约2，000个类以及30，000个方法构成，并且在计划方面提供有合理的容忍度 As we talked, I asked Jeffries how success on the C3 project translated into XP use on other Chrysler IT projects. His grin told me all I needed to know. I've been involved in enough rapid application development (RAD) projects for large IT organizations over the years to understand why success does not consistently translate into acceptance. There are always at least a hundred very good reasons why success at RAD, or XP, or lean development, or other out-of-the-box approaches doesn't translate into wider use -- but more on this issue later.
　　正向我们所谈到，我问Jeffries他怎样成功的将C3变为XP并应用到其他的克莱斯勒IT项目。他笑着告诉了我。多年来我为许多大型IT组织开发了不少RAD系统（快速原型开发），因此我知道为什么我们无法将成功的经验运用于其它项目中. 对于RAD, XP, 轻量级的开发以及其它一些未得到广泛应用的方法, 它们成功的原因至少有一百条.
作者: 成成    时间: 2004-2-7 13:01
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) arrow Test arrow Code arrow 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的统计数据是尽管它在发现缺陷方面非常有效，但通过团队对于好的开发实践持续的学习和协作，可以更好的在第一时间预防缺陷。
作者: 成成    时间: 2004-2-7 13:01
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).
　　"配对编程是两个人试图同时编程和理解如何更好编程的一种对话"，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不仅提醒我们有可能有严重的集成错误，而且从实践与工具的角度提供了一种新的认识。
作者: 成成    时间: 2004-2-7 13:02
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实践相互支持。例如，如果你进行配对编程并让他人修改共有代码，那么编码标准看起来就是必须的。
作者: 成成    时间: 2004-2-7 13:03
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实践相互支持。例如，如果你进行配对编程并让他人修改共有代码，那么编码标准看起来就是必须的。
作者: 成成    时间: 2004-2-7 13:03

Managing XP
管理XP

One area in which XP (at least as articulated in Beck's book) falls short is management, understandable for a practice oriented toward both small project teams and programming. As Beck puts it, "Perhaps the most important job for the coach is the acquisition of toys and food." (Coaching is one of Beck's components of management strategy.)
　　对于针对小型项目以及编程而言，在XP（至少是Beck的书中）里对管理的欠缺是可以理解的，。就如Beck写的，"对于教练(coach)来说，或许最重要的工作就是获得玩具同食物"（指导是Beck的管理战略中的一个组成部分） With many programmers, their recommended management strategy seems to be: get out of the way. The underlying assumption? Getting out of the way will create a collaborative environment. Steeped in the tradition of task-based project management, this assumption seems valid. However, in my experience, creating and maintaining highly functional collaborative environments challenges management far beyond making up task lists and checking off their completion.
　　同许多的程序员一样，他们推荐的管理策略像是：躲避。下面的假定呢？躲避会建立一个协作的环境，在传统的基于任务的管理里，这个假定是有效的。然而，根据我的经验，创造并维持一个协作的环境会挑战管理远离编制任务列表以及检查。
Figure 1 Figure 1 -- Historical lifecycle change costs.

Figure 2 Figure 2 -- Comtemporary lifecycle change costs.

The Cost of Change
变化的代价

Early on in Beck's book, he challenges one of the oldest assumptions in software engineering. From the mid-1970s, structured methods and then more comprehensive methodologies were sold based on the "facts" shown in Figure 1. I should know; I developed, taught, sold, and installed several of these methodologies during the 1980s.
　　Beck从他的早期的著作开始，就不断向那些软件工程中的一些"古训"发出挑战。从19世纪70年代中期的结构化方法，以至后来的那些更复杂的方法，他们都基于如图1所示的那个"事实"，在整个80年代，我必须了解、使用、讨论、实施这些方法。 Beck asks us to consider that perhaps the economics of Figure 1, probably valid in the 1970s and 1980s, now look like Figure 2 - that is, the cost of maintenance, or ongoing change, flattens out rather than escalates. Actually, whether Figure 2 shows today's cost profile or not is irrelevant -- we have to make it true! If Figure 1 remains true, then we are doomed because of today's pace of change.
　　Beck却给我们提了一个问题，那些在70年代和80年代也许还能起到效果的方法，他们的经费开销状况（如图1）现在已经发生了变化（如图2），也就是说，维护的成本（也可以等价为不断发生的变化）降低了，而不是越来越高。实际上，图2所示的开销情况在当今是否是事实其实并不重要，重要的是我们必须认识到，如果图1的现象还在继续重演的话，我们只有死路一条，因为当今时代变化实在太快了（也就是说维护的成本将是一个天价）。 The vertical axis in Figure 1 usually depicts the cost of finding defects late in the development cycle. However, this assumes that all changes are the results of a mistake -- i.e., a defect. Viewed from this perspective, traditional methods have concentrated on "defect prevention" in early lifecycle stages. But in today's environment, we can't prevent what we don't know about -- changes arise from iteratively gaining knowledge about the application, not from a defective process. So, although our practices need to be geared toward preventing some defects, they must also be geared toward reducing the cost of continuous change. Actually, as Alistair Cockburn points out, the high cost of removing defects shown by Figure 1 provides an economic justification for practices like pair programming.
　　图1中的y轴通常用来表示在开发周期的后期发现错误后需要花费的改错成本。可是，这正验证了一个假设，即后期所有需要做的开动均来自前期的一个错误，比方说一个设计缺陷。从这一点来看，传统方法太依赖于在软件生命周期的早期"不出错"。但是在当今瞬息万变的环境中，我们不能完全预防住那些我们预测不到的东西--即由应用需求不断增长而带来的变化，并且这种变化在早期不可能遇见并加以预防。因此，虽然我们要尽可能在早期做出某些应付变化的预防措施，但是更重要的是我们要减少后期改变所带来的开销。正如 Alistai Cockburn 所指出的，需要高成本的图1所示的那种改正缺陷方法，正好从节省开支的角度给了一些实用的方法（如配对编程）一个好的理由。 In this issue of eAD, I want to restrict the discussion to change at the project or application level -- decisions about operating systems, development language, database, middleware, etc., are constraints outside the control of the development team. (For ideas on "architectural" flexibility, see the June and July 1999 issues of ADS.) Let's simplify even further and assume, for now, that the business and operational requirements are known.
　　在本期eAD杂志中，我打算把讨论定位于项目或应用软件层次上的变化--对类似操作系统、编程语言、数据库、组件等的讨论不在讨论之列。（关于软件结构的灵活性，可以参考ADS杂志1999年6月的那期）另外，让我们进一步做个简化，即假定软件的用户需求已经确定。 Our design goal is to balance the rapid delivery of functionality while we also create a design that can be easily modified. Even within the goal of rapid delivery, there remains another balance: proceed too hurriedly and bugs creep in; try to anticipate every eventuality and time flies. However, let's again simplify our problem and assume we have reached a reasonable balance of design versus code and test time.
　　我们的目标是既能快速不断的发布新功能，同时又要让软件的设计易于更改。即使是在快速发布这个目标下，仍然需要在"快速发布但Bug丛生"和"面面俱到但旷日持久"之间进行取舍。因此，让我再简化一下我们要讨论的问题，我们假定我们已经在设计、编码和测试这三者之间取得了合理的平衡。 With all these simplifications, we are left with one question: how much anticipatory design work do we do? Current design produces the functionality we have already specified. Anticipatory design builds in extra facilities with the anticipation that future requirements will be faster to implement. Anticipatory design trades current time for future time, under the assumption that a little time now will save more time later. But under what conditions is that assumption true? Might it not be faster to redesign later, when we know exactly what the changes are, rather than guessing now?
　　在上面这些简化的基础上，还留有一个尾巴：我们在设计时对于未知的未来要看多远？现在的设计已经实现了我们现在想到的一些功能。具有预见性的设计可以使未来的需求更快的获得实现，也就是说预见性设计方法在以现在的时间换取未来的时间，如果一点点现在的时间可以换来未来节约大量时间，当然是划算的。但是这种建设怎么才能成为现实呢？也许未来出了问题就整个重新设计一遍也不慢，那又何必现在瞎猜呢？ This is where refactoring enters the equation. Refactoring, according to author Martin Fowler, is "the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure." XP proponents practice continuous, incremental refactoring as a way to incorporate change. If changes are continuous, then we'll never get an up-front design completed. Furthermore, as changes become more unpredictable -- a great likelihood today -- then much anticipatory design likely will be wasted.
　　这就是我们为什么要提出重构的原因。重构，Martin Fowler说过，是不改变软件对外表现但是重整内务的一种改进。XP方法的支持者在变化的环境中实践了连续的、增量式的重构方法。如果变化是不断演化的的，那就不可能存在什么一步到位的设计方法。说白了，如果变化不可预测--正如当今社会的情况--过多的在设计时考虑以后可能的变化，完全是一种浪费。
作者: 成成    时间: 2004-2-7 13:05
I think the diagram in Figure 3 depicts the situation prior to the rapid-paced change of the Internet era. Since the rate of change (illustrated by the positioning of the balance point in the figure) was lower, more anticipatory designing versus refactoring may have been reasonable. As Figure 4 shows, however, as the rate of change increases, the viability of anticipatory design loses out to refactoring- - a situation I think defines many systems today.
　　我认为图3给出的是互联网时代到来之前的情况。由于变化的速度慢（图中由天平的支点比较靠左来表示），早期的预测多一些是合理的。但是在图4中，由于变化速度变快乐，设计时预测太多是得不偿失的，这种情况正是现在许多系统所面临的。 In the long run, the only way to test whether a design is flexible involves making changes and measuring how easy they are to implement. One of the biggest problems with the traditional up- front-design-then-maintain strategy has been that software systems exhibit tremendous entropy; they degrade over time as maintainers rush fixes, patches, and enhancements into production. The problem is worse today because of the accelerated pace of change, but current refactoring approaches aren't the first to address the problem. Back in the "dark ages" (circa 1986), Dave Higgins wrote Data Structured Software Maintenance, a book that addressed the high cost of maintenance, due in large part to the cumulative effects of changes to systems over time. Although Higgins advocated a particular program-design approach (the Warnier/Orr Approach), one of his primary themes was to stop the degradation of systems over time by systematically redesigning programs during maintenance activities.
　　在一个长期项目中，检验一个设计是否具有很好的灵活性是通过变化需求，同时看看原设计能否很容易的实现新变化的需求。这种传统的"先设计，再维护"策略的最大问题在于软件系统存在非常大的熵（极易变化，没有规律）。一个系统随着时间的推移，维护、改错、打补丁、增强功能等工作会使系统的熵越来越大。现在由于外部环境变化加快，情况正越来越糟。不过，现在的重构技术也不是第一个试图解决这个问题的方法。早在所谓的"黑暗时期"（circa 1986），Dave Higgins 就写过一本名为"Data Structured Software Maintenance"的书，该书指出了由于随着时间的推移变化的累计影响不断增大，维护所需要的开销也将越来说庞大，Higgins 提出了一种新的设计方法（the Warnier/Orr Approach）用于阻止系统的熵增大所带来的负面影响，该方法的思想是在维护过程中有系统的对程序进行重新设计。 Higgins's approach to program maintenance was first to develop a pattern (although the term pattern was not used then) for how the program "should be" designed, then to create a map from the "good" pattern to the "spaghetti" code. Programmers would then use the map to help understand the program and, further, to revise the program over time to look more like the pattern. Using Higgins's approach, program maintenance counteracted the natural tendency of applications to degrade over time. "The objective was not to rewrite the entire application," said Higgins in a recent conversation, "but to rewrite those portions for which enhancements had been requested."
　　Higgins 的方法首先为程序改如何设计设定一种模式（虽然那时还没有模式这个提法），然后在细致的代码设计与"好"的模式之间建立一种映射，程序员即根据这种映射关系来理解系统并修改程序，使修改的结果更接近于那个模式。使用 Higgins 这个方法可以通过维护抵消系统谁时间而熵增大的趋势。Higgins 说："该方法的目标并不是重写整个系统，而只是重写那些根据需要必须增强的部分。" Although this older-style "refactoring" was not widely practiced, the ideas are the same as they are today -- the need today is just greater. Two things enable, or drive, increased levels of refactoring: one is better languages and tools, and the other is rapid change.
　　虽然这种原始的"重构"技术并没有被广泛的实践检验，其思想与现在的重构还是相通的，只不过现在的需求变化更快、更大。不过有两个东西驱动、提高了现代的重构技术：一是更好的程序设计语言和开发工具；二是更快的变化需求。 Another approach to high change arose in the early days of RAD: the idea of throwaway code. The idea was that things were changing so rapidly that we could just code applications very quickly, then throw them away and start over when the time for change arose. This turned out to be a poor long-term strategy.
　　在早期的 RAD（快速原型开发）方法中还有另一种应付变化的办法：代码抛弃思想。这个思想认为环境和需求变化太快，因此我们唯一的办法只能是快速编写新代码，并且也快速的抛弃老代码。我们认为这不是长久之计。
作者: 成成    时间: 2004-2-7 13:06

Refactoring
重构

Refactoring is closely related to factoring, or what is now referred to as using design patterns. Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, provides the foundational work on design patterns. Design Patterns serves modern-day OO programmers much as Larry Constantine and Ed Yourdon's Structural Design served a previous generation; it provides guidelines for program structures that are more effective than other program structures.
　　重构(Refactoring)与构造 (factoring)，或者说与设计模式的使用密切相关。Erich Gamma, Richard Helm, Ralph Johnson, 和 John Vlissides合著的《 Design Patterns: Elements of Reusable Object-Oriented 》一书为设计模式做出了奠基性的工作。正如Larry Constantine 和Ed Yourdon 所倡导的结构化设计一样，设计模式对当代的面向对象技术程序设计做出了巨大的贡献，为开发人员带来了福音。通过设计模式，程序的结构的比以往更为有效。 If Figure 4 shows the correct balance of designing versus refactoring for environments experiencing high rates of change, then the quality of initial design remains extremely important. Design patterns provide the means for improving the quality of initial designs by offering models that have proven effective in the past.
　　如果图表4 所显示的设计（designing）与重构(refactoring)在面对高速变化环境时的适应能力方面的差别是客观的话，初始设计的质量则显的尤为重要。通过提供过去已被证明是有效的模式，设计模式(Design patterns)提供了一种提高初始设计质量的方法。 So, you might ask, why a separate refactoring book? Can't we just use the design patterns in redesign? Yes and no. As all developers (and their managers) understand, messing with existing code can be a ticklish proposition. The cliché "if it ain't broke, don't fix it" lives on in annals of development folklore. However, as Fowler comments, "The program may not be broken, but it does hurt." Fear of breaking some part of the code base that's "working" actually hastens the degradation of that code base. However, Fowler is well aware of the concern: "Before I do the refactoring, I need to figure out how to do it safely.... I've written down the safe steps in the catalog." Fowler's book, Refactoring: Improving the Design of Existing Code, catalogs not only the before (poor code) and after (better code based on patterns), but also the steps required to migrate from one to the other. These migration steps reduce the chances of introducing defects during the refactoring effort.
　　现在，也许你会问，为什么还需要一本独立讲重构的书呢？难道我们不可以只使用设计模式来重新设计吗？可以，也不可以。正如所有的开发人员(包括管理者)都知道，修改原有的程序代码是一件棘手的事。development folklore年刊上有一句话，"if it ain't broke,don't fix it".然而，正如Fowler所提到的，"程序也许还没有'坏掉'，但却造成了潜在的危害." 害怕对那些还能"工作"的代码重新构造实际上只会加剧代码性能的衰退。同时，Fowler也清楚的认识到："在软件重构之前，需要找到安全的做法……我把这些安全的步骤写进了目录"。Fowler所写的<>,不仅编录了如何对以前的（差的）代码和以后的（基于模式设计的较好）的代码进行重构的方法，而且也包含了代码分割重构的步骤。这些步骤减少了在重构过程中出现差错的机会。 Beck describes his "two-hat" approach to refactoring -- namely that adding new functionality and refactoring are two different activities. Refactoring, per se, doesn't change the observable behavior of the software; it enhances the internal structure. When new functionality needs to be added, the first step is often to refactor in order to simplify the addition of new functionality. This new functionality that is proposed, in fact, should provide the impetus to refactor.
　　Beck用"two-hat"方法来描述重构，也就是说, 添加新的功能与重构是两种不同的行为。在本质上，重构不改变软件可见的外部功能，它只是增强了软件的内部结构。当有新的功能需要添加时，第一步常是对软件进行重构，使添加更简化。事实上，这种添加的新功能为重构提供着推动力。 Refactoring might be thought of as incremental, as opposed to monumental, redesign. "Without refactoring, the design of the program will decay," Fowler writes. "Loss of structure has a cumulative effect." Historically, our approach to maintenance has been "quick and dirty," so even in those cases where good initial design work was done, it degraded over time.
　　与重量级的再设计相反，重构可以被认为是增量（incremental）式的再设计，"没有重构，程序设计会 腐烂"，Fowler写到," 结构性的缺陷会带来累积效应 "。历史上，我们对软件维护的方法是"quick and dirty"(快速但不彻底的?)，致使一些初始设计工作做的好的项目，随着时间推移，也会"退化"（degrade）.
作者: houseguy    时间: 2004-4-16 09:32
hao



欢迎光临 栖息谷-管理人的网上家园 (http://bbs.21manager.com.cn/) Powered by Discuz! X3.2