⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 toayoungextremist.html

📁 极限编程 Extream Programing
💻 HTML
📖 第 1 页 / 共 2 页
字号:
Now, how could what I wrote above be construed as anti-design? It is certainly against making lots of design decisions all at once. In the style I aspire to, you try to make each decision at each scale with as much context as possible. The reductio ad absurdum is that you make one requirement decision, one analysis decision, one design decision, one testing decision, and then one coding decision. This typically takes 1-10 minutes. You have learned a lot, because you have received the concrete feedback of the code and the tests. Now you have much more context for your next set of decisions- you're smarter, you have the context of running code to keep you from getting far off course, and you have remained focused, not pursuing high-risk, low-payoff phantasms.
<p>I suppose if design is &quot;thinking ahead to avoid problems in the future&quot;, I am anti-design. That looks radical to me just sitting there, but it is my honest opinion, so I'll let it sit there. If design is making decisions that span objects, I spend far more time and energy on that now, and I do so much more effectively, with the style I describe above.
<p>(Let me interject here... But this isn't how you behave. As is pointed out at the bottom, lots of things in XP are thinking ahead to avoid problems. What's <a href="SpikeSolution.html">SpikeSolution</a>. How do you attack <a href="http://c2.com/cgi/wiki?WorstThingsFirst">WorstThingsFirst</a> without thinking about what's worst. What are the six weeks of exploration at the beginning of C3 if not analysis. It's clearly not the same as what traditional methodologies consider design, and much more focused on getting quick feedback on what you've thought, but there's still definite forethought involved -- <a href="http://c2.com/cgi/wiki?AlanKnight">AlanKnight</a>)
<p>That doesn't mean you can't design ahead and be extreme at the same time. In the spirit of XP, however, I urge you to pay attention to when your &quot;designing ahead&quot; activities pay off and when they don't, and to experiment with other styles. Within the context of clear communication, simple designs and code, and tests for everything that could break, I discovered that the fewer design decisions I made in a row without feedback, the faster and better I went, and the better I felt.
<p>You have to handle a wild ocean of change. Are you going to build a breakwater, or are you going to learn to surf? --<a href="KentBeck.html">KentBeck</a> (scared of being honest, but there you have it).
<hr>
Kent, it looks like this is another one of those cases where I agree with you, and I see where you are going, but by playing devil's advocate I've boggled things.
<p>From <a href="ExtremeProgramming.html">ExtremeProgramming</a>:
<p><em>Listening, Testing, Coding, Refactoring. That's all there is to software. Anyone who tells you different is selling something. --<a href="KentBeck.html">KentBeck</a></em>
<p>You just don't use the word design at all.  I work in the medical instruments area.  FDA regulated industry.  I can imagine people in safety critical areas who believe that unless you diagram first and code second you are doomed.  And if your code does not match your diagrams, you've failed to follow process and you've made mistakes.  I tend to feel that this is a result of the fallacy that <a href="TheSourceCodeIsTheDesign.html">TheSourceCodeIsTheDesign</a> recognizes, and that XP does away with even if it does not say so explicitly.  So, I agree with you totally, I'm just presenting this other perspective which XP may have to deal with in some milieus.  
<p>We start with waterfall, then we go to spiral, and then iterative incremental, and now XP.  What is the tendency?  Has the process for design and constructing bridges followed this sequence over the years?  In software, we can say that it is L, T, C, and R (as above) and design is what goes on between the grey matter and the fingers on the keyboard with no reviews or signoffs, or we can say it is all part of the design phase of software and <a href="TheSourceCodeIsTheDesign.html">TheSourceCodeIsTheDesign</a>. 
<p>What I am saying is that in some areas people will not look twice at a process with no design phase.  They will call it hacking and freak out.  I just see the whole thing L,T,C,R as the design phase.  Everything before you distribute the software.  -- <a href="http://c2.com/cgi/wiki?MichaelFeathers">MichaelFeathers</a>
<hr>
Michael- I agree that we agree. The question is how do we break the news. Early in the life of an idea it can be worthwhile to be outrageous. I have certainly used this tactic at times. 
<p>However, as time goes on, I find I am getting more outrageous, not less. I was interviewing a project for a possible coaching position. They said, &quot;We like to do two months of analysis and design for a six month project.&quot; I said, &quot;I don't see how that could possibly work. I can't imagine doing less than six months of analysis. And six months of design. And six months of coding. And six months of testing. Fortunately, though, we can do them all at the same time.&quot; We'll see how that works... --<a href="KentBeck.html">KentBeck</a>
<p><em>Oh, I </em>
<strong>like</strong> 
<em>that last bit!  --<a href="RonJeffries.html">RonJeffries</a></em>
<p><hr>
<p>I like this page a great deal and hesitate to comment ... but.
<p>Hmm, where to start after that but. How about this:
<p>But I like to see the far side of the lake before I commit to cross it. I like to see how high the mountain before I commit to climb it. And I like to see how deep the problem domain before I commit to solve it.
<p>At what point does XP scope the problem domain? At the end of the project? Isn't scoping the problem domain necessary to adequately resource the project? 
Analysis, for me, is more than just input to a design process; it's what gives me an idea of the mountain's height or the lake's width so I can adequately resource my commitment.
<p><em>I'm going to go out on a limb here: You are asking to predict the future. You are asking questions that can only be answered once the project is completed (ie how many resourced did it take? What objects are necessary? How do they interact?).  You are asking to scope the project in such a way that you will know more than you would by gathering requirements and making a <a href="http://c2.com/cgi/wiki?CommitmentSchedule">CommitmentSchedule</a>....which I would call analysis, design and scoping if pressed (by management) to call it more than it really is.</em>
<p><em>Basically, as in <a href="http://c2.com/cgi/wiki?RealLife">RealLife</a>, in these things there are some inherent risks. The best you can do is (1) understand what is being asked of you, and (2) perform to the best of your abilities. There's no safety net. --<a href="http://c2.com/cgi/wiki?AnthonyLander">AnthonyLander</a></em>
<p><strong>Nicely put, Anthony.  --rj</strong>
<p><em>True.  As far as scheduling and scope go there is no safety net, but in the nuts and bolts of development, TestingIsTheUltimateSafetyNet<a href="http://c2.com/cgi/wiki?edit=TestingIsTheUltimateSafetyNet">?</a>.  There is no excuse today for a project which pushes all the bugs to the final month of development.  Developing without testing as you go is like climbing to higher and higher tightropes without a safety net.  The chances that you will splatter almost approach certainty.</em>
<p>This is the nub of <a href="http://c2.com/cgi/wiki?ExtremeProgrammingChallengeFive">ExtremeProgrammingChallengeFive</a>. I'd take <a href="http://c2.com/cgi/wiki?ExtremeProgrammingChallengeFive">ExtremeProgrammingChallengeFive</a> as an appeal for XP to adopt an extra value, which, for want of a better word, I'd call Vision, and an attendant activity, which. for want of a better word, I'd call Scoping. --<a href="http://c2.com/cgi/wiki?PeterMerel">PeterMerel</a>
<hr>
The letter above is about how to code, and how to partner.  I didn't make that clear.
<p>Overall, XP is about seeing the far side of the lake, how high the mountain is, as clearly as <strong>necessary</strong>, not by introspection, but by production of actual artifacts.
<p><UL><li> <a href="http://c2.com/cgi/wiki?UserStory">UserStory</a> cards, written at the beginning of the project, delineate its overall size;
<li><a href="SpikeSolution.html">SpikeSolution</a> (ArchitecturalPrototype<a href="http://c2.com/cgi/wiki?edit=ArchitecturalPrototype">?</a>) tests the solution from the very beginning;
<li> <a href="http://c2.com/cgi/wiki?CommitmentSchedule">CommitmentSchedule</a>, done after the first <a href="SpikeSolution.html">SpikeSolution</a>, assigns risk to each story and ensures that they'll be attacked <a href="http://c2.com/cgi/wiki?WorstThingsFirst">WorstThingsFirst</a>. 
<p></UL>See also <a href="http://c2.com/cgi/wiki?XpVisionScope">XpVisionScope</a>.  --<a href="RonJeffries.html">RonJeffries</a>
<hr>
I was visiting a client at the same time as Ward was.  One of the younger developers came into the room with a question: &quot;I needed such and such, so I put a method like this on this object, was that OK?&quot;  It wasn't, and I said so.  Ward said, let's do a CRC session.
<p>The developer laid out the cards and showed where the change was made.  It wasn't the right place, and I said so.  Ward picked up the cards, asked questions; the developer answered.  After a while the developer said, &quot;so it should go here?&quot;, and pointed to the right object.
<p>I was half-way home before I even realized what Ward had done.  It was over a month ago, and I'm still not over feeling clumsy.  How such a big man can dance so smoothly, I'll never understand.  Amazing.  --<a href="RonJeffries.html">RonJeffries</a>
<hr>
<em>I have this vision of how I want the objects to be and what they need to do - and I don't seem to be communicating it very well.</em>
<p>Dammit, I feel that way about XP.  I suspect it's for the same reasons.  What I most want from XP is the <em>always ready</em> aspect.  After much failure to sell people on the idea, I've worked out that I'm being driven by an over compensation for too many years of being late for everything.  &quot;All methodology is based on fears&quot; to quote <a href="KentBeck.html">KentBeck</a>.  But my colleagues don't have the same fears, so I have to work out what in XP I can offer them that will also give me what I want.  
<p>XRef SecurityBlanket<a href="http://c2.com/cgi/wiki?edit=SecurityBlanket">?</a>, <a href="http://c2.com/cgi/wiki?XpLite">XpLite</a>
<p>--<a href="http://c2.com/cgi/wiki?BenAveling">BenAveling</a>
<hr><a href="http://c2.com/cgi/wiki?edit=ToAyoungExtremist">EditText</a> of this page (last edited September 4, 1999)<br><a href="http://c2.com/cgi/wiki?FindPage&value=ToAyoungExtremist">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 + -