📄 extremeprogrammingforone.html
字号:
<head><title>Extreme Programming For One</title></head><body><h1><img src="logo.gif"> Extreme Programming For One</h1><strong>Scenario</strong>
<p>A lone software developer is working on several small to medium scale
projects. He needs to increase his productivity and resilience. While
his management are amicable and approachable, they tend to frown on
"over-designing" a system, since it is "liable to change in the
future anyway".
<p>This programmer has been using patterns with Java for a while, but he
has no techie colleagues to pair with, and very limited contact with the
end users. Requirements tend to "appear" at any time. The management
seem to accept that and the resultant geometric increase in effort
needed to add to and maintain the design/code.
<p>Can XP help?
<p><hr>
See also: <a href="ExtremeProgrammingChallenge.html">ExtremeProgrammingChallenge</a> <em>(source of this discussion)</em>,
<a href="http://c2.com/cgi/wiki?ExtremeHacking">ExtremeHacking</a> <em>(controversial alternate name for this?)</em>
<hr>
<p>I hope you all don't mind this rather personal scenario (I admit
that I am the programmer in question), but I think that any answers
may be applicable to a wide range of loners and lurkers whose
interest is piqued by XP. --<a href="http://c2.com/cgi/wiki?DavidMcNicol">DavidMcNicol</a>
<p><hr>
<p>We'll be glad to help! Here's a first cut. Other XP masters and observers, please pitch in!
<p>XP does not believe that there is a "resultant geometric increase in effort" as a result of change. XP is built to thrive on change. Requirements appear and change at any time. Here's a short summary of how that happens.
<p>We plan the entire project based on <a href="http://c2.com/cgi/wiki?UserStories">UserStories</a>, using the <a href="http://c2.com/cgi/wiki?CommitmentSchedule">CommitmentSchedule</a> to describe the overall plan. We plan our work in (three-week) iterations, using an <a href="http://c2.com/cgi/wiki?IterationPlan">IterationPlan</a> to say what we're going to do. We build our code using <a href="PairProgramming.html">PairProgramming</a> (this one is tricky for one person). The <a href="FunctionalTests.html">FunctionalTests</a>, of course, tell us whether we're done.
<p>We <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a>. This means that we do not build for needs we might have in the future: we accept that we can't guess, so we don't waste time doing it.
<p>To allow for future change, we <a href="RefactorMercilessly.html">RefactorMercilessly</a>. We keep the code as simple as possible, which means that after we put in a simplest solution, we refactor the code to do everything <a href="http://c2.com/cgi/wiki?OnceAndOnlyOnce">OnceAndOnlyOnce</a>, which is a simple description of what you get when behavior is all on the right objects and the code is in the simplest rest state for what it does.
<p>We ensure that refactoring changes and new features work by <a href="http://c2.com/cgi/wiki?RelentlessTesting">RelentlessTesting</a> of each class with <a href="UnitTests.html">UnitTests</a> and of the entire system in operation using <a href="FunctionalTests.html">FunctionalTests</a> for <a href="http://c2.com/cgi/wiki?FunctionalTesting">FunctionalTesting</a>. This lets us be sure that the changes we make don't break things that already work, and that our new functionality works as well.
<p>We keep the system working all the time via <a href="ContinuousIntegration.html">ContinuousIntegration</a> (see also <a href="ContinuousIntegrationRelentlessTesting.html">ContinuousIntegrationRelentlessTesting</a> for some further discussion of how these work together).
<p>Wow. Remind me to save this description. Anyway, if I were working alone I could do all these things (except pair programming). Maybe that one could be substituted with some kind of review process with peers on the web or in the community.
<p><em>The pair programming partner doesn't have to be a programmer. You don't need to be an expert to say, "Did you run the test?" every five seconds or so. Kids could work well as programming partners.</em>
<p>Here's how I'd try to work:
<p>Get small, simple descriptions, on cards, of the known requirements. From those, select, with whatever guidance you can get, the next feature to be added. Think of the simplest way to put it in. Write <a href="UnitTests.html">UnitTests</a> to see whether it works. (Usually it doesn't.) Write the code in the simplest possible way. Run the tests, make it work. Then refactor the code to keep the system at its overall simplest. Report the card as done. Go on to the next.
<p>The keys would be simplicity and testing. The keys are always simplicity and testing. --<a href="RonJeffries.html">RonJeffries</a>
<hr>
I can't help thinking that the above includes a bit of sloganizing. Notice the original poster mentioned very little end-user contact. The reply didn't seem to address that (even though the essence of XP is said to be listening).
Sure I would say that <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> essentially does address the situation (if it's similar to the ones I've seen). But the whole article isn't addressing the question very directly. I think another simple XP answer to the original question might have been simply "relax and learn to enjoy programs designed only as much as is appropriate for the moment."
I suspect that complex design methodologies are something of a siren song to many programmers - where XP seems involve a sensible method of designing only to the degree you've coded, discovered what to do, etc.. Again <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a>. There, that is the part you want.
<p>But in general, I'd also say meet your users. Even if you have sneak and do it. It gives you an idea where things will ultimately go.
<p>I've had assignments where not only is an "exponential increase in effort" accepted, it was so expected that if it didn't happen, something was considered wrong. My war story involved a situation where I knew the user requirements, designed the solution to these early, then had to duck and dodge changing management requirements - which I happened to know wouldn't last.
<p>I think a bare-bones design philosophy - architecting only as much as needed designing at the moment while secretly figuring what they really wanted - allowed me to do something that amazed people ultimately - actually completing the project before it was due.
<p>--JoeSolbrig<a href="http://c2.com/cgi/wiki?edit=JoeSolbrig">?</a>
<p><hr>
<p>I have been typing in responses here for the past half-hour, and things
have been clicking into place (thanks, Ron). I think my main worry about
XP stems from my programming environment: jdk, unix and vi. Even though
I can see the value of XP, constantly refactoring from the command line
seems like a daunting task.
--<a href="http://c2.com/cgi/wiki?DavidMcNicol">DavidMcNicol</a>
<p>On your environment: try vim and exuberant-ctags from <a href="http://www.vim.org">http://www.vim.org</a> . This should make all that refactoring a lot easier to do - fun even. Vim is free, entirely backwards-compatible with vi, and vastly more powerful. Exuberant-ctags gives you the ability to flit from use to declaration without ever leaving the editor or doing a grep. Very good for flow, much better than some clunky IDE. --<a href="http://c2.com/cgi/wiki?PeterMerel">PeterMerel</a>
<p>That URL isn't responding at the moment, but you can try
<a href="http://www.math.fu-berlin.de/~guckes/vim/">http://www.math.fu-berlin.de/~guckes/vim/</a> instead. -- <a href="http://c2.com/cgi/wiki?DavidMcNicol">DavidMcNicol</a>
<p>I use JDK, Unix, and wily (see the <a href="http://c2.com/cgi/wiki?AcmeProgrammingEnvironment">AcmeProgrammingEnvironment</a>), and I have found <a href="ExtremeProgramming.html">ExtremeProgramming</a> (for one) to be a real blast. Wily works well with the way the JDK prints out exceptions -- the "should" and "shouldEqual" methods of my testing framework throw a ShouldButDid<a href="http://c2.com/cgi/wiki?edit=ShouldButDid">?</a> exception when the test fails; the point the test failed is then just a click away. For the first time in a long time, I feel like I am writing code with confidence that it will actually work....
<p><hr>
<p>When I'm by myself, I don't separate <a href="http://c2.com/cgi/wiki?UserStory">UserStory</a>'s and <a href="http://c2.com/cgi/wiki?EngineeringTask">EngineeringTask</a>'s (I generally work as both Business and Development when I program alone). I keep a <a href="http://c2.com/cgi/wiki?ToDoList">ToDoList</a>, either on a card or in a workspace. Every time I think of something else I might like to do, I add it to the list. The list grows and shrinks, but tends to grow over time.
<p>After a while, I know I am getting close to a useful release-able system, so I draw a line. I go through the list and put items below the line that don't need to be in the release. When I create new items, I decide whether they go above the line or below. When there is nothing above the line, I'm ready to release.
<p>It is important for me to always be working towards an item on the list. If I am just refactoring for fun, I stop myself and ask whether I am contributing to an item. If not, I set myself a time limit and play.
<p>The real question is how much less than XP you can do if you are alone. I think the planning stuff scales down nicely. You have to test and refactor. You can't pair. What else less could you do? --<a href="KentBeck.html">KentBeck</a>
<p>Another trick -- if you keep the list on a card, when the card fills up you copy all the undone items to a new card. If there is something little, I tend to just do it rather than copy it. This keeps the little stuff from piling up. --kb
<p>I do something similar, but I keep the stuff in text files because otherwise I think I'd lose it. I use the marker "XXX", which comes up in a nice egg-yellow under vim, to indicate little things that need to be nailed down as I go; I also keep a ToDo<a href="http://c2.com/cgi/wiki?edit=ToDo">?</a> section in major class headers and delete items as they get done. I confess I haven't tried to share such ToDo<a href="http://c2.com/cgi/wiki?edit=ToDo">?</a> lists with other developers - they're more notes to myself than any sort of documentation for others to see. Probably a sign of insecurity. --<a href="http://c2.com/cgi/wiki?PeterMerel">PeterMerel</a>
<p><em>Especially when writing open source, the tag "XXX" tends to have problems. I prefer using "FARKLE" or "TODO". The problem with XXX is, in today's environment, your source code can be flagged as "unsafe for children" by automatic site blockers...</em>
<p><hr>
<p>Note that Kent is working as both business and development when working alone, and he is extremely experienced at working alone. I'd strongly advise a normal human to be a bit more orderly:
<p><OL><li> Break down your <a href="http://c2.com/cgi/wiki?UserStory">UserStory</a>'s (requirements) into <a href="http://c2.com/cgi/wiki?EngineeringTask">EngineeringTask</a>'s, which will help you focus on how little you can do, and will help you not think about the future.
<li> Always have a releasable system, not just when you get close to some major increment of function. To accomplish this, work in small bites, release often, and keep all your tests running at 100% all the time. Then when the PTB want a release, they can always have your best.
<p></OL>I don't agree that the question is how much less you can do. I think the question is how much of XP's benefit can you get, and what's the most effective way to get it.
<p>Certainly you don't need to hold an <a href="http://c2.com/cgi/wiki?IterationPlanning">IterationPlanning</a> meeting with yourself ... but it would be valuable to identify your tasks and estimates and track your performance against estimates. This will help you identify things that slow you down, time-wasters, etc.
<p>You may or may not need a <a href="http://c2.com/cgi/wiki?CommitmentSchedule">CommitmentSchedule</a>. Depends whether you need to communicate with the boss what you're going to work on, and how long it will take. If they want to set and change your priorities often, having the stories on cards will be a good way to communicate and track.
<p>All the coding rules, except Pairing, apply. All the testing applies, more than ever because you don't have a partner to catch you when you stumble.
<p>Ask not how little you can do ... ask how you can best benefit. --<a href="RonJeffries.html">RonJeffries</a>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -