1,268
社区成员
发帖
与我相关
我的任务
分享XP的测试-编码循环！翻译高手请指教，谁能帮我说清楚此段文章？
Write one test.
.Compile the test. It should fail to com-pile,
as you haven’t yet implemented the
code that the test calls.
.Implement just enough to compile.//怎么翻译？
(Refactor first if necessary.)
.Run the test and see it fail.
.Implement just enough to make the test
pass.
.Run the test and see it pass
.Refactor for clarity and “ once and only
once.”
.Repeat from the top..15
.Compile the test. It should fail to com-pile,
as you haven’t yet implemented the
code that the test calls.
.Implement just enough to compile.//怎么翻译？
(Refactor first if necessary.)
.Run the test and see it fail.
.Implement just enough to make the test
pass.
.Run the test and see it pass
.Refactor for clarity and “ once and only
once.”
.Repeat from the top..15
...全文
请发表友善的回复…
发表回复
w102272 2001-07-11
- 打赏
- 举报
哈哈，notyy，给我发点资料来．看来你看了不少好东东．别让我总到讨论组里头Search.
notyy 2001-07-11
- 打赏
- 举报
pmt 现在有xp工作组了吗？上面那段中文的是麦田翻译的吗？：）
to wonder：你想要什么资料呢？电子书？还是我自己写的文章，呵呵
to wonder：你想要什么资料呢？电子书？还是我自己写的文章，呵呵
xxn_xxn 2001-07-11
- 打赏
- 举报
再贴一段中文的，有兴趣的GGMM共享之：PMT 版权所有 2001 XP 是什么
--PMT XP 工作组 xp@pmtsolution.net
XP 是Extreme Programming 的缩写，从字面上可以译为极端编程。但是，XP 并不仅仅是一种编程方法，也不是中文中常理解的那种不可理喻的“极端”化做法。实际上，XP 是一种审慎的（deliberate）、有纪律（disciplined）的软件生产方法。
我们说软件生产，而不说“顺口”的软件开发，是因为软件开发常常被误解为代码编写。软件生产从手工作坊式进化到工程化，是软件业不小的进步；但人们在软件工程的实践过程中也逐渐传统的软件生产方法太过“笨重”，难于实施，导致的直接结果是生产成本的上升，于是，人们开始寻找有别于“重量级”（heavyweight）生产模式的“轻量级”（lightweight）生产模式。所谓“轻量级”（lightweight）就是只有很少的一些规则（rule）和做法（practice）。XP 就是在这样的历史背景下在90 年代初出现的。
XP 的鼻祖是Kent Beck 。最初Kent 的希望是找到更好的软件生产方法。在思考和探索的过程中，Kent 逐渐意识到改进软件项目的四个因素。第一是改善沟通（communication），第二是寻求简单（simplicity），第三是获得反馈（feedback），第四是富有勇气（courage）。这四个因素后来成为XP 的四大价值观。
有人以为XP 只在非正规的软件项目开发中才存在，而实际上，XP 特别强调客户满意和团队合作，很多商业化的软件公司都采用XP 来开发软件项目。在XP 中，开发队伍不仅仅是编程人员，还包括管理人员和客户。但是XP 适合2-10 人的开发队伍。所以大规模的软件项目XP 不大能够胜任。
经过多年的应用和实践检验，XP 总结出了软件生产的十余条做（practice），涉及软件设计、测试、编码、发布等各个环节。
虽然XP 的这些价值观和做法可以逐条的讲述，但唯有将所有这些融为一个整体，才能真正领悟XP 的思想，才能应用XP 从容面对不断变化的客户需求。g
PMT 版权所有 2001 emag@pmt sol uti on. net
XP 入门（1 ）
Rye hyt002@263.net
第一章 XP 总体介绍
译自：website ：http://www.extremeprogramming.org/
在这一章中，我们将回答一些XP 方法的疑问。
首先我们看XP 项目流程图：
接着，让我们来回答第一个问题：什么是XP ？
第一个问题：什么是XP
XP 实际上是一种经历过很多实践考验的一种软件开发的方法，它诞生了大概有5 年，它已经被成功的应用在许多大型的公司，如：Bayeris che Landesbank , Credit Swis s Life,DaimlerChrysler, First Union National Bank, Ford Motor Company and UBS.
XP 的成功得益于它对客户满意度的特别强调，XP 是以开发符合客户需要的软件为目标而产生的一种方法论，XP 使开发者能够更有效的响应客户的需求变化，哪怕在软件生命周期的后期。
同时，XP 也很强调团队合作。团队包括：项目经理，客户，开发者。他们团结在一起来保证高质量的软件。XP 其实是一种保证成功的团队开发的简单而有效的方法。
XP 强调四种价值：交流，简易，回馈，勇气。XP 程序员之间紧密的相互交流，XP 程序员也和客户紧密的交流。他们总是保持他们的设计简单明了。项目一开始，XP 就强调通过对软件的不断测试来获得反馈，程序员尽可能早的把软件交给客户，并实现客户对软件需求提出的变化，有了这些基础，XP 程序员就可以自信的面对需求和软件技术的变化。
XP 是与众不同的，它有点象快步的舞蹈。XP 开发过程包括许多的小卡片，独立的看，这些小卡片没有什么意义，但是当它们组合在一起，一幅完整的美丽的图片就可以看见，XP方法有别于传统软件开发，它是软件开发的一种新的重要的发展。它改变了我们开发程序的传统思维方式。下面我们将介绍它带给我们那些改变。
第二问题：XP 带给我们的变化
通过软件工程设计的简单而优美的软件并不比那些设计复杂而难以维护的软件有价值。
这是真的吗？XP 认为事实并非如此。
一个典型的项目花在人力上的金钱是花在硬件上的时间的20 倍，这意味着一个项目每年要花200 万美元在程序员身上，而仅仅花10 万美元在电脑设备上。很多聪明的程序员说；“我们如此聪明，发现一种方法可以节省20%的硬件开销”，然后他们使得源程序大而且难懂和难以维护，他们会说：“但是我们节省了20%或者2 万美元每年，很大的节省”。反之，如果我们写我们的程序简单而且容易扩展，我们将至少节省10%的人力开销，一笔更大的节省，这是你客户一定会注意到的一些事情。
另外一个对客户来说很重要的问题就是程序的BUGS 。XP 不只是强调测试，而且要求正确的测试。测试必须是能自动进行的，以便为程序和客户提供一个安全的环境。在编码的所有阶段，我们不断增加测试用例。当找到bug 时，我们就添加新的测试，一个紧密的安全网就这样产生了。同一个BUG 不出现两次，这些一定会引起用户的注意。
你的客户必须注意的另外一件事情：XP 开发者拥抱需求变化。XP 使我们能够接受需求的变化。
一般情况下，客户只有在系统被开发完成以后能真正去体会它。XP 却不一样，它通过加强客户的反馈来缩短开发的周期，同时获得足够的时间来改变功能和获得用户的认同。在XP 中，你的客户应该明确的知道这一点。
XP 开发过程的大多的革命是在软件开发的方法上，代码质量的重要程度超出人们一般所认为的。仅仅因为我们的客户不能明白我们的源代码并不意味着我们可以不努力去管理代码的质量。
第三个问题：我们什么时候用XP
XP 方法的产生是因为难以管理的需求变化，从一开始你的客户并不是很完全的知道他们要的系统是怎么样的，你可能面对的系统的功能一个月变化多次。在大多数软件开发环境中不断变化的需求是唯一的不变，这个时候应用XP 就可以取得别的方法不可能取得的成功。XP 方法的建立同时也是为了解决软件开发项目中的风险问题。假如你的客户在特定的时间内，需要一个相当难开发的系统，而且对于你的项目组来说，这个系统是一个新的挑战（从来没有做过），那风险就更大了，如果这个系统对于整个软件行业来说都是新的挑战，那么它的风险就更大了，采用XP 将可以减少风险，增加成功的可能。
XP 方法是为小团体开发建立的，在2-10 个人之间。假如你的团体恰好合适，你就不需要用其他的软件工程方法了，就用XP ，但是要注意你不能将XP 方法应用于大团体的开发项目中。我们应该注意，在需求一惯呈动态变化或者高具有高风险的项目中，你就会发现XP 方法在小团体的开发中的作用要远远高于在大团体的开发。
XP 方法需要一个扩展的开发团体，XP 团体不仅仅包括开发者，经理、客户也是其中的一员，所有的工作一环扣一环，问问题，商讨方法和日程，增加功能测试，这些问题的解决不仅仅涉及到软件的开发者。
另一个需要是可测试性，你必须能增加自动的单元测试和功能测试，然而在你进行这个需求的时候，你会发现有许多的问题很难测试，这需要充分发挥你的测试的经验和智慧，而且你有时还要改变你的设计以便它可以更容易的进行测试。记住：那儿有需求，那儿就应该有测试的方法。
在XP 方法的好处的清单上，最后一条是生产力。在同样的合作环境下，XP 项目都一致的表现出比使用其他方法高的多的生产力。但这从来不是XP 方法学的真正目标。XP 真实追求的目标是：在规定的时间生产出满足客户需要的软件。 假如对于你的开发来说，这是很重要的方面，你就可以选择XP 了。
在这一章我们回答了XP 的一些疑问，在下一章我们将开始介绍XP 的一些基本的规则和实践经验。
--PMT XP 工作组 xp@pmtsolution.net
XP 是Extreme Programming 的缩写，从字面上可以译为极端编程。但是，XP 并不仅仅是一种编程方法，也不是中文中常理解的那种不可理喻的“极端”化做法。实际上，XP 是一种审慎的（deliberate）、有纪律（disciplined）的软件生产方法。
我们说软件生产，而不说“顺口”的软件开发，是因为软件开发常常被误解为代码编写。软件生产从手工作坊式进化到工程化，是软件业不小的进步；但人们在软件工程的实践过程中也逐渐传统的软件生产方法太过“笨重”，难于实施，导致的直接结果是生产成本的上升，于是，人们开始寻找有别于“重量级”（heavyweight）生产模式的“轻量级”（lightweight）生产模式。所谓“轻量级”（lightweight）就是只有很少的一些规则（rule）和做法（practice）。XP 就是在这样的历史背景下在90 年代初出现的。
XP 的鼻祖是Kent Beck 。最初Kent 的希望是找到更好的软件生产方法。在思考和探索的过程中，Kent 逐渐意识到改进软件项目的四个因素。第一是改善沟通（communication），第二是寻求简单（simplicity），第三是获得反馈（feedback），第四是富有勇气（courage）。这四个因素后来成为XP 的四大价值观。
有人以为XP 只在非正规的软件项目开发中才存在，而实际上，XP 特别强调客户满意和团队合作，很多商业化的软件公司都采用XP 来开发软件项目。在XP 中，开发队伍不仅仅是编程人员，还包括管理人员和客户。但是XP 适合2-10 人的开发队伍。所以大规模的软件项目XP 不大能够胜任。
经过多年的应用和实践检验，XP 总结出了软件生产的十余条做（practice），涉及软件设计、测试、编码、发布等各个环节。
虽然XP 的这些价值观和做法可以逐条的讲述，但唯有将所有这些融为一个整体，才能真正领悟XP 的思想，才能应用XP 从容面对不断变化的客户需求。g
PMT 版权所有 2001 emag@pmt sol uti on. net
XP 入门（1 ）
Rye hyt002@263.net
第一章 XP 总体介绍
译自：website ：http://www.extremeprogramming.org/
在这一章中，我们将回答一些XP 方法的疑问。
首先我们看XP 项目流程图：
接着，让我们来回答第一个问题：什么是XP ？
第一个问题：什么是XP
XP 实际上是一种经历过很多实践考验的一种软件开发的方法，它诞生了大概有5 年，它已经被成功的应用在许多大型的公司，如：Bayeris che Landesbank , Credit Swis s Life,DaimlerChrysler, First Union National Bank, Ford Motor Company and UBS.
XP 的成功得益于它对客户满意度的特别强调，XP 是以开发符合客户需要的软件为目标而产生的一种方法论，XP 使开发者能够更有效的响应客户的需求变化，哪怕在软件生命周期的后期。
同时，XP 也很强调团队合作。团队包括：项目经理，客户，开发者。他们团结在一起来保证高质量的软件。XP 其实是一种保证成功的团队开发的简单而有效的方法。
XP 强调四种价值：交流，简易，回馈，勇气。XP 程序员之间紧密的相互交流，XP 程序员也和客户紧密的交流。他们总是保持他们的设计简单明了。项目一开始，XP 就强调通过对软件的不断测试来获得反馈，程序员尽可能早的把软件交给客户，并实现客户对软件需求提出的变化，有了这些基础，XP 程序员就可以自信的面对需求和软件技术的变化。
XP 是与众不同的，它有点象快步的舞蹈。XP 开发过程包括许多的小卡片，独立的看，这些小卡片没有什么意义，但是当它们组合在一起，一幅完整的美丽的图片就可以看见，XP方法有别于传统软件开发，它是软件开发的一种新的重要的发展。它改变了我们开发程序的传统思维方式。下面我们将介绍它带给我们那些改变。
第二问题：XP 带给我们的变化
通过软件工程设计的简单而优美的软件并不比那些设计复杂而难以维护的软件有价值。
这是真的吗？XP 认为事实并非如此。
一个典型的项目花在人力上的金钱是花在硬件上的时间的20 倍，这意味着一个项目每年要花200 万美元在程序员身上，而仅仅花10 万美元在电脑设备上。很多聪明的程序员说；“我们如此聪明，发现一种方法可以节省20%的硬件开销”，然后他们使得源程序大而且难懂和难以维护，他们会说：“但是我们节省了20%或者2 万美元每年，很大的节省”。反之，如果我们写我们的程序简单而且容易扩展，我们将至少节省10%的人力开销，一笔更大的节省，这是你客户一定会注意到的一些事情。
另外一个对客户来说很重要的问题就是程序的BUGS 。XP 不只是强调测试，而且要求正确的测试。测试必须是能自动进行的，以便为程序和客户提供一个安全的环境。在编码的所有阶段，我们不断增加测试用例。当找到bug 时，我们就添加新的测试，一个紧密的安全网就这样产生了。同一个BUG 不出现两次，这些一定会引起用户的注意。
你的客户必须注意的另外一件事情：XP 开发者拥抱需求变化。XP 使我们能够接受需求的变化。
一般情况下，客户只有在系统被开发完成以后能真正去体会它。XP 却不一样，它通过加强客户的反馈来缩短开发的周期，同时获得足够的时间来改变功能和获得用户的认同。在XP 中，你的客户应该明确的知道这一点。
XP 开发过程的大多的革命是在软件开发的方法上，代码质量的重要程度超出人们一般所认为的。仅仅因为我们的客户不能明白我们的源代码并不意味着我们可以不努力去管理代码的质量。
第三个问题：我们什么时候用XP
XP 方法的产生是因为难以管理的需求变化，从一开始你的客户并不是很完全的知道他们要的系统是怎么样的，你可能面对的系统的功能一个月变化多次。在大多数软件开发环境中不断变化的需求是唯一的不变，这个时候应用XP 就可以取得别的方法不可能取得的成功。XP 方法的建立同时也是为了解决软件开发项目中的风险问题。假如你的客户在特定的时间内，需要一个相当难开发的系统，而且对于你的项目组来说，这个系统是一个新的挑战（从来没有做过），那风险就更大了，如果这个系统对于整个软件行业来说都是新的挑战，那么它的风险就更大了，采用XP 将可以减少风险，增加成功的可能。
XP 方法是为小团体开发建立的，在2-10 个人之间。假如你的团体恰好合适，你就不需要用其他的软件工程方法了，就用XP ，但是要注意你不能将XP 方法应用于大团体的开发项目中。我们应该注意，在需求一惯呈动态变化或者高具有高风险的项目中，你就会发现XP 方法在小团体的开发中的作用要远远高于在大团体的开发。
XP 方法需要一个扩展的开发团体，XP 团体不仅仅包括开发者，经理、客户也是其中的一员，所有的工作一环扣一环，问问题，商讨方法和日程，增加功能测试，这些问题的解决不仅仅涉及到软件的开发者。
另一个需要是可测试性，你必须能增加自动的单元测试和功能测试，然而在你进行这个需求的时候，你会发现有许多的问题很难测试，这需要充分发挥你的测试的经验和智慧，而且你有时还要改变你的设计以便它可以更容易的进行测试。记住：那儿有需求，那儿就应该有测试的方法。
在XP 方法的好处的清单上，最后一条是生产力。在同样的合作环境下，XP 项目都一致的表现出比使用其他方法高的多的生产力。但这从来不是XP 方法学的真正目标。XP 真实追求的目标是：在规定的时间生产出满足客户需要的软件。 假如对于你的开发来说，这是很重要的方面，你就可以选择XP 了。
在这一章我们回答了XP 的一些疑问，在下一章我们将开始介绍XP 的一些基本的规则和实践经验。
xxn_xxn 2001-07-11
- 打赏
- 举报
其实就是《xpexplore》上摘的一段，能不能再贴点东西，大家共享啊？翻译的意思我明白了，谢谢！
我先贴原文：） 的一部分。 （主要是英文水平不够，看着有点吃力。）
Section 2: Practices.58.Chapter 4 What are XP’s team
practices?
We’ll explore these practices and their alternatives.
Code Ownership: Who can change an object that needs to
change?
Integration: How and when does a team ensure everybody's
code works together?
Overtime: What do you do when you run out of time?
Workspace: How should a team be physically arranged?
Release Schedule: How often should a team release their prod-uct?
Coding Standard: How should the code be written?
These are “ team” practices because it’s no use trying to do
them alone; it does no good to be the only person integrating
often or the only one following a coding standard..60
Code Ownership
When code needs to be changed, who gets to (or has to!)
change it?
Nobody (“Orphan”)
In some groups, nobody owns the code. For closed-source sys-tems,
maintained by a third party, “ nobody” just means “ nobody
here.” There are other programs that are untouchables: there’s
no source code (it was lost years ago), or the system is too brittle
or too complicated to safely change.
When code isn’t owned, developers will either design around it
or treat it as a black box. That latter approach can be especially
painful: the programmer has to format data going in and out;
they may have to mediate between two paradigms (e.g., using
screen-scraping technology); they may be unable to do things
you would normally expect to be possible; there may be data
denormalization and coordination problems because information
has to be stored both inside and outside the system.
Avoid the situation of “ nobody owns it (and nobody wants
to).”
Last One Who Touched It (“ Tag” or “ Musical Chairs” ); and
Whoever's Newest (“ Trial by Fire” )
You may have systems that are reasonably stable, but still a pain
to maintain. In these situations, there’s typically a local cultural
rule that kicks in: whoever touched it last owns the next problem
(which can make it frustratingly hard to escape), or perhaps the
problem is given to the least powerful person (often with the
instructions, “ just make it work” ).
This model seems very common in maintenance organizations.
One Owner Per Class (or Package) (“ Monogamy” )
This approach is very common in new development: the author
owns the code they write, until somebody explicitly takes it over..61
The key is that there’s a well-defined person in charge of a sec-tion
of code. If you want it changed, you negotiate with them.
They may even let you change it yourself, but they’ll retain
approval rights on what you do. Sometimes the ownership will go
stale: the person who did one part is gone, and it’s not actively
changing, so there won’t be a real owner until someone needs
something done, the team will assign an owner when it needs to.
The benefit of this approach is that it provides a well-defined
method for deciding who does what work, and it lets a person
develop expertise in a particular area.
There are downsides, though. If the owner isn’t available to
make a change when needed, the team is slowed down. (Some
teams mitigate this by having emergency backups.) Sometimes
the owner won’t agree with a proposed change, perhaps com-pletely
vetoing it. Then clients may design around it or wrapper it
in a way that is worse for the system overall. Another problem is
that a single owner can be in trouble and hide the fact. (The code
may be deeply in trouble by the time their lack of expertise is
noticed.)
The single-owner approach can require that interfaces be fro-zen
too early, before they’re really understood, because of the
need to let clients “ make progress.” Refactoring can be more dif-ficult;
when interfaces are public and require a lot of cooperation
to change, there is political pressure not to change them (even if
they need it).
Sequential Owners (“ Rental Property” or “ Serial Monog-amy”
)
Some groups have a single owner for a package at any given
time, but that owner will be decided on a task-by-task or itera-tion-
by-iteration basis.
This can be good in that it gives people variety, but they may
not get a chance to build deep enough expertise to be particularly
effective. But at least there’s an owner, so everybody knows who
to talk to..62
The biggest problem is that the code is like rental property: the
current “ owner” is really a “ tenant” ; they know the situation is
temporary, so they have less incentive to worry about the long-term
value of the place (provided they can get out of their lease
before it gets too bad).
Ownership by Layer (“ Tribalism” )
Some groups organize their software into distinct layers, or
even distinct applications, and have ownership at that level. Any-body
in the tribe can make any change they need to— but they
keep the tribe informed about what they’re doing. However,
nobody from another layer would dare to jump in. (You see this
with user interface vs. business logic vs. database, or application 1
vs. application 2 vs. database.)
This method overcomes some flaws of “ monogamy” : the “ bus
number” is higher, there’s no chance bad code will be hidden
from the sub-team, etc. (The “ bus number” is the number of
people that, if they were hit by a bus, would cause the project to
fail.) The subteams can develop a very strong esprit de corps,
which further boosts their productivity.
However, interfaces between layers are elevated to near
“ golden” status, making them even harder to change. This inter-feres
with refactoring intended to improve the overall system
design.
Communication within the subteam is usually good, but it's
harder to talk across layers. A change that requires convincing
one person in the “ one owner” model now requires “ How about
our subteams meet and discuss this; is everybody open next
week?” This slows down the team as whole.
Collective Code Ownership (“ Everybody” )
In collective ownership, the whole team owns all code. Any-body
can change any part they need to.
The key benefit of this approach is that it is the least obstructive
to getting things done quickly. The ability to refactor is.63
improved, as there are fewer published interfaces. For the right
team, this can be an effective mode. (See the next section, which
describes how XP tries to retain its benefits without falling victim
to its risks.)
There are potential downsides as well:
.Some people take personal pride in their code, and don’t want
others to touch it.
.You risk the tragedy of the commons: “ everybody is responsible”
can come to mean “ nobody is responsible.”
.This resembles “ musical chairs” carried even further, perhaps
aggravating the risk that nobody will be expert enough, and that
nobody will care for the long-term value.
.It can be hard to read and work with someone else’s code. You
may get a mish-mash of styles and approaches.
.People may step on each others’ toes more, as they need access to
the same objects.
XP Uses Collective Code Ownership
Extreme Programming recognizes the risks in collective code
ownership, but uses it anyway. XP’s practices attempt to mitigate
these risks:
.Personal pride: XP doesn’t really address this, other than perhaps
encouraging a shift to pride at the team level.
.“ Tragedy of the Commons” : Pair programming, and unit tests
running at 100%, help ensure that no person can “ pollute” in
secrecy. The shuffling of pairs helps make all code visible to the
whole team. Refactoring can clean up any trouble that does occur.
.Not enough expertise: Pair programming spreads knowledge
through the team. The open workspace gives others a chance to
speak up when one pair seems stuck or worried. Simple design can
require less “ deep” expertise. Finally, tests help ensure that func-tionality
won't diverge from the requirements.
.Reading others’ code: A coding standard helps reduce this prob-lem,
as does the shared culture that pair programming engenders..64
.Stepping on toes: Continuous integration ensures that people
won’t go far without rejoining the main line. The tests ensure that
there is no regression.
Integration
How and when does a team ensure everybody's code works
together?
Just before delivery
Some groups I’ve worked with have typically had developers
working in private areas, picking up what they need from others
as they need it. Before delivery, there’s an attempt to do a “ code
freeze” (usually a “ code slush” at that point): everybody makes
sure everything is checked in, and they resolve any conflicts due
to changing interfaces (especially those that obviously break the
compile). (This is similar to annealing in metallurgy: at first
there’s a lot of activity, and as the temperature is lowered, every-thing
settles into a low energy state.)
The big problem with this approach is that it lets people go off
in drastically wrong directions, with nothing forcing them to test
(or even integrate) for days or weeks. The integration process
becomes a lot of work for whoever must resolve all the problems.
Daily Builds
One way forward is to go to daily builds. Every night, the sys-tem
is compiled, and a “ smoke test” is run.
The developer’s motto becomes “ Don’t break the build.”
Developers are supposed to do their own integration testing as
they check in, so there should be no surprises. (The groups I’ve
been in with this process had a project manager who actively
checked that people were checking in as they finished tasks.)
Groups evolve different mechanisms to deal with the code
breaking. I’ve heard of groups that say “ Whoever breaks the
build must be in by 8:00 each day to check the latest build (until
somebody new breaks it).” One group I was in relied on peer.65
pressure by publicizing who broke the build. Eventually the team
hired a configuration manager who had a set start time each day,
and whose first responsibility of the day was to identify any com-pilation
or integration problems, and get the relevant program-mer(
s) to fix them.
Continuous Integration
Continuous integration, as XP uses, is not literally continuous,
but it does occur several times per day. Each time a developer
(pair) finishes a work session, they integrate what they have done.
Typically, there’s a single machine for the team’s integration
efforts, so it’s serialized “ first-come, first-serve.”
Integration in XP is supported by tests. Developers must keep
all unit tests running at 100%. To integrate, they take their code
to a machine already running at 100%. After they’ve integrated: if
the tests are still at 100%, they’re done. If not, only one thing has
changed: the code they introduced. They’re obligated to fix the
code (perhaps with help from others), or back out the changes
and throw them away. They’re not permitted to leave the integra-tion
system in a deteriorated state.
Continuous integration is possible in XP because of the
“ togetherness” of the group, because it’s supported by tests, and
because XP provides for simpler design via refactoring.
Overtime
What do you do when you run out of time?
Work overtime
For many teams, overtime is their first response to a schedule
crunch. First, the team’s hours start to stretch, then the team is
asked to work weekends. Some groups go so far as to have man-datory
overtime.
This path can be counter-productive. The job can turn into a
“ death march” (in Yourdon’s phrase). People find themselves.66
working at less capacity because they’re too tired to think
straight. Or, it takes a toll on their family life, or they put in the
hours physically but not mentally.
40-Hour Week
XP pushes a different view, saying that a 40-hour week is more
appropriate (for some value of 40). XP teams realize there may be
an occasional long week, but that even two weeks of overtime in
a row is a sign of other problems. What does “ 40” mean? It
doesn’t mean exactly 40; for some people it will be 35, for others
45, etc. “ 40” puts a number out, to say, “ there is a limit.”
XP teams want a sustainable level of productivity. If the team
can’t do all they promised in an iteration, they hand back stories.
The “ Yesterday’s Weather” rule ensures that next iteration is bet-ter
balanced to the team’s productivity level. (“ Yesterday’s
Weather” says to estimate that next iteration will accomplish
about as many days work as this one did.) If a team is doing 2- or
3-week iterations, and it requires overtime to finish the promised
tasks for this iteration, odds are good it would take overtime next
iteration as well. It’s better to figure out the team’s natural pace.
My manager, Steve Metsker, says, “ A professional should be
willing to spend 5 hours a week (outside of work) improving
themselves.” There are XP teams that reserve 1/2 day a week as
“ play time” (where members can do things like learn a new pro-gramming
language). This uncommitted time pays off in the
main work week.
In Planning Extreme Programming, Kent Beck has a great story
about a team that moved from thinking “ We don’t have enough
time” to “ We have too much to do.” He points out that the shift
is empowering: you can’t do anything about time, but you can do
something about your tasks.
Workspaces
How should a team be organized physically?.67
Geographically Separate (Including Telecommuting)
Geographically separate groups are based in different locations,
and face the communication difficulties that implies. For exam-ple,
there may be differences in language (in the worst case) and
differences in time zone. Even groups nominally in the same time
zone can evolve different hours: I worked with a group where
one site tended to get in between 8:00 and 9:00, and the other
group around 10-10:30. With varying lunch and departure
schedules, the core hours were 10:30-11:30 and 1:30-4:00.
Communication problems can make this approach more costly,
even though it appears cheaper on the surface. (“ We can hire the
best people from both locations,” “ We’ll start another site where
it’s cheaper to hire.” ) There are travel costs as well as communi-cation
costs (including resentment from those who travel). Most
groups must co-locate once in a while. (I know of an interna-tional
group that felt that things fell apart if they didn’t meet at
least quarterly.)
Telecommuting takes the case of separate workspaces to the
extreme, breeding more communication difficulty, more isola-tion,
and a perception of less opportunity for advancement. If
tasks can be split in a way to minimize the need for communica-tion,
telecommuting may be a welcome approach. I haven’t
known any developers to stick with it for more than a year or so,
though.
Offices (1- or 2-Person)
Offices offer the greatest level of privacy and quiet to the devel-oper.
In Peopleware, DeMarco and Lister reported that those
with offices did the best in their “ coding wars,” which they
attributed to the need for programmers to reach a state of “ flow.”
Offices are apparently the most expensive choice, because few
companies seem willing to provide them for developers. (I’ve
found a 2-person office to be far more productive than a cubicle.).68
Cubicles
“ Cubes” seem to be the form of office least liked by developers
and most liked by the managers who put them there.
Companies I’ve worked with seem to be making them smaller:
ten years ago, the standard size was 100 square feet (including for
the president of the company); today (at a smaller, different com-pany),
the standard is 54 square feet (and I’m bigger than I was
then!). My current cubicle doesn’t allow for two people at the
desk, and even if it did, the computer doesn’t fit anywhere but
the corner.
Cubes also seem to get smaller only, never bigger. A friend of
mine worked for a company that would have occasional “ moving
weekends” : you’d pack up all your stuff, and return Monday to
the same office only 6” smaller. By gaining 6” per cube across a
football-field-sized room, they could add even more cubicles.
Cubes don’t allow much privacy or quiet, but they still interfere
with communication. (I’ve seen wall heights anywhere from 4 to
8 feet, but they always seem to be open on top and never have a
door.)
Open Workspace
XP specifies an open workspace, usually with small private
spaces around a central area. The fast machines are in the center,
for pairing. XP would like the team to hit a state where program-mers
can focus on their problem, but still hear enough to jump in
if they can help.
The same physical structure without an XP focus can degener-ate
into a “ bullpen” : you’re all stuffed into the same space (with
no private space). You aren’t on the same project or phase, so the
rhythms of your communication clash with those of others. The
bullpen has been the worst office type I’ve been in.
Some groups starting toward XP also take smaller steps toward
open workspace, by arranging for pairing machines in a spare
niche, or treating a wing of cubes as a public area. Beware that.69
some places have “ hot” walls: the cubicle walls are dangerous to
move as they’re wired for electricity.
Release Schedule: Small Releases
How often should a team release their product? XP pushes for
small but frequent releases. An XP team is trying to learn, and the
more feedback they get (especially from actual use), the better.
Projects that don’t release for months, or even years, accumulate
a lot of risk: technology will change, the business environment
will change, the team will change. Small releases reduce this risk.
A release should be small, but it needs to make sense: only
whole features should be included. The first release needs at least
primitive versions of all major components or subsystems.
Failing to meet the goal of having small releases is the biggest
mistake I’ve made in developing systems. When I focus on it, I
find that “ small” can be even smaller than I would have thought.
I’ve resolved to start every project with this question: “ Will this
interface work?” (Mimic pushing the button with your nose or
forehead.)
Do It!.70
The answer is often “ yes, if you knew these parameters.” In
that case we can start without a GUI. Where this interface isn’t
enough, it can get us focused on understanding what is the mini-mal
useful system. (I’ve also found that it can be the developers
who resist starting small; they have the vision of what the system
could be and hate to back off from there.)
In the first XP immersion class, Michael Hill described his prac-tice
of producing a ZFR (“ ziffer” ) - Zero Feature Release. It was
an end-to-end release that did nothing, but it established the
architecture and the deployment strategy in the first iteration. It’s
hard to get a system into production the first time; updating it is
usually a lot easier.
我先贴原文：） 的一部分。 （主要是英文水平不够，看着有点吃力。）
Section 2: Practices.58.Chapter 4 What are XP’s team
practices?
We’ll explore these practices and their alternatives.
Code Ownership: Who can change an object that needs to
change?
Integration: How and when does a team ensure everybody's
code works together?
Overtime: What do you do when you run out of time?
Workspace: How should a team be physically arranged?
Release Schedule: How often should a team release their prod-uct?
Coding Standard: How should the code be written?
These are “ team” practices because it’s no use trying to do
them alone; it does no good to be the only person integrating
often or the only one following a coding standard..60
Code Ownership
When code needs to be changed, who gets to (or has to!)
change it?
Nobody (“Orphan”)
In some groups, nobody owns the code. For closed-source sys-tems,
maintained by a third party, “ nobody” just means “ nobody
here.” There are other programs that are untouchables: there’s
no source code (it was lost years ago), or the system is too brittle
or too complicated to safely change.
When code isn’t owned, developers will either design around it
or treat it as a black box. That latter approach can be especially
painful: the programmer has to format data going in and out;
they may have to mediate between two paradigms (e.g., using
screen-scraping technology); they may be unable to do things
you would normally expect to be possible; there may be data
denormalization and coordination problems because information
has to be stored both inside and outside the system.
Avoid the situation of “ nobody owns it (and nobody wants
to).”
Last One Who Touched It (“ Tag” or “ Musical Chairs” ); and
Whoever's Newest (“ Trial by Fire” )
You may have systems that are reasonably stable, but still a pain
to maintain. In these situations, there’s typically a local cultural
rule that kicks in: whoever touched it last owns the next problem
(which can make it frustratingly hard to escape), or perhaps the
problem is given to the least powerful person (often with the
instructions, “ just make it work” ).
This model seems very common in maintenance organizations.
One Owner Per Class (or Package) (“ Monogamy” )
This approach is very common in new development: the author
owns the code they write, until somebody explicitly takes it over..61
The key is that there’s a well-defined person in charge of a sec-tion
of code. If you want it changed, you negotiate with them.
They may even let you change it yourself, but they’ll retain
approval rights on what you do. Sometimes the ownership will go
stale: the person who did one part is gone, and it’s not actively
changing, so there won’t be a real owner until someone needs
something done, the team will assign an owner when it needs to.
The benefit of this approach is that it provides a well-defined
method for deciding who does what work, and it lets a person
develop expertise in a particular area.
There are downsides, though. If the owner isn’t available to
make a change when needed, the team is slowed down. (Some
teams mitigate this by having emergency backups.) Sometimes
the owner won’t agree with a proposed change, perhaps com-pletely
vetoing it. Then clients may design around it or wrapper it
in a way that is worse for the system overall. Another problem is
that a single owner can be in trouble and hide the fact. (The code
may be deeply in trouble by the time their lack of expertise is
noticed.)
The single-owner approach can require that interfaces be fro-zen
too early, before they’re really understood, because of the
need to let clients “ make progress.” Refactoring can be more dif-ficult;
when interfaces are public and require a lot of cooperation
to change, there is political pressure not to change them (even if
they need it).
Sequential Owners (“ Rental Property” or “ Serial Monog-amy”
)
Some groups have a single owner for a package at any given
time, but that owner will be decided on a task-by-task or itera-tion-
by-iteration basis.
This can be good in that it gives people variety, but they may
not get a chance to build deep enough expertise to be particularly
effective. But at least there’s an owner, so everybody knows who
to talk to..62
The biggest problem is that the code is like rental property: the
current “ owner” is really a “ tenant” ; they know the situation is
temporary, so they have less incentive to worry about the long-term
value of the place (provided they can get out of their lease
before it gets too bad).
Ownership by Layer (“ Tribalism” )
Some groups organize their software into distinct layers, or
even distinct applications, and have ownership at that level. Any-body
in the tribe can make any change they need to— but they
keep the tribe informed about what they’re doing. However,
nobody from another layer would dare to jump in. (You see this
with user interface vs. business logic vs. database, or application 1
vs. application 2 vs. database.)
This method overcomes some flaws of “ monogamy” : the “ bus
number” is higher, there’s no chance bad code will be hidden
from the sub-team, etc. (The “ bus number” is the number of
people that, if they were hit by a bus, would cause the project to
fail.) The subteams can develop a very strong esprit de corps,
which further boosts their productivity.
However, interfaces between layers are elevated to near
“ golden” status, making them even harder to change. This inter-feres
with refactoring intended to improve the overall system
design.
Communication within the subteam is usually good, but it's
harder to talk across layers. A change that requires convincing
one person in the “ one owner” model now requires “ How about
our subteams meet and discuss this; is everybody open next
week?” This slows down the team as whole.
Collective Code Ownership (“ Everybody” )
In collective ownership, the whole team owns all code. Any-body
can change any part they need to.
The key benefit of this approach is that it is the least obstructive
to getting things done quickly. The ability to refactor is.63
improved, as there are fewer published interfaces. For the right
team, this can be an effective mode. (See the next section, which
describes how XP tries to retain its benefits without falling victim
to its risks.)
There are potential downsides as well:
.Some people take personal pride in their code, and don’t want
others to touch it.
.You risk the tragedy of the commons: “ everybody is responsible”
can come to mean “ nobody is responsible.”
.This resembles “ musical chairs” carried even further, perhaps
aggravating the risk that nobody will be expert enough, and that
nobody will care for the long-term value.
.It can be hard to read and work with someone else’s code. You
may get a mish-mash of styles and approaches.
.People may step on each others’ toes more, as they need access to
the same objects.
XP Uses Collective Code Ownership
Extreme Programming recognizes the risks in collective code
ownership, but uses it anyway. XP’s practices attempt to mitigate
these risks:
.Personal pride: XP doesn’t really address this, other than perhaps
encouraging a shift to pride at the team level.
.“ Tragedy of the Commons” : Pair programming, and unit tests
running at 100%, help ensure that no person can “ pollute” in
secrecy. The shuffling of pairs helps make all code visible to the
whole team. Refactoring can clean up any trouble that does occur.
.Not enough expertise: Pair programming spreads knowledge
through the team. The open workspace gives others a chance to
speak up when one pair seems stuck or worried. Simple design can
require less “ deep” expertise. Finally, tests help ensure that func-tionality
won't diverge from the requirements.
.Reading others’ code: A coding standard helps reduce this prob-lem,
as does the shared culture that pair programming engenders..64
.Stepping on toes: Continuous integration ensures that people
won’t go far without rejoining the main line. The tests ensure that
there is no regression.
Integration
How and when does a team ensure everybody's code works
together?
Just before delivery
Some groups I’ve worked with have typically had developers
working in private areas, picking up what they need from others
as they need it. Before delivery, there’s an attempt to do a “ code
freeze” (usually a “ code slush” at that point): everybody makes
sure everything is checked in, and they resolve any conflicts due
to changing interfaces (especially those that obviously break the
compile). (This is similar to annealing in metallurgy: at first
there’s a lot of activity, and as the temperature is lowered, every-thing
settles into a low energy state.)
The big problem with this approach is that it lets people go off
in drastically wrong directions, with nothing forcing them to test
(or even integrate) for days or weeks. The integration process
becomes a lot of work for whoever must resolve all the problems.
Daily Builds
One way forward is to go to daily builds. Every night, the sys-tem
is compiled, and a “ smoke test” is run.
The developer’s motto becomes “ Don’t break the build.”
Developers are supposed to do their own integration testing as
they check in, so there should be no surprises. (The groups I’ve
been in with this process had a project manager who actively
checked that people were checking in as they finished tasks.)
Groups evolve different mechanisms to deal with the code
breaking. I’ve heard of groups that say “ Whoever breaks the
build must be in by 8:00 each day to check the latest build (until
somebody new breaks it).” One group I was in relied on peer.65
pressure by publicizing who broke the build. Eventually the team
hired a configuration manager who had a set start time each day,
and whose first responsibility of the day was to identify any com-pilation
or integration problems, and get the relevant program-mer(
s) to fix them.
Continuous Integration
Continuous integration, as XP uses, is not literally continuous,
but it does occur several times per day. Each time a developer
(pair) finishes a work session, they integrate what they have done.
Typically, there’s a single machine for the team’s integration
efforts, so it’s serialized “ first-come, first-serve.”
Integration in XP is supported by tests. Developers must keep
all unit tests running at 100%. To integrate, they take their code
to a machine already running at 100%. After they’ve integrated: if
the tests are still at 100%, they’re done. If not, only one thing has
changed: the code they introduced. They’re obligated to fix the
code (perhaps with help from others), or back out the changes
and throw them away. They’re not permitted to leave the integra-tion
system in a deteriorated state.
Continuous integration is possible in XP because of the
“ togetherness” of the group, because it’s supported by tests, and
because XP provides for simpler design via refactoring.
Overtime
What do you do when you run out of time?
Work overtime
For many teams, overtime is their first response to a schedule
crunch. First, the team’s hours start to stretch, then the team is
asked to work weekends. Some groups go so far as to have man-datory
overtime.
This path can be counter-productive. The job can turn into a
“ death march” (in Yourdon’s phrase). People find themselves.66
working at less capacity because they’re too tired to think
straight. Or, it takes a toll on their family life, or they put in the
hours physically but not mentally.
40-Hour Week
XP pushes a different view, saying that a 40-hour week is more
appropriate (for some value of 40). XP teams realize there may be
an occasional long week, but that even two weeks of overtime in
a row is a sign of other problems. What does “ 40” mean? It
doesn’t mean exactly 40; for some people it will be 35, for others
45, etc. “ 40” puts a number out, to say, “ there is a limit.”
XP teams want a sustainable level of productivity. If the team
can’t do all they promised in an iteration, they hand back stories.
The “ Yesterday’s Weather” rule ensures that next iteration is bet-ter
balanced to the team’s productivity level. (“ Yesterday’s
Weather” says to estimate that next iteration will accomplish
about as many days work as this one did.) If a team is doing 2- or
3-week iterations, and it requires overtime to finish the promised
tasks for this iteration, odds are good it would take overtime next
iteration as well. It’s better to figure out the team’s natural pace.
My manager, Steve Metsker, says, “ A professional should be
willing to spend 5 hours a week (outside of work) improving
themselves.” There are XP teams that reserve 1/2 day a week as
“ play time” (where members can do things like learn a new pro-gramming
language). This uncommitted time pays off in the
main work week.
In Planning Extreme Programming, Kent Beck has a great story
about a team that moved from thinking “ We don’t have enough
time” to “ We have too much to do.” He points out that the shift
is empowering: you can’t do anything about time, but you can do
something about your tasks.
Workspaces
How should a team be organized physically?.67
Geographically Separate (Including Telecommuting)
Geographically separate groups are based in different locations,
and face the communication difficulties that implies. For exam-ple,
there may be differences in language (in the worst case) and
differences in time zone. Even groups nominally in the same time
zone can evolve different hours: I worked with a group where
one site tended to get in between 8:00 and 9:00, and the other
group around 10-10:30. With varying lunch and departure
schedules, the core hours were 10:30-11:30 and 1:30-4:00.
Communication problems can make this approach more costly,
even though it appears cheaper on the surface. (“ We can hire the
best people from both locations,” “ We’ll start another site where
it’s cheaper to hire.” ) There are travel costs as well as communi-cation
costs (including resentment from those who travel). Most
groups must co-locate once in a while. (I know of an interna-tional
group that felt that things fell apart if they didn’t meet at
least quarterly.)
Telecommuting takes the case of separate workspaces to the
extreme, breeding more communication difficulty, more isola-tion,
and a perception of less opportunity for advancement. If
tasks can be split in a way to minimize the need for communica-tion,
telecommuting may be a welcome approach. I haven’t
known any developers to stick with it for more than a year or so,
though.
Offices (1- or 2-Person)
Offices offer the greatest level of privacy and quiet to the devel-oper.
In Peopleware, DeMarco and Lister reported that those
with offices did the best in their “ coding wars,” which they
attributed to the need for programmers to reach a state of “ flow.”
Offices are apparently the most expensive choice, because few
companies seem willing to provide them for developers. (I’ve
found a 2-person office to be far more productive than a cubicle.).68
Cubicles
“ Cubes” seem to be the form of office least liked by developers
and most liked by the managers who put them there.
Companies I’ve worked with seem to be making them smaller:
ten years ago, the standard size was 100 square feet (including for
the president of the company); today (at a smaller, different com-pany),
the standard is 54 square feet (and I’m bigger than I was
then!). My current cubicle doesn’t allow for two people at the
desk, and even if it did, the computer doesn’t fit anywhere but
the corner.
Cubes also seem to get smaller only, never bigger. A friend of
mine worked for a company that would have occasional “ moving
weekends” : you’d pack up all your stuff, and return Monday to
the same office only 6” smaller. By gaining 6” per cube across a
football-field-sized room, they could add even more cubicles.
Cubes don’t allow much privacy or quiet, but they still interfere
with communication. (I’ve seen wall heights anywhere from 4 to
8 feet, but they always seem to be open on top and never have a
door.)
Open Workspace
XP specifies an open workspace, usually with small private
spaces around a central area. The fast machines are in the center,
for pairing. XP would like the team to hit a state where program-mers
can focus on their problem, but still hear enough to jump in
if they can help.
The same physical structure without an XP focus can degener-ate
into a “ bullpen” : you’re all stuffed into the same space (with
no private space). You aren’t on the same project or phase, so the
rhythms of your communication clash with those of others. The
bullpen has been the worst office type I’ve been in.
Some groups starting toward XP also take smaller steps toward
open workspace, by arranging for pairing machines in a spare
niche, or treating a wing of cubes as a public area. Beware that.69
some places have “ hot” walls: the cubicle walls are dangerous to
move as they’re wired for electricity.
Release Schedule: Small Releases
How often should a team release their product? XP pushes for
small but frequent releases. An XP team is trying to learn, and the
more feedback they get (especially from actual use), the better.
Projects that don’t release for months, or even years, accumulate
a lot of risk: technology will change, the business environment
will change, the team will change. Small releases reduce this risk.
A release should be small, but it needs to make sense: only
whole features should be included. The first release needs at least
primitive versions of all major components or subsystems.
Failing to meet the goal of having small releases is the biggest
mistake I’ve made in developing systems. When I focus on it, I
find that “ small” can be even smaller than I would have thought.
I’ve resolved to start every project with this question: “ Will this
interface work?” (Mimic pushing the button with your nose or
forehead.)
Do It!.70
The answer is often “ yes, if you knew these parameters.” In
that case we can start without a GUI. Where this interface isn’t
enough, it can get us focused on understanding what is the mini-mal
useful system. (I’ve also found that it can be the developers
who resist starting small; they have the vision of what the system
could be and hate to back off from there.)
In the first XP immersion class, Michael Hill described his prac-tice
of producing a ZFR (“ ziffer” ) - Zero Feature Release. It was
an end-to-end release that did nothing, but it established the
architecture and the deployment strategy in the first iteration. It’s
hard to get a system into production the first time; updating it is
usually a lot easier.
notyy 2001-07-10
- 打赏
- 举报
老兄是哪位啊。这是哪篇文章的片段？很眼熟。
“（实现一个方法前先写它的测试用例），然后编译这个测试用例，编译会失败，因为你还没有实现测试用例要测试的方法。
implement just enough to compile是说只要写足够让测试编译通过的代码就够了（也就是接口，不要真的去实现方法）（如果有必要先重构它）。
现在运行测试，并看着它失败（因为你并没有真的实现方法），现在实现被测试的方法使测试能够通过。运行测试，并看着它通过。通过重构是代码结构清晰而且符合”once and only once“原则（就是说没有冗余的代码）
从头重复
这是说XP的test driven design的。使用junit作为测试工具。
“（实现一个方法前先写它的测试用例），然后编译这个测试用例，编译会失败，因为你还没有实现测试用例要测试的方法。
implement just enough to compile是说只要写足够让测试编译通过的代码就够了（也就是接口，不要真的去实现方法）（如果有必要先重构它）。
现在运行测试，并看着它失败（因为你并没有真的实现方法），现在实现被测试的方法使测试能够通过。运行测试，并看着它通过。通过重构是代码结构清晰而且符合”once and only once“原则（就是说没有冗余的代码）
从头重复
这是说XP的test driven design的。使用junit作为测试工具。
