📄 designinxp.html
字号:
<head><title>Design In Xp</title></head><body><h1><img src="logo.gif"> Design In Xp</h1><a href="ExtremeProgramming.html">ExtremeProgramming</a> includes as much or more design as other processes. It differs in when it does design, and in what artifacts are produced.
<p>Waterfall processes use <a href="BigDesignUpFront.html">BigDesignUpFront</a>, and look kind of like this:
<p><UL><li> design design design code code code test test test
<p></UL>Incremental and spiral processes look more like this:
<p><UL><li> design code test design code test design code test
<p></UL><a href="ExtremeProgramming.html">ExtremeProgramming</a> looks like this:
<p><UL><li> dtc dtc dtc dtc dtc dtc dtc dtc dtc dtc dtc dtc
<p></UL><em>[Minor edit: I changed dct to dtc in the previous line. My apologies if I am wrong. -- interlock.arinc.com]</em>
<p><em>[Or, if I understand <a href="RefactorMercilessly.html">RefactorMercilessly</a>, it should be "tcd"??? -- <a href="http://c2.com/cgi/wiki?JeffGrigg">JeffGrigg</a>]</em>
<p><em>dtc is best. a little carding, or a moment of thought, then write test, then code. In refactoring, there is generally no new test-writing, though of course one runs them incessantly.</em>
<p>In <a href="ExtremeProgramming.html">ExtremeProgramming</a>, we admit that we aren't smart enough to invent a full-scale design that will actually be optimal. This means that doing a <a href="BigDesignUpFront.html">BigDesignUpFront</a> will be wasteful.
<p>We also admit that we aren't smart enough to do a lot of coding and have it all work. This means that doing a lot of coding and only then testing will also be wasteful.
<p>Instead, we do a little bit of design, we code it up, we test it, again and again, many times a day.
<p>In the middle of the project, we're faced with a new <a href="http://c2.com/cgi/wiki?UserStory">UserStory</a>. We need to define the <a href="http://c2.com/cgi/wiki?EngineeringTask">EngineeringTask</a>'s that will implement the story. If it's not obvious (and often it is), we will do a quick CRC session to determine what needs to be done. A handful of developers will sit down, usually with a customer, and put down cards for the objects relating to the new story. They'll add cards representing the new inputs and outputs, and cards representing the objects that transform the inputs to the outputs. In a few minutes, the developers will know what is to be done.
<p>The next step is to throw away the CRC cards and implement the tests and the code. Developers step to the machine, write a unit test for the method or object they're about to create, run the test (oops, it doesn't work), implement the method or object, run the test, fix the method, add a method, run the test, until done. This should take a few minutes. Then the cycle repeats.
<p>Where's the design? Part of it is in the CRC session, if one was needed. Most of it comes during a "dct" cycle. <em>[Write the test then...]</em> Go the object that needs a new method. Write the method, giving it a name that expresses your intention. Implement the method by refining it, also by intention:
<p><em>Add the test first right? I think it would look something like this... --<a href="TimMackinnon.html">TimMackinnon</a> --</em>
<PRE> testGetTaxDeductions
aTaxObject setTaxDeductions: self taxDeductionsTestData.
aTaxObject getTaxDeductions.
self assert: aTaxObject getDeductionTotal = self taxDeductionsKnownTotal.
...other assertions....
<p></PRE>Then write the missing method...
<p><PRE> getTaxDeductions
[taxDeductions atEnd] whileFalse:
[deduction := taxDeductions next.
self addDeduction: deduction]
<p></PRE>Now either you're done, because you used only methods that already exist, or you need to write another method:
<p><PRE> addDeduction: aDeduction
taxDeductions add: aDeduction.
taxDeductionTotal := taxDeductionTotal + aDeduction amount.
<p></PRE>Pretty soon you've implemented the feature. Run your tests and make sure it works.
<p><em>Question: When did a test get written for this second method #addDeduction:? It may be that the initial test correctly covers its scope, but usually more testing is required for it. I've heard Kent say <a href="http://c2.com/cgi/wiki?SitOnTheOtherCards">SitOnTheOtherCards</a>, I take this to mean that I should also queue up another card to remind myself to write a test for #addDeduction:. I wonder if <a href="http://c2.com/cgi/wiki?SitOnOneCardDiscussion">SitOnOneCardDiscussion</a> covers this? --<a href="TimMackinnon.html">TimMackinnon</a></em>
<p><p>Now examine the code you have created. Look for violations of <a href="http://c2.com/cgi/wiki?OnceAndOnlyOnce">OnceAndOnlyOnce</a>, names that don't communicate, methods that seem to be on the wrong object, other infelicities. <a href="RefactorMercilessly.html">RefactorMercilessly</a>, until the code is a neat as a pin. Run your tests often during this process, and of course, when you're done.
<p><UL><li> How often do you integrate your changes into the source base? In my <a href="ExtremeProgrammingForOne.html">ExtremeProgrammingForOne</a> (using Java and RCS), I will commit my changes every time the unit tests come out OK and the functional tests show I haven't lost ground -- so what I get is ''code commit refactor commit refactor commit code commit", with test runs before every commit and often during the coding.
<p><li> Recall that all the <a href="UnitTests.html">UnitTests</a> must run in order for us to release code. This takes about ten minutes for all 3,000 of them. And we release code from a specific machine, to ensure that we serialize release, which prevents folks from accidentally stepping on each others' edits. So we release at the end of a chunk of functionality - typically once a day per developer.
<p></UL>There's a lot of design in this process. When you express your intention, you're designing how the thing should be done - the meaning of the objects and methods involved. Then when you refactor, you are ensuring that the overall system remains cohesive and that the objects relate to each other well. These are the main things you want to accomplish with design.
<p>If design is done more up front, the discoveries during coding either have to be fed way back into the design, or the design will be allowed to drift from reality, or (god save us) the design will be adhered to even though the code tells us the design is wrong.
<p>If design is done more up front, it becomes harder and harder to do design, so less and less is done. But since "design and coding aren't the same thing", the slack will not be picked up during the code/test cycle, so the system diverges from good design.
<p>XP does more design than most processes; it does it longer; and it does it closer to the point where it matters: closer to what goes into the code.
<p>See also <a href="http://c2.com/cgi/wiki?ExtremeDesignArtifacts">ExtremeDesignArtifacts</a>, also <a href="http://c2.com/cgi/wiki?ExtremeHumility">ExtremeHumility</a>
<p><hr><a href="http://c2.com/cgi/wiki?edit=DesignInXp">EditText</a> of this page (last edited July 15, 1999)<br><a href="http://c2.com/cgi/wiki?FindPage&value=DesignInXp">FindPage</a> by browsing or searching<p><font color=gray size=-1>This page mirrored in <a href="index.html">ExtremeProgrammingRoadmap</a> as of March 31, 2001</font></body>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -