-
Extreme Programming FAQ
校对 钱五哥 [AKA]
译者 喻海涛 郭宏杰 罗予晋[AKA]
- Introduction
简介
- What is Extreme Programming? Does it involve bungee cords?
什么是极限编程（Extreme Programming）？它需要蹦级保险绳么?
Extreme Programming (or XP) is a set of values, principles and practices for rapidly developing high-quality software that provides the highest value for the customer in the fastest way possible. XP is extreme in the sense that it takes 12 well-known software development "best practices" to their logical extremes -- turning them all up to "10" (or "11" for Spinal Tap fans). See Kent Beck's introduction to Extreme Programming Explained for more details.
极限编程（Extreme Programming，或简称XP）是一套能快速开发高质量软件所需的价值观、原则和活动的集合，使软件能以尽可能快的速度开发出来并向客户提供最高的效益。说XP是极限在于它将12个众所周知的软件开发的“最佳活动”都发挥到极限“10分”（或到“11分”对超级发烧友）。更详细的细节可参看Kent Beck的关于极限编程的介绍。
- What does this have to do with Windows XP?
它和Windows XP有什么关系？
Absolutely nothing. In February 2001, Microsoft announced that the next release of their consumer Windows operating system would be called "Windows XP". The use of "XP" as shorthand for Extreme Programming predates Microsoft's use of "XP" by 2-3 years.
绝对无关。在2001年2月，微软宣布他们下一个要发布的Windows操作系统叫做“Windows XP”，用"XP"做为极限编程的缩写在2～3年前就预测了微软的"XP"用法。
- Is XP a methodology?
XP是一种方法学么？
No and yes. No, it's not a methodology in the sense of a lot of paperwork and additional hoops for developers to jump through. But yes, in the sense that it is a repeatable process for developing software, it is in fact a methodology, although a lightweight one.
可以说不是，也可以说是。说它不是一种方法学是因为开发者可以跳过许多纸面上的东西和附加的条条框框；说它是，是因为它对于开发软件来说是一种可重复的过程，它实际上也是一种方法学，但是属于“轻量级”的。 Alistair Cockburn, who studies methodologies for a living, characterizes XP as a lightweight, low-ceremony, high-discipline methodology.
Alistair Cockburn,一个研究方法学的学者，描述XP为轻量级的、不讲究繁文缛节的、高纪律性的方法学。
- Where did XP come from?
XP起源于何处？
XP was originated by Kent Beck, based on his years of practice as an O-O software developer, and in particular, his work with Ward Cunningham using the Smalltalk programming language. Because Smalltalk was the first popular O-O language, Ward and Kent have been doing object-oriented programming longer than just about anyone else.
XP最早是由Kent Beck提出来的，源于他多年的O-O实践，特别是他和Ward Cunningham一起使用Smalltalk语言进行开发的工作经验。因为Smalltalk是第一种流行的O-O语言，Ward和Kent比其他任何人都有更长的面向对象的编程经历。
- What are the basic practices of XP?
XP的基本实践是什么？
The 12 core practices of XP are:
12个XP的核心实践是：
The Planning Game: Business and development cooperate to produce the maximum business value as rapidly as possible. The planning game happens at various scales, but the basic rules are always the same:
游戏策划：结合业务和开发以尽可能快地产生商业效益。游戏策划的范围各有不同，但基本原则都是一样的：
Business comes up with a list of desired features for the system. Each feature is written out as a User Story, which gives the feature a name, and describes in broad strokes what is required. User stories are typically written on 4x6 cards.
业务提供了一张系统的期望特征表，把每个特征作为一个用户需求（User Story）记录下来,其中包括特征名和需求的各种提法。用户需求典型地是写在4x6的卡片上。
Development estimates how much effort each story will take, and how much effort the team can produce in a given time interval (the iteration).
开发工作要估计每条需求所需要的工作量，以及开发团队在一个时间段（一次迭代）里能完成的工作量。
Business then decides which stories to implement in what order, as well as when and how often to produce a production releases of the system.
然后企业就确定用何种顺序实现哪些用户需求，同时确定可发布的产品以的发布频度。
Small Releases: Start with the smallest useful feature set. Release early and often, adding a few features each time.
短时发布：以实现最小的可用特征集开始。尽早发布和更新，每次只增加少数几个新特征。
System Metaphor: Each project has an organizing metaphor, which provides an easy to remember naming convention.
系统绰号：每个项目有一个有规律的绰号，提供容易记住的命名规则。
Simple Design: Always use the simplest possible design that gets the job done. The requirements will change tomorrow, so only do what's needed to meet today's requirements.
简要设计：使用尽可能最简单的设计来完成工作。需求也许明天就会改变，因此我们所需的只是完成今天所遇到的需求。
Continuous Testing: Before programmers add a feature, they write a test for it. When the suite runs, the job is done. Tests in XP come in two basic flavors.
连续测试：在程序员增加一项特征前就完成测试程序。当整个系统能运行时，测试任务也就结束了。XP中的测试包括两种类型：
Unit Tests are written by the developers to test functionality as they write it. Each unit test typically tests only a single class, or a small cluster of classes.
单元测试（Unit Tests）(代码)是开发者编写用来对他们所做的程序进行功能测试的。每个单元测试典型地只测试单个的类或很少几个类的组合。
Acceptance Tests (also known as Functional Tests) are specified by the customer to test that the overall system is functioning as specified. Acceptance tests typically test the entire system, or some large chunk of it. When all the acceptance tests pass for a given user story, that story is considered complete.
验收测试(也被称为功能测试)是由客户指定来测试整个系统是否完成既定功能。验收测试通常测试整个系统，或系统中一些大的模块。当验收测试达到某条给定需求后，此需求就认为已经完成了。
Refactoring: Refactor out any duplicate code generated in a coding session. You can do this with confidence that you didn't break anything because you have the tests.
求精（Refactoring）：去掉在编码过程中产生的任何重复代码，你可以自信地认为这么做不会破坏任何东西，因为你还有测试作为后盾。
Pair Programming: All production code is written by two programmers sitting at one machine. Essentially, all code is reviewed as it is written.
编程对子：所有代码都是坐在同一台机器前的两个程序员共同编写的，因此所有代码在编写的同时就完成了复查工作。
Collective Code Ownership: No single person "owns" a module. Any developer is expect to be able to work on any part of the codebase at any time.
集体代码所有权：没有单独的一个人能“拥有”一个模块，所有开发者都能在任何时候针对代码库的任何部分进行工作。
Continuous Integration: All changes are integrated into the codebase at least daily. The tests have to run 100% both before and after integration.
连续整合：至少每天都将所有的改变整合到代码库中，在整合前后都要进行100%的测试。
40-Hour Work Week: Programmers go home on time. In crunch mode, up to one week of overtime is allowed. But multiple consecutive weeks of overtime are treated as a sign that something is very wrong with the process.
每周4干40小时：让开发人员按时回家。在特殊情况下，最多也只允许加班一周，但连续加班几周就是工作过程出了问题的迹象。
On-site Customer: Development team has continuous access to a real live customer, that is, someone who will actually be using the system. For commercial software with lots of customers, a customer proxy (usually the product manager) is used instead.
在位(on-site)客户：开发团队要经常和活生生的客户接触，即系统的实际用户。对于有很多客户的商业软件，可以用客户代理（经常就是产品经理）来代替。
Coding Standards: Everyone codes to the same standards. Ideally, you shouldn't be able to tell by looking at it who on the team has touched a specific piece of code.
编码标准：每个人都按相同的标准编写代码。理想情况下，你无法通过看代码的形式来说出是团队中的谁编写的。
转载
