📄 extremeprogramming.html
字号:
<head><title>Extreme Programming</title></head><body><h1><img src="logo.gif"> Extreme Programming</h1>There are other recommended practices and rules, but these <a href="http://c2.com/cgi/wiki?ExtremeProgrammingCorePractices">ExtremeProgrammingCorePractices</a> constitute an <a href="http://c2.com/cgi/wiki?ExtremeProgrammingProject">ExtremeProgrammingProject</a>.
<p>(See the list of <a href="ExtremeProgrammingProjects.html">ExtremeProgrammingProjects</a>, and add your own.)
<p>The <em>"Extreme"</em> part refers to extreme sports in the sense that such sports combine skill and courage to accomplish what look to outsiders like impossible tasks. Extreme atheletes leave absolutely nothing to chance--they bring their bodies, minds, and equipment to the highest possible level before beginning.
<p><em>"Extreme"</em> means these practices get "turned up" to a much higher "volume" than on traditional projects. XP ignores any other practice (like <a href="BigDesignUpFront.html">BigDesignUpFront</a>) that does not appear on the list. The result is stable, productive, and very rapid because the practices support each other the more they are used together without interference. An Extreme project is typically so stable and sedate it can lead to <a href="http://c2.com/cgi/wiki?FortyHourWeek">FortyHourWeek</a><strong></strong>s without any schedule slips.
<p><hr>
[<a href="http://c2.com/cgi/wiki?EditHint">EditHint</a>: For the rest of this page holds: <a href="RefactorMercilessly.html">RefactorMercilessly</a>]
<p>"Saving the world, two programmers at a time." -- <a href="http://c2.com/cgi/wiki?JoeBergin">JoeBergin</a>
<p>The more you adopt eXtreme principles, the less "extreme" your project will feel.
<p><em>See also <a href="http://www.xProgramming.com/">http://www.xProgramming.com/</a> (supersedes <a href="http://www.armaties.com/Practices/PracLeadin.htm">http://www.armaties.com/Practices/PracLeadin.htm</a>) </em>
<p><em><a href="http://www.extremeprogramming.org">http://www.extremeprogramming.org</a></em>
<p><em><a href="http://www.xpdeveloper.com/">http://www.xpdeveloper.com/</a></em> (an XP wiki)
<p><em><a href="ExtremeProgrammingRoadmap.html">ExtremeProgrammingRoadmap</a></em>
<p><em><a href="WikiPagesAboutTransitioningToExtremeProgramming.html">WikiPagesAboutTransitioningToExtremeProgramming</a></em>
<p><em><a href="news:comp.software.extreme-programming">news:comp.software.extreme-programming</a></em>
<p><em><a href="http://www.egroups.com/group/extremeprogramming/">http://www.egroups.com/group/extremeprogramming/</a></em>
<p>Software is too damned hard to spend time on things that don't matter. So, starting over from scratch, what are we absolutely certain matters?
<OL><li> <em>Coding</em>. At the end of the day, if the program doesn't run and make money for the client, you haven't done anything.
<li> <em>Testing</em>. You have to know when you're done. The tests tell you this. If you're smart, you'll write them first so you'll know the instant you're done. Otherwise, you're stuck thinking you maybe might be done, but knowing you're probably not, but you're not sure how close you are.
<li> <em>Listening</em>. You have to learn what the problem is in the first place, then you have to learn what numbers to put in the tests. You probably won't know this yourself, so you have to get good at listening to clients- users, managers, and business people.
<li> <em>Designing</em>. You have to take what your program tells you about how it wants to be structured and feed it back into the program. Otherwise, you'll sink under the weight of your own guesses.
<p></OL><strong>L</strong>istening,
<strong>T</strong>esting,
<strong>C</strong>oding,
<strong>D</strong>esigning. That's all there is to software. Anyone who tells you different is selling something.
--<a href="KentBeck.html">KentBeck</a>
<p><hr>
<a href="http://c2.com/cgi/wiki?TopicGlossaryXp">TopicGlossaryXp</a>
<hr>
<p>Special note on Listening: we do listening in two ways:
<OL><li> <em>Stories</em>. (Similar to "use cases".) On cards, our customers write stories describing how something is supposed to work. A story might say "An employee making $10 an hour works four hours of overtime on Friday and two on Sunday. She should receive $60 for the Friday overtime and $40 for Sunday." We have hundreds of cards describing the product.
<li> <em>Functional Tests.</em> These are typically single use cases with expected answers provided by the customer.
</OL>-- <a href="RonJeffries.html">RonJeffries</a>
<p>I have my doubts if the CTLR will be enough to make delighted customers. I learned in every project that Listening is far from sufficient to learn the needs and expectations of customers. They may not know what they want, or describe the paper-way-of-working or omit all things they consider obvious. In the worst case they describe an espoused system, not the system in use.
This CTLR approach may work for some well known domains (payroll?) but will fail on less beaten tracks, I fear.
-- <a href="http://c2.com/cgi/wiki?MartineDevos">MartineDevos</a>
<p>Part of <a href="ExtremeProgramming.html">ExtremeProgramming</a> is a careful balance of political power between the developers and the client. The story gathering process is certainly not, "Well, User, what do you want the system to do?" There's a lot more structure and ritual to it, some of which I don't understand well enough to write about.
<p>Requirements is a dialog, not a document. Also, programmers should make technical decisions, and business people should make business decisions. You will eventually get in trouble if this isn't true. Finally, if you think a big payroll system is well understood, I would wager good Swiss money that you haven't built one.
-- <a href="KentBeck.html">KentBeck</a>
<p>The requirements document isn't a goal; it is a side-effect of the requirements process. In some organizations it is an essential side-effect. When Fred Bigwig roars, "Why are all the buttons pea-green?", it is helpful to be able to say "Because you ordered pea-green buttons on April 29th." People do forget what they asked for, and do make contradictory requests. Requirements documents can guard against the first problem and highlight the second problem.
--<a href="http://c2.com/cgi/wiki?BetsyHanesPerry">BetsyHanesPerry</a>
<p>In organizations which take requirements documents and adherence to same seriously but where the requirements for addons are changing frequently, one should look at the <a href="http://c2.com/cgi/wiki?ScrumMethodology">ScrumMethodology</a>. It is a highly structured method which
can be very successful. --<a href="http://c2.com/cgi/wiki?MarkSwanson">MarkSwanson</a>
<p><hr>
<p><p>I think <a href="ExtremeProgramming.html">ExtremeProgramming</a> is a serious methodology, which I have been citing to the people around me. I would think it would be a mistake to give it a euphemism for a name if anyone were to do that. If it takes unnecessary damage from its extreme name, then give it an unapologetic natural name to indicate it really is the natural way of working. The prefix Extreme best takes a gerund - a verb in 'ing' form. It plays upon the extreme skiing and extreme snowboarding terms. And it <em>is</em> extreme programming, it is a methodology of living programming and designing programming, and documenting programming, and offering programming as the most serious part of software creation.
<em>(Only someone who was afraid of facing their fear of being called "<a href="http://c2.com/cgi/wiki?JustaProgrammer">JustaProgrammer</a>" would call this <a href="http://c2.com/cgi/wiki?ExtremeSoftware">ExtremeSoftware</a>. -- <a href="KentBeck.html">KentBeck</a>)</em>
<p>Extreme programming quite possibly works in more than one setting, and should be put forth as a serious contender to documentation-based methodologies. I vote it as a valid one of the <a href="MinimalMethodologies.html">MinimalMethodologies</a>. I like the <a href="ExtremeProgramming.html">ExtremeProgramming</a> methodology, it fits my definition of a big 'M' methodology, it pushes a given philosophy to its natural conclusion and stands behind that conclusion. It has been used by more than the <a href="http://c2.com/cgi/wiki?ChryslerComprehensiveCompensation">ChryslerComprehensiveCompensation</a> project (but not as vocally defended or as well documented) so it has wider prior art. I find it interesting to defend, even not having ever used it. -- <a href="http://c2.com/cgi/wiki?AlistairCockburn">AlistairCockburn</a>
<p><hr>
<p>Where does Thinking fit into <a href="ExtremeProgramming.html">ExtremeProgramming</a>? I see afterthinking in Refactoring, but I don't see any beforethinking.
--<a href="http://c2.com/cgi/wiki?BetsyHanesPerry">BetsyHanesPerry</a>
<p>I could answer that question several ways ...
<UL><li> <em>Provocative.</em> The <a href="http://c2.com/cgi/wiki?ExtremeProgrammer">ExtremeProgrammer</a> is too busy learning to think.
<li> <em>Snide.</em> What do you want to think for, it'll just screw up your code.
<li> <em>Serious.</em> The kind of thinking I used to do before coding wasn't helpful. I would impute all sorts of requirements that weren't really there, and end up building something far too complicated.
<p></UL>The <a href="http://c2.com/cgi/wiki?ExtremeProgrammer">ExtremeProgrammer</a> does BeforeThinking<a href="http://c2.com/cgi/wiki?edit=BeforeThinking">?</a> in two ways. The first is figuring out what the next test case should be, thinking about the objects strictly in terms of their external protocol. The second is answering the question, "What is the simplest thing that could possibly work?" Sometimes you just make the test case work, sometimes you refactor first so you can easily make the test case work.
<p>AfterThinking<a href="http://c2.com/cgi/wiki?edit=AfterThinking">?</a> comes in the form of 1) restructuring the system based on what it is telling you about how it wants to be structured and 2) filling in test cases suggested by the code.
<p>There's a lot of thought going on, before and after, more than in any way I've ever programmed before.
-- <a href="KentBeck.html">KentBeck</a>
<p>Sorry, I didn't mean to imply you weren't thinking, though I wouldn't have missed your riff on the subject for the world. Rather, I was commenting on your opening salvo, which says "LTCR, that's all there is to software." In other words, anything besides LTCR is superfluous. I've worked on projects where people coded without thinking, and the results didn't ship. Your described process guards against the Scylla of overthinking; it does not, in the original formulation, address the Charybdis of underthinking. It seems to me that your riff does a better job of navigating between the hazards.
--<a href="http://c2.com/cgi/wiki?BetsyHanesPerry">BetsyHanesPerry</a>
<p><p>There's two types of not thinking. One good and one bad
<p>1. You have design guides, coding style, coding standards, naming standards, and the compiler. This cuts down the amount of thinking to do in two ways:
<OL>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -