dothesimplestthingthatcouldpossiblywork.html

极限编程 Extream Programing

<p>
I keep seeming to get two contradictory messages.
I see two interpretations: which is XP?
<p>
A)
<PRE>
    1. Do the quickest hack that could possibly work (even if it's complex)
    2. Refactor to the simplest thing that does work
<p>
</PRE>
or B)
<p>
<PRE>
    1. Do the simplest thing in the local context (even if it takes time)
    2. Refactor to be globally simplest
<p>
</PRE>
--<a href="http://c2.com/cgi/wiki?DaveWhipp">DaveWhipp</a>
<p>
I prefer B if I can get it. If not, I do A, and prepare to throw away the resulting code if it exceeds my stink threshold. --<a href="KentBeck.html">KentBeck</a>
<hr>
&quot;One little step at a time, lest I be presumptuous, lest I hurt myself, lest I hurt others.&quot; --Joan Halifax
<p>
<strong>It means one knows everything about programming there is to, but only applies one technique at a time.</strong>
<p>
<hr>
<p>
I don't understand.  The simplest thing that could possibly work will usually be the least effective.  Certainly, it's simpler to write (in the middle of a class) 
<p>
<PRE>
  // ...
  public final static int CLUB_SUIT = 1;
  public final static int DIAMOND_SUIT = 2;
  public final static int HEART_SUIT = 3;
  public final static int SPADE_SUIT = 4;
  // ...
<p>
</PRE>
then it would be to create a Suit class:
<p>
<PRE>
  public class Suit implements java.lang.Cloneable,
                               java.lang.Comparable,
                               java.io.Serializable {
    private static int next_ordinal = 0;
    private final int ordinal = next_ordinal++;
    private transient String name;
    private Suit(String name) { this.name = name; }
    public String toString()  { return name; }
    public Object clone()     { return this; }
    public int compareTo(Object obj) {
      return ordinal - ((Suit)obj).ordinal; }
    public final static Suit CLUB = new Suit(&quot;Club&quot;);
    public final static Suit DIAMOND = new Suit(&quot;Diamond&quot;);
    public final static Suit HEART = new Suit(&quot;Heart&quot;);
    public final static Suit SPADE = new Suit(&quot;Spade&quot;);
    private final static Suit[] SUITS =
      {CLUB, DIAMOND, HEART, SPADE};
    private Object readResolve() throws java.io.O<strong></strong>bjectStreamException {
      return SUITS[ordinal]; }
  }
<p>
</PRE>
However, I'd hate to work with the first type of code.  the second isn't simple, but it's better.  So?
<p>
<em>But All I need to do is capture the suit choice for use by a down-stream system, they use 1,2,3,4 as their deliniator.  My system never does anything with it.  Why do I need all the other stuff?</em>
<p>
Actually the simplest thing is to number the cards in rank order. Suit might be a concept confined to the print routines. If you said this will lead to bug producing logic duplication, I'd say let's wait and see.
<p>
<em>Unless, of course, we aren't interested in the face value of the card, just the suit.  Context, context, context... ;-)</em>
<p>
Some assumptions made in the above code :
<UL>
<li> Suits have persistent state of their own.
<li> Suits are not singletons.
<li> Suits are ranked rather than equal.
<li> Suits are ranked in the particular order C, D, H, S.
<li> Suits have printable <strong>English</strong> names (rather than e.g. icons).
<li> Suits' names are hardcoded, not configurable.
<li> Suits' names are singular rather than plural.
<li> There are only four suits.
<p>
</UL>
Thought experiment. Suppose that we are the Customer for a system that at some point requires simulated playing cards. We had one <a href="http://c2.com/cgi/wiki?UserStory">UserStory</a> so far, which said, &quot;Cards must be characterized by their face value and suit.&quot;
<p>
Now, how many <em>reasonable</em> user stories can we think up that one or more of the above assumptions will make harder, not easier, to implement ? (Hint: imagine a game of French Tarots coded in picoJava for the Palm Pilot, memory being at a premium.)
<p>
<hr>
<p>
Perhaps I'm missing something here, but just because a given language makes one solution <em>appear</em> more complex, doesn't mean it really is so.
<p>
In the above example, if you take out the gramatical constructs of java and leave only the semantic content, you wind up with something like this:
<p>
<PRE>
  standard_enumeration_class Suit = {
      CLUB = &quot;Club&quot;
      DIAMOND = &quot;Diamond&quot;
      HEART = &quot;Heart&quot;
      SPADE = &quot;Spade&quot;
      ==================
      ordered
      collection = SUITS
  }
<p>
</PRE>
Now, that's a little more complex than the static constants, but NOT MUCH MORE. All the rest is just 20 lines of boilerplate. If this is something that you use a lot (and why wouldn't it be?), then a <a href="http://c2.com/cgi/wiki?PragmaticProgrammer">PragmaticProgrammer</a> would create some sort of utility to handle the boilerplate... hopefully allowing the programmer to see a version closer to the one I show above. <em>cf. <a href="http://c2.com/cgi/wiki?MetaRefactoring">MetaRefactoring</a></em>
<p>
<hr>
<p>
I don't think you can call the second piece of code &quot;better&quot; in isolation.  It certainly does more.  If that additional functionality is required someplace else in the system then maybe it's better.  If not, why bother with it?  --<a href="http://c2.com/cgi/wiki?JohnBrewer">JohnBrewer</a>
<p>
<hr>
I tell a story about discovering the extremeness of DTSTTCPW at <a href="http://c2.com/cgi/wiki?SimplestVersusRight">SimplestVersusRight</a>.  -- <a href="http://c2.com/cgi/wiki?MitchellModel">MitchellModel</a>
<hr>
<p>
<a href="http://c2.com/cgi/wiki?TopicGlossaryXp">TopicGlossaryXp</a>, <a href="http://c2.com/cgi/wiki?XpToolsFaq">XpToolsFaq</a>
<p>
<hr>
<a href="http://c2.com/cgi/wiki?edit=DoTheSimplestThingThatCouldPossiblyWork">EditText</a> of this page (last edited March 19, 2001)<br>
<a href="http://c2.com/cgi/wiki?FindPage&value=DoTheSimplestThingThatCouldPossiblyWork">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>