欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久

1. Extreme Programming FAQ
   校對 錢(qián)五哥 [AKA]
   譯者 喻海濤 郭宏杰 羅予晉[AKA]
2. Introduction
   簡(jiǎn)介
3. 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，或簡(jiǎn)稱(chēng)XP）是一套能快速開(kāi)發(fā)高質(zhì)量軟件所需的價(jià)值觀(guān)、原則和活動(dòng)的集合，使軟件能以盡可能快的速度開(kāi)發(fā)出來(lái)并向客戶(hù)提供最高的效益。說(shuō)XP是極限在于它將12個(gè)眾所周知的軟件開(kāi)發(fā)的“最佳活動(dòng)”都發(fā)揮到極限“10分”（或到“11分”對超級發(fā)燒友）。更詳細的細節可參看Kent Beck的關(guān)于極限編程的介紹。
4. What does this have to do with Windows XP?
   它和Windows XP有什么關(guān)系？
   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.
   絕對無(wú)關(guān)。在2001年2月，微軟宣布他們下一個(gè)要發(fā)布的Windows操作系統叫做“Windows XP”，用"XP"做為極限編程的縮寫(xiě)在2～3年前就預測了微軟的"XP"用法。
5. Is XP a methodology?
   XP是一種方法學(xué)么？
   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.
   可以說(shuō)不是，也可以說(shuō)是。說(shuō)它不是一種方法學(xué)是因為開(kāi)發(fā)者可以跳過(guò)許多紙面上的東西和附加的條條框框；說(shuō)它是，是因為它對于開(kāi)發(fā)軟件來(lái)說(shuō)是一種可重復的過(guò)程，它實(shí)際上也是一種方法學(xué)，但是屬于“輕量級”的。 Alistair Cockburn, who studies methodologies for a living, characterizes XP as a lightweight, low-ceremony, high-discipline methodology.
   Alistair Cockburn,一個(gè)研究方法學(xué)的學(xué)者，描述XP為輕量級的、不講究繁文縟節的、高紀律性的方法學(xué)。
6. 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提出來(lái)的，源于他多年的O-O實(shí)踐，特別是他和Ward Cunningham一起使用Smalltalk語(yǔ)言進(jìn)行開(kāi)發(fā)的工作經(jīng)驗。因為Smalltalk是第一種流行的O-O語(yǔ)言，Ward和Kent比其他任何人都有更長(cháng)的面向對象的編程經(jīng)歷。
7. What are the basic practices of XP?
   XP的基本實(shí)踐是什么？
   The 12 core practices of XP are:
   12個(gè)XP的核心實(shí)踐是：

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:
游戲策劃：結合業(yè)務(wù)和開(kāi)發(fā)以盡可能快地產(chǎn)生商業(yè)效益。游戲策劃的范圍各有不同，但基本原則都是一樣的：
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.
業(yè)務(wù)提供了一張系統的期望特征表，把每個(gè)特征作為一個(gè)用戶(hù)需求（User Story）記錄下來(lái),其中包括特征名和需求的各種提法。用戶(hù)需求典型地是寫(xiě)在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).
開(kāi)發(fā)工作要估計每條需求所需要的工作量，以及開(kāi)發(fā)團隊在一個(gè)時(shí)間段（一次迭代）里能完成的工作量。
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.
然后企業(yè)就確定用何種順序實(shí)現哪些用戶(hù)需求，同時(shí)確定可發(fā)布的產(chǎn)品以的發(fā)布頻度。
Small Releases: Start with the smallest useful feature set. Release early and often, adding a few features each time.
短時(shí)發(fā)布：以實(shí)現最小的可用特征集開(kāi)始。盡早發(fā)布和更新，每次只增加少數幾個(gè)新特征。
System Metaphor: Each project has an organizing metaphor, which provides an easy to remember naming convention.
系統綽號：每個(gè)項目有一個(gè)有規律的綽號，提供容易記住的命名規則。
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.
簡(jiǎn)要設計：使用盡可能最簡(jiǎn)單的設計來(lái)完成工作。需求也許明天就會(huì )改變，因此我們所需的只是完成今天所遇到的需求。
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.
連續測試：在程序員增加一項特征前就完成測試程序。當整個(gè)系統能運行時(shí)，測試任務(wù)也就結束了。XP中的測試包括兩種類(lèi)型：
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）(代碼)是開(kāi)發(fā)者編寫(xiě)用來(lái)對他們所做的程序進(jìn)行功能測試的。每個(gè)單元測試典型地只測試單個(gè)的類(lèi)或很少幾個(gè)類(lèi)的組合。
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.
驗收測試(也被稱(chēng)為功能測試)是由客戶(hù)指定來(lái)測試整個(gè)系統是否完成既定功能。驗收測試通常測試整個(gè)系統，或系統中一些大的模塊。當驗收測試達到某條給定需求后，此需求就認為已經(jīng)完成了。
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）：去掉在編碼過(guò)程中產(chǎn)生的任何重復代碼，你可以自信地認為這么做不會(huì )破壞任何東西，因為你還有測試作為后盾。
Pair Programming: All production code is written by two programmers sitting at one machine. Essentially, all code is reviewed as it is written.
編程對子：所有代碼都是坐在同一臺機器前的兩個(gè)程序員共同編寫(xiě)的，因此所有代碼在編寫(xiě)的同時(shí)就完成了復查工作。
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.
集體代碼所有權：沒(méi)有單獨的一個(gè)人能“擁有”一個(gè)模塊，所有開(kāi)發(fā)者都能在任何時(shí)候針對代碼庫的任何部分進(jìn)行工作。
Continuous Integration: All changes are integrated into the codebase at least daily. The tests have to run 100% both before and after integration.
連續整合：至少每天都將所有的改變整合到代碼庫中，在整合前后都要進(jìn)行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小時(shí)：讓開(kāi)發(fā)人員按時(shí)回家。在特殊情況下，最多也只允許加班一周，但連續加班幾周就是工作過(guò)程出了問(wèn)題的跡象。
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)客戶(hù)：開(kāi)發(fā)團隊要經(jīng)常和活生生的客戶(hù)接觸，即系統的實(shí)際用戶(hù)。對于有很多客戶(hù)的商業(yè)軟件，可以用客戶(hù)代理（經(jīng)常就是產(chǎn)品經(jīng)理）來(lái)代替。
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.
編碼標準：每個(gè)人都按相同的標準編寫(xiě)代碼。理想情況下，你無(wú)法通過(guò)看代碼的形式來(lái)說(shuō)出是團隊中的誰(shuí)編寫(xiě)的。