📄 justintimeprogramming.html
字号:
<head><title>Just In Time Programming</title></head><body><h1><img src="logo.gif"> Just In Time Programming</h1>An iterative approach to development. Focus on developing <strong>only</strong> what your current requirements call for. <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a>. Assume that <a href="YouArentGonnaNeedIt.html">YouArentGonnaNeedIt</a>.
<em>[Or, <a href="http://c2.com/cgi/wiki?CodeUnitTestFirst">CodeUnitTestFirst</a>]</em>
<hr>
<p>In its finest form, as practiced by <a href="KentBeck.html">KentBeck</a>, the approach looks like this.
<p><UL><li> Have a test showing that the new feature desired doesn't work. Put a message send in the appropriate place to add the feature. (Don't implement the method.)
<li> Run the test. It walks back; the new method isn't there.
<li> Add the method, with a halt in it. Run the test. It halts.
<li> Write the method in the debugger, each message in the broken method stating intention. If you don't quite know what to do, you're in the debugger, inspect what you've got and see what it can do to help.
<li> Run the test. It walks back; the first new method isn't there.
<p></UL>Repeat the process, rapidly refining the implementation until, voila, it's actually working. Review the implementation, refactor as needed. You have a test, so you can be sure your refactoring is correct.
<p>With a couple of features added to the debugger, like a <a href="http://c2.com/cgi/wiki?StubButton">StubButton</a>, you build most of the code in the debugger ... it's like being able to observe the engine running while you tune it.
<p><hr>
<p>If you haven't experienced this, it probably sounds like baling wire and chewing gum. It isn't. You are intimately connected to the objects that need to do the job for you. You follow where Smalltalk leads, crafting clear, small methods as you go. If I could give you this one experience, my life would be complete. (Not that I'd log out, you understand.)
--<a href="RonJeffries.html">RonJeffries</a>
<p><hr>
<p>This is the way I used to do it in Smalltalk. Now, when I'm using VaJava<a href="http://c2.com/cgi/wiki?edit=VaJava">?</a>, I find that it can't be done as easily because when I add a method or change a signature, etc. stuff doesn't compile. But VaJava<a href="http://c2.com/cgi/wiki?edit=VaJava">?</a> kindly shows me with little red X's what I have to fix. So I fix them and then use breakpoints and the debugger (until a change I make in the debugger gives me new little red X's).
<p>It's still a beautiful thing and gets the same result. --<a href="http://c2.com/cgi/wiki?KenAuer">KenAuer</a>
<p><hr>
<p>I've been having mixed results with this "top-down" approach, and I'm pretty sure it's my fault, because the technique sounds so beautiful. I'm having trouble figuring out when to write the tests for the lower-level methods. If I try to write the test when the walkback occurs, it tends to break the flow of the process. If, instead, I try to maintain the flow, I find myself producing beautiful, clear methods - but when I'm done, I find myself with only one high-level test written. (At that point, I can go back and write the lower-level tests, but that doesn't sound like the right way to do things.)
<p>Is there a better way of doing this? Maybe I need to train myself to incorporate the lower-level-test-writing into the flow.
<p><em>(A week later...)</em>
<p>Having had the answer pounded through my head by several people, I'll attempt to write it up here. Please fix the parts that I get wrong. --<a href="http://c2.com/cgi/wiki?AdamSpitz">AdamSpitz</a>
<p>The trick is to do things so simply that there's no need to go very deep during any test-code-refactor cycle. Start off by writing the simplest test you can think of, and make it pass by writing the simplest code that you can - which probably means just hard-coding the correct answer.
<p>You don't just leave the hard-coded answer in there, of course. You go back and write another test - this time the second-simplest test you can think of. Maybe this time the hard-coded answer isn't good enough anymore, so you generalize the method so that it passes both tests.
<p>It might seem stupid to do the two steps separately, but it's important to realize that while you were doing that first step, the code told you a little bit about how it wanted to be structured, even if it didn't tell you how it wanted to be implemented. And it all happened without straying very far from a place where the tests would pass.
<p><hr>
<p>I suppose I'm just daft, but all this talk of automated test suites sounds like pie in the sky to me--but maybe I'm reading too much into it. It seems to me that when code gets complex, no test that I could write would convince me that it is sound. On the other hand, if I can think of a test, I almost don't need it, because it'll be so simple. That said, I'd love to have a suite of tests that I can run anytime I want to verify that the whole system works, but how to do it? I mean, a test that tells me whether a bunch of code still processes some test data in a predictable way is nice, but what I really need is a test that tells me when a side effect has appeared, and that's an animal I'm not likely to see.
<p>I work mostly on small projects in Lotus Notes and LotusScript<a href="http://c2.com/cgi/wiki?edit=LotusScript">?</a> (Visual Basic). I test as I go, but in most cases I just can't see how a cost effective automated test can be built. As a practical matter, I write tiny tests to verify each function, but mostly rely on manual functional tests to assess the system. I'll admit it does not work perfectly, and would not work for large projects, but if their is a practical alternative for small projects, I'd like to learn about it.
<p><hr><a href="http://c2.com/cgi/wiki?edit=JustInTimeProgramming">EditText</a> of this page (last edited January 18, 2001)<br><a href="http://c2.com/cgi/wiki?FindPage&value=JustInTimeProgramming">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 + -