📄 dothesimplestthingthatcouldpossiblywork.html
字号:
<head><title>Do The Simplest Thing That Could Possibly Work</title></head><body><h1><img src="logo.gif"> Do The Simplest Thing That Could Possibly Work</h1>It is interesting that the <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> page is so large. Is it simple?
<p><a href="http://c2.com/cgi/wiki?DoSimpleThings">DoSimpleThings</a> in XP. This enables design via two rules:
<p>First, implement a new capability in the simplest way you can think of that "could possibly work". Don't build a lot of amazing superstructure, don't do anything fancy, just put it in. Use an if statement, even. Make the code pass the <a href="UnitTests.html">UnitTests</a> for the new feature (and all features, as always).
<p>Second, and this is critical to the rule, <em>refactor</em> the system to be the simplest possible code including all the features it now has. Follow the rule of <a href="http://c2.com/cgi/wiki?OnceAndOnlyOnce">OnceAndOnlyOnce</a> and the other code quality rules to make the system as clean as it can possibly be.
<p><hr>
<p>Be sure to see the <a href="http://c2.com/cgi/wiki?ShakerQuote">ShakerQuote</a> that starts...
<p>'"If it is not useful or necessary, free yourself from imagining that you need to make it. ..."''
<hr>
<a href="http://c2.com/cgi/wiki?WhatIsSimplest">WhatIsSimplest</a> is a very interesting question to me. -- <a href="http://c2.com/cgi/wiki?MichaelFeathers">MichaelFeathers</a>
<p><a href="http://c2.com/cgi/wiki?DoSimpleThings">DoSimpleThings</a> is a simple answer, speaking to ones awesome power to be complex. --PCP
<p><hr>
Isn't <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> just <a href="http://c2.com/cgi/wiki?SmallIsBeautiful">SmallIsBeautiful</a> applied to programming? --<a href="http://c2.com/cgi/wiki?HelmutLeitner">HelmutLeitner</a>
<hr>
<em>See <a href="http://c2.com/cgi/wiki?DrawingHand">DrawingHand</a> for a response to the concerns about simplicity possibly resulting in "<a href="http://c2.com/cgi/wiki?FlimsyAndBarelyFunctional">FlimsyAndBarelyFunctional</a>" software.</em>
<hr>
With each increment of an <a href="IterativeDevelopment.html">IterativeDevelopment</a> one should do the simplest thing that could possibly work. To do this you have to know at least two ways to do the thing. That way you can at least pick the simpler, if not the simplest.
<p>Know that the ways could possibly work. We do not mean <strong>will</strong> work,
we mean <strong>could possibly</strong> work. You need to be pretty sure it will work, but you don't have to prove it. Why? Because when you try to implement it, your implementation will tell you whether it <em>does</em> work. Your tests will run, or they won't. It will feel good, or it won't.
(Contrast this with the <a href="http://c2.com/cgi/wiki?EinsteinPrinciple">EinsteinPrinciple</a>.)
<p><em>We're not looking for the quickest way, we're looking for the simplest result. So, we first break the existing method into pieces. That leaves the existing test cases running. Then we modify (simply, now) one of the little methods to handle the next test case. (KB)</em>
<p>Simplest does, however, mean a minimal solution. Don't build a giant super-efficient object, sorted and hashed and linked together, if an Array will do the job.
<p>Simplest might mean "just use a Dictionary". It might mean "create a little object". It might mean "refactor the part hierarchy so that entitlements and deductions both have positive balance when they are normal".
<p>What it does mean, however, is to pick something you can do and do quickly, so that you can get on with the other things you really need to do. Then do that thing professionally and well, complete with all appropriate refactoring.
<p>As for the things you're gonna need: <a href="YouArentGonnaNeedIt.html">YouArentGonnaNeedIt</a>.
<p>-- <a href="RonJeffries.html">RonJeffries</a>
<hr>
My motivation [for DTSTTCPW] is confronting fear. Without a mantra, I can easily remain paralyzed in careful, clever, even brilliant design for weeks when thirty minutes of code would answer all my questions. Design that comes from experience is always workable, and occassionally profound. Design that comes from fear-based speculation is always clever, and occasionally utterly impossible.
<p>There are second order effects to asking yourself "What is the simplest thing that could possibly work?"-
<PRE> * You get done sooner
* Your work is easier to communicate
* Duplication is obvious, so the needs and means for refactoring are clearer
* Tests are easier to write
* The code is easier to performance tune
* You feel less stress, which enhances all of the above
<p></PRE>-- <a href="KentBeck.html">KentBeck</a> from <a href="XpMailingList.html">XpMailingList</a> (8/2000)
<hr>
<a href="http://c2.com/cgi/wiki?SimplestThingReplyFromJamesCollins">SimplestThingReplyFromJamesCollins</a>
<hr>
<a href="http://c2.com/cgi/wiki?SimplestThingReplyFromRonJeffries">SimplestThingReplyFromRonJeffries</a>
<hr>
One final note: <a href="ExtremeProgramming.html">ExtremeProgramming</a> rests, I believe, on the assumption that developers want to do well, and that when they know what is expected, they will do well. We do, as a team, require that our rules about testing and other key processes be followed. In almost every case, that works just fine. If a developer doesn't follow the rules, we correct or remove him.
<p>Quality is terribly important in payroll. Airplanes won't fall out of the sky, but the factory could go on strike, and you could make tens of thousands of people very angry. There is no reason why simplicity and quality are in conflict: in my experience, they go hand in hand.
<p>--<a href="RonJeffries.html">RonJeffries</a>
<hr>
Where I am having difficulty here is that 'simplest' has no metric. So "the fewest programming environment operations to get the next test case running" could actually be what is meant. Or, "fewest lines of source code". Or, "source code using the what-I-consider simplest types of operations".
<p>I have my funny little coffee machine design problem, which has many different solutoins, and which I give to all and sundry. What struck me in the 1997 OOPSLA worshop on OO Design Quality was that the people at our table were split over which of the two designs on the table was "simpler". We found six different characteristics for simpler among 8 people. This scenario has repeated itself over, and I was surprised that <a href="RonJeffries.html">RonJeffries</a> was able to criticize the existing design set and come up with yet another, different design, by saying that the others weren't as simple as they should be. He had another thinking that gave another solution that he thought was 'simpler'.
<p>That leaves me with the feeling that we should not actually try to get to the bottom of What-Is-Meant by the <a href="http://c2.com/cgi/wiki?SimplestThingThatCouldPossiblyWork">SimplestThingThatCouldPossiblyWork</a>. Rather, given that different people are going to interpret Simplest in different ways, assume that their Simplest solutions will be different.
<p>Extreme Programming then says, Refactor until <some other low-entropy or simplicity-based subjective criteria> is met, always preserving the test cases.
<p>--<a href="http://c2.com/cgi/wiki?AlistairCockburn">AlistairCockburn</a>
<hr>
Interesting observations and conclusion, Alistair ... not entirely satisfying, but consistent with one thing I believe, which is that a developer really needs to dig in until she has developed her own internal sense of quality. I don't expect mine to match yours; I do hope we are in touch enough with them that we can talk about them and use our different senses to choose a solution for today that satisfies both our internal metrics. --<a href="RonJeffries.html">RonJeffries</a>
<hr>
Alistair, did some of those workshop participants argue that a design was
simpler because it involved fewer code changes from an earlier design?
<p>The 'do' in <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> isn't how you get to the
design; it's what is done <em>in the design</em>. "The fewest programming
environment operations to get the next test case running" is a possible way to
get to a design. It's
<em>almost</em> irrelevant in discussion of the simplicity of a
design itsel.
<p>I say "almost", because if you <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a>, i.e., if
you produce the simplest design, getting to the <em>next</em> design will be
simpler. In the long haul, "the fewest programming environment operations to
get the next test case running" isn't even the simplest way to get to the next
design. <em>Kiel, please support FewestIsntSimplest<a href="http://c2.com/cgi/wiki?edit=FewestIsntSimplest">?</a>. --rj</em>
<p>Sorry to be too obtuse, Ron. At each iteration in the evolution of the design,
Fewest may well be Simplest. But <a href="http://c2.com/cgi/wiki?CruftMultiplies">CruftMultiplies</a> and that simplest
way to get from Design N to Design N + 1 is not as simple
<em>as it would have been had cruft not been allowed to accumulate.</em> In other words, the shortest path from Cruft-laden Design N to the next design
is generally longer than the shortest path from Cruft-free Design N to the next
design.
--<a href="http://c2.com/cgi/wiki?KielHodges">KielHodges</a>
<p><em>Kiel, we aren't talking abou the same thing. In XP, <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> entails two (2) steps: first, implement the thing in a simple straightforward way; second, refactor the code to produce the simplest system including the new thing. In XP, we have an explicit rule and practice to keep cruft from multiplying. When we do this (and of course we can screw up), it seems to me that fewest is simplest. I was asking you to support FewestIsntSimplest<a href="http://c2.com/cgi/wiki?edit=FewestIsntSimplest">?</a> in the XP context. --rj</em>
<p>Yes, I believe we were out of sync in two ways. I was arguing that
FewestIsntSimplest<a href="http://c2.com/cgi/wiki?edit=FewestIsntSimplest">?</a> as it is all too frequently practiced (making the smallest
change without subsequently refactoring), not in the context of XP. But I was
missing the point about the first of the two steps in
<a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a>, that it entailed simple, straightforward changes.
<p>Please allow me to test my understanding.
In step one, the <em>developer</em> should <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a>
in order to get from the current design to one that implements the new
functionality.
In step two, the developer refactors to get a <em>system</em> that will
<a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a>. So, 'do' is different in each step,
yet you still want simplicity relative to the context of each step.
--<a href="http://c2.com/cgi/wiki?KielHodges">KielHodges</a>
<p>Thanks for the feedback, Ron. BTW, what I was missing is certainly there. ("Use an if statement, even.") But I was too
focused on the subsequent refactoring (and probably still hung up on "doing it right") to give it due consideration.
<p>Refactoring lets one go faster; I've long been convinced of that. But one also goes faster by initially implementing
the thing in a simple straightforward way. I -- and probably others -- need to let go and allow myself to do that.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -