extremeprogramming.html

来自「极限编程 Extream Programing」· HTML 代码 · 共 318 行 · 第 1/3 页

<li> The decisions about how to code make themselves, because of the standards you have.  For example one of our standards is &quot;Don't inline&quot;.  Ok, it means we don't have to think about whether it would be better to inline.  
<li> When using other developers' interfaces, you don't have to think too hard.  e.g., when I substantively use class Class<strong></strong>Name, I know in this organization I need a header file called Class<strong></strong>Name.hh - it's not className.hh or Class<strong></strong>Nam.hh (thank the Buddha we don't use DOS).  And I know that Class<strong></strong>Name is a type, CLASS_NAME is a macro, firstNum is an object in local scope, myFirstNum is a member object, ourNextNum is a static member, and fsLowestNumber is my idea of a file static.
</OL>
Consider also modifying your compiler to enforce the coding standards that you have, if the source is available.
<p>
1a. With <a href="UnitTests.html">UnitTests</a> you don't have to think too hard when refactoring the code - the tests will tell you if you screw up.
<p>
2. The not thinking by those who deserve <a href="http://c2.com/cgi/wiki?ParkingLotTherapy">ParkingLotTherapy</a> - more specifically those that write code without considering the consequences, or break all the rules, whether described above or otherwise (that guy who has 15 years C experience is a prime candidate)
<p>
-- <a href="http://c2.com/cgi/wiki?NickBishop">NickBishop</a>
<p>
<hr>
<p>
I like what I have read so far about <a href="ExtremeProgramming.html">ExtremeProgramming</a>.  I just wonder whether it can be assumed to be universally applicable or whether there are certain development scenarios in which it would be best not to try this form of process. -- <a href="http://c2.com/cgi/wiki?MichaelFeathers">MichaelFeathers</a>
<p>
<em>I was meeting today with another Chrysler project and one of the people asked me this question, relating back to the old days.  I found myself answering that while some of the details might change, I'd adhere to, and so on, as my technical base would support.  In short, integrating my present and past experience, I'd start by using the <a href="ExtremeProgramming.html">ExtremeProgramming</a> practices to the maximum degree possible.  As always, I'd adjust when we were too extreme. --<a href="RonJeffries.html">RonJeffries</a></em>
<p>
<em>I have been seeking to apply 'as lightweight a process, as simple a commitment, as much refactoring' increasingly, as best I know how, to a large mixture of commercial projects for over ten years.  There is still a great deal to improve and <a href="ExtremeProgramming.html">ExtremeProgramming</a> is one of the few methods/cultures/case-studies to come along that is really helping.  In my view no 'development scenario' anywhere can afford to ignore what this Smalltalk team discovered when they took development to the 'extreme'. --<a href="http://c2.com/cgi/wiki?RichardDrake">RichardDrake</a></em>
<p>
<hr>
<p>
Just a comment on what I've been reading here lately: For a long while now, I've  noticed that people program (and projects run) in two basically different ways: One I term 
<em>locally better</em>
and the other
<em>globally better</em>.
Locally better decisions make things go faster in the short run (eg writing all these test cases will take me forever!), while globally better decisions do the opposite (writing all these test cases will save us countless hours a few months down the road). Unless you have lots of experience, it's very hard to even identify which things you are doing will save you time in the long run (I'm a <a href="http://c2.com/cgi/wiki?LazyProgrammer">LazyProgrammer</a>); this is especially difficult in a team, because some things are worse for you individually, but much better for the project overall.
<p>
Does this mesh with what you guys are saying?
--<a href="http://c2.com/cgi/wiki?AnthonyLander">AnthonyLander</a>
<p>
<em>Partly yes, partly no.  For example, XP doesn't invest in building for the future (see e.g. <a href="YouArentGonnaNeedIt.html">YouArentGonnaNeedIt</a>), relying instead on the combination of tests and refactoring to evolve the system to where it really needs to go.  We hold that the tests help us to go faster now, and that refactoring helps us go faster overall.</em>
<p>
<em>I would like to say that XP takes the long view of the project, but that it doesn't invest a lot now in hope of return later.  --<a href="RonJeffries.html">RonJeffries</a></em>
<p>
Absolutely no. The trick is to do activities that all have short term payoff, so they all make sense even under stress, but whose emergent properties give good long term results. Writing all those test cases makes me go faster at the end of an hour. Of course, there are lots of combinations of short-term-payoff activities that crash and burn. --<a href="KentBeck.html">KentBeck</a> (feeling absolutist)
<p>
<em>Kent, when you are acting like a methodologist, you are thinking about the long term.  When you are acting like a coach, you are thinking long term.  It is only when you are in the heat of programming that you just think short term.  That is part of the magic of <a href="ExtremeProgramming.html">ExtremeProgramming</a>; you've designed it so that programmers can just worry about the short term and be confident that the long term will work out.  This is powerful because programmers tend to worry mostly about the short term anyway, so this way they can do what they are good at and not get into trouble later. --<a href="http://c2.com/cgi/wiki?RalphJohnson">RalphJohnson</a></em>
<p>
I didn't mean to say that all short-term decisions are bad -- though on rereading what I wrote, I suppose that I did (oops). The testing example is not quite good either. Variable naming and code formatting are better: Each programmer would be happy in the short term to do things his or her own way, but clearly there are (rapidly) diminishing returns as the code size increases.
<p>
...But it's an interesting question: Is programming a greedy process (ie do lots of good short-term decisions make for long-term benefits?) --<a href="http://c2.com/cgi/wiki?AnthonyLander">AnthonyLander</a>
<p>
<em>With my Computer Scientist hat on, I can &quot;prove&quot; that problems exist such that you can't climb the hill.  With my Real Life hat on, and it's a very old and experienced hat, I don't run into many real situations that can't be resolved quite effectively with good short-term decisions.  I can't even remember the last time.</em>
<p>
<em>In real projects, I think good short-term decisions, refactoring, and addressing risk early result in perfectly satisfactory implementations.  --<a href="RonJeffries.html">RonJeffries</a></em>
<p>
I can remember quite a few short-term oriented decisions that were bad. I can remember quite a few short-term decisions that propagated erroneous datastructures to the point where fixing them required effort - and annoyed clients and management. Why, isn't win32 the some of such decisions? (Though, since it is successful, that argument might go either way). 
<p>
And if SOME short-term decisions really ARE bad, all Xp really say &quot;make good decisions and you will succeed&quot; - thanks. Or maybe there's more.
<p>
I'll admit that many long-term decisions were bad. Indeed, the point that long term decision are more likely to bad simply because it's harder think long-term is WELL taken. Maybe, it's matter of being shamelessly greedy when you can be greedy. 
<p>
I think the schizophrenia of wiki is making me go two different ways. 
Enjoy.
<p>
--Joe Solbrig
<p>
What you mean is that with the right value system, making good short term
decisions leads to good long term results.  The problem is getting the
right value system.  
<p>
This is true outside the realm of programming, too.  I think that is the
purpose of a value system.  We need to figure out the way to live so that
when we are the middle of life we &quot;do the right thing&quot;.  When our neighbor
comes over to argue with us, we are not going to start thinking about how
this will affect our life ten years from now, but we react according to the
way we were taught, and the way we taught ourselves.  The time for reflection
is when things are quiet, and that is when we should decide to be peaceful
or to stand up for our rights.
<p>
<a href="ExtremeProgramming.html">ExtremeProgramming</a> teaches that flexibility is crucial, that you have to
preserve flexibility now.  Keeping your system flexible means that you
can add features quickly now, which has good short term results, but it
also means that you can almost certainly respond to changes in the distant
future.  But it takes a lot of education to learn how to keep systems
flexible, and how to refactor them to make them that way.  Just like it
takes a lot of education to make a child learn to do the right thing.
Some people figure it out on their own, but most learn from their parents.
In the same way, a few programmers will figure <a href="ExtremeProgramming.html">ExtremeProgramming</a> out on
their own, but most will learn it from someone else.  Probably because
they were forced into it!
<p>
-<a href="http://c2.com/cgi/wiki?RalphJohnson">RalphJohnson</a>
<p>
<em>Nicely put, Ralph.  Me 'at's off to da duke! --<a href="RonJeffries.html">RonJeffries</a></em>
<p>
Ralph, your statement that started with &quot;This is true outside the realm of programming, too&quot; up there is simply beautiful. Thank you. --<a href="http://c2.com/cgi/wiki?AnthonyLander">AnthonyLander</a>
<p>
One very attractive feature of <a href="ExtremeProgramming.html">ExtremeProgramming</a> is that it tries to ride, instead of quelling, the deepest of urges in any true programmer, namely the urge to hack. This makes XP true to its parts, the programmers, and gives it some of The <a href="http://c2.com/cgi/wiki?QualityWithoutaName">QualityWithoutaName</a> --<a href="http://c2.com/cgi/wiki?AndersChrigstrom">AndersChrigstrom</a>
<p>
I like Ralph's conclusions, but I'm not sure that &quot;<a href="ExtremeProgramming.html">ExtremeProgramming</a> teaches that flexibility is crucial&quot;. It seems to me that tenets like &quot;do the simplest thing that could possibly work&quot; don't seem likely to deliver particularly flexible software.  In fact, <a href="ExtremeProgramming.html">ExtremeProgramming</a> as I understand it says that a comprehensive test suite is a good thing because it lowers the risks in aggressive restructuring.  If that's true, then the value of flexible software is actually <em>reduced</em>.  <a href="ExtremeProgramming.html">ExtremeProgramming</a> teaches that flexibility is futile: the ability to rewrite is crucial. Is this a fair outsider's view?  I'm not sure I like it as a philosophy. --<a href="http://c2.com/cgi/wiki?DaveCleal">DaveCleal</a>
<p>
<hr>
<p>
We've left you with a misunderstanding, Dave. In fact, XP produces very flexible software, and it's not an accident.  Recall that the <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> practice has <em>two</em> parts: first, pick and implement a simple approach to the solution; 
second, <em>refactor the system</em> so that it is the simplest possible implementation (<a href="http://c2.com/cgi/wiki?OnceAndOnlyOnce">OnceAndOnlyOnce</a>) of the simple approach. It is the refactoring that leaves the system flexible.  
<p>
It is true that XP builds a system without unused potentially useful code. It is <em>not</em> true that it builds a system that's inflexible, i.e. hard to modify. Good factoring results in flexibility.  --<a href="RonJeffries.html">RonJeffries</a>
<p>
<hr>
<p>
See also <a href="http://c2.com/cgi/wiki?WhatMakesSoftwareFlexible">WhatMakesSoftwareFlexible</a>
<p>
<hr>
<p>
Aside from <a href="http://c2.com/cgi/wiki?ChryslerComprehensiveCompensation">ChryslerComprehensiveCompensation</a>, where else has XP been used successfully? What was the size and duration of the projects? What was the experience level of the developer? How did XP change to accommodate the different environment/platform/management/etc? --<a href="http://c2.com/cgi/wiki?WayneCarson">WayneCarson</a>