📄 xpisapseudomethodology.html
字号:
<head><title>Xp Isa Pseudo Methodology</title></head><body><h1><img src="logo.gif"> Xp Isa Pseudo Methodology</h1>I have used TurnObjectionsIntoScenarios<a href="http://c2.com/cgi/wiki?edit=TurnObjectionsIntoScenarios">?</a>, resulting in <a href="http://c2.com/cgi/wiki?ExtremeProgrammingChallengeTen">ExtremeProgrammingChallengeTen</a>. --<a href="KentBeck.html">KentBeck</a>
<p><a href="ExtremeProgramming.html">ExtremeProgramming</a>
<p>I've been following these threads for months now, and I just can't get over
the idea that proponents of this technique have simply given a name to poor
programming practices. It seems to be nothing more than a pseudo-methodology
to justify what a lot of programmers doing the job under bad conditions do:
given a customer with an unrealistic requirements and schedule and understaffed project, just pick a piece of the purported requirements, make a guess at what it means, start coding. Code/compile/run repeated until it seems to be free of bugs, then ship it (or commit the changes or whatever constitutes a release).
<p><em>I've updated <a href="http://c2.com/cgi/wiki?UserStory">UserStory</a> to make it a bit more obvious that the requirements are not "purported" but instead are </em>
<strong>written</strong>
<em>by customers, onto cards, which are preserved and tracked throughout the entire process.</em>
<p><em>Also please observe such pages as <a href="UnitTests.html">UnitTests</a> and <a href="FunctionalTests.html">FunctionalTests</a>, which should make it clear that a growing collection of permanent tests is used to get quite well beyond "it seems to be free of bugs".. --<a href="RonJeffries.html">RonJeffries</a></em>
<p>That's not a method, that's the software development equivalent of Ptolemy's
terribly complicated but ultimately wrong system of circles and epicycles
to explain the movements of the visible planets. It only seemed to work
as more and more complexity was added to try to explain an earth-centric
view of the universe, and it took Copernicus to knock the earth into its
proper place orbiting the sun before a real science of orbital mechanics
could evolve around the observations of Tycho and Johannes Kepler.
<p>As long as folks keep adding complexity to this thread to try to explain
a programmer-centric view of software development, then it will continue
to fail to be coherent in any meaningful sense.
<p><a href="http://c2.com/cgi/wiki?StevenNewton">StevenNewton</a>
<p><em>I'm sorry you're having difficulty getting what we're giving. Kindly review and comment upon <a href="ExtremeProcess.html">ExtremeProcess</a>, which is new. And you might find it profitable to review <a href="ExtremeProgrammingSystem.html">ExtremeProgrammingSystem</a> as well, then comment back here. Thanks. --<a href="RonJeffries.html">RonJeffries</a></em>
<p>I would find it helpful if you could be more specific about what you
object to in XP. As best I can tell from the above, you are objecting
to complexity. It isn't obvious to me that XP is more complicated than
many well-accepted and widely practiced methodologies. Am I
misunderstanding your point? --<a href="http://c2.com/cgi/wiki?MatthewWilbert">MatthewWilbert</a>
<hr>
I'm fairly new to this Extreme stuff; but what I've seen seems to coincide
with my thoughts from the first time I read about refactoring. If refactoring
becomes simpler than up-front design, then design becomes a burden.
<p>Every so often, concepts ermerge (from existing practices) that radically
simplify a field. In the early 80's, RISC replaced CISC. Now we see s/w
design methods getting increasingly complex. Perhaps, contrary to the
original comments, <a href="ExtremeProgramming.html">ExtremeProgramming</a> is doing a Copernicus to UML's Ptolemy.
<p>--<a href="http://c2.com/cgi/wiki?DaveWhipp">DaveWhipp</a>
<hr>
There are two extremes that can be contrasted with XP. First is
the bureaucratic developer, who documents everything upfront and
who has lots of meetings to resolve problems instead of just trying
it and seeing. The other is the cowboy coder, who reacts to the
current problem until none of the problems seem bad enough to keep
from shipping the system. XP is usually contrasted with the first
approach, but it is also quite different from the second. How many
cowboy coders write tests first, and how many refactor their programs
until it is perfectly clear and readable? XP is different from both
extremes.
<p>If you are having trouble telling XP apart from one extreme, it is
probably because you are on the other. People who have spent all
their life in New York City have a hard time telling Ohio from
Oklahoma.
A complete description of a method takes many volumes. I bet that
there have been 10 volumes written on UML and its associated method.
I've been periodically receiving these volumes. The books claim that
they only introduce the method, that if you want to learn the complete
Rational UML method then you have to buy a lot of other stuff that is a
lot more comprehensive than the books.
<p>XP is going to take several volumes, too. See <a href="WhosWritingAboutXp.html">WhosWritingAboutXp</a>. A few web pages to describe it seems to be enough for some people to think they get it, but not others.
<p>What makes something a real methodology and what makes it a pseudo methodology?
A real methodology doesn't have to be the best way to do something, it just
has to be a repeatable way that you can teach to somebody.
<p>-<a href="http://c2.com/cgi/wiki?RalphJohnson">RalphJohnson</a>
<p><hr>
<p>Obviously, XP works for some people, and not for others, like most things. The real question is, <em>is <a href="ExtremeProgramming.html">ExtremeProgramming</a> itself really a methodology, or just a stylistic preference that you want to justify?</em>
<p>Or perhaps an even better one is, <a href="http://c2.com/cgi/wiki?WhatIfAnythingIsaMethodology">WhatIfAnythingIsaMethodology</a>, and how does one tell a Real Methodology on from a Pseudo Methodology? Is there a hard and fast definition, or is it a vague, heuristic term, like so many others in this field? -- <a href="http://c2.com/cgi/wiki?JayOsako">JayOsako</a>
<p><hr>
The one problem I see at XP is the explicit demand for lack of code documentation. Well written code needs no additional docs. In many years of doing SW engineering I have often heard of this myth. <em>Selfdocumenting Code</em> used to be the buzzword and in reality it never worked out well. More or less an excuse for laziness. Perhabs in Smalltalk, where a method consists of only a few lines of code, this is not as bad as in C++. But one should not forget that many programmers have only mediocre abilities and for them documenting before hacking is a good way to get them to write clearer and better structured code.
<p>-- <a href="http://c2.com/cgi/wiki?ThomasFunke">ThomasFunke</a>
<p><em>I have never met a "mediocre" programmer who could document even as well as he could program. If he can't think clearly enough to express something in a precise language like C++, he probably can't express it clearly in English either. I suppose that having them documenting would keep them out of the code, but that doesn't seem to be the intent here. --<a href="RonJeffries.html">RonJeffries</a></em>
<p>There are two questions here- method-level comments and design documentation.
<p>I never said you shouldn't write method-level comments. I said you shouldn't have method comments that are totally redundant. And there is a very natural stepwise process that leads you to make nearly all method comments totally redundant.
<p>Design documentation is a tougher sell, but again I never said you shouldn't have design documentation. However, communication is the purpose of such documentation and there are better (cheaper, faster, more effective) ways to communicate. Like storytelling, the product of 20,000 years of evolution. And tests (which are even better to write before hacking than documentation). And you'd never let a mediocre programmer code alone, so the problem isn't so bad as it might otherwise be. And...
<p>It is certainly not true that there is nothing besides the code. That's too simple to possibly work. There are the tests. There are the people who understand and know how to tell stories. There is the metaphor, which everyone understands. And the code does a lot more work than you might imagine it could, besides. But never alone. That would be stupid.
<p>--<a href="KentBeck.html">KentBeck</a> (it wasn't exactly a question, so I don't mind commenting)
<p>For me, refactoring is a key element in making the code clearer. If people had tried self documenting code without refactoring, there is no chance of succeeding. The only way you could succeed is if you got it right first time and never needed to change it. --<a href="http://c2.com/cgi/wiki?MartinFowler">MartinFowler</a>
<p>XP does NOT demand that there be no code documentation. XP
lets you succeed with little code documentation. But that is the result,
not the starting point.
Yes, tests and user stories are documentation. Yes, user stories are a
form of use cases. I think Kent picked the term "user stories" because he
wanted something that didn't sound like a software term. -<a href="http://c2.com/cgi/wiki?RalphJohnson">RalphJohnson</a>
<p><hr>
<p>But no one has contradicted my assertion that this is just a codification of bad programming practices in bad environments. Ron Jeffries assertion that "Any real software development effort has not enough time, or too much to do" demonstrates that point. That's like saying that any real bridge must be too high and too long. Nor is this the same as saying it's "cowboy coding", and yes I do know a few cowboy coders that write test cases. As for complexity, I'm not asserting that there is anything inherently wrong with complexity, just that proponents of this programming style are needing to add more and more complexity to their alleged method in order to make it fit real world.
<p>Next, the problem of what is documentation. Kent asserts that story telling and tests are all the documents you need. Well, unless you write down the stories (which then become something like mutant Use Cases) then when people leave you lose the stories, just as when programmers leave you lose the ability to understand and modify code that only the programmer understands (which *is* what happens in cowboy coding) and you get to throw it out and start over again.
<p>For example, the issue of what happens when a change breaks a test because of a seemingly unrelated piece of the code, and you no longer have anyone around who knows the "story" that piece of code is supposed to tell. What you get is what I've seen time and time again -- some program that worked for a while (maybe years) now fails, and no one around remembers the reason it was written the way it was, and someone tries to fix it and no know the original design or intent, can't solve the problem that causing the new failure without some other failure cropping up.
<p>So, we are left back at the point where we have an attempt to bring a method to the madness. A "real methodology" would cure the madness, or at least bring order to chaos.
<p>Let me close by saying this will be my last comment here. It seems this thread is taking over Wiki, and I'm not sure what it has to do with patterns or objects or OO methodologies -- the topics I came to Wiki to learn more about.
<p>--<a href="http://c2.com/cgi/wiki?StevenNewton">StevenNewton</a>
<p><hr>
<em>Well, the thing is, as <a href="http://c2.com/cgi/wiki?BuckarooBanzai">BuckarooBanzai</a> says: "No matter where you go, there you are."</em>
<p>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -