📄 extremereuse.html
字号:
<head><title>Extreme Reuse</title></head><body><h1><img src="logo.gif"> Extreme Reuse</h1>When I first heard about XP, I wanted to try it. Being a C++ programmer, the first step involved porting <a href="KentBeck.html">KentBeck</a> and <a href="http://c2.com/cgi/wiki?ErichGamma">ErichGamma</a>'s JUnit to C++. I dubbed it <a href="http://c2.com/cgi/wiki?CppUnit">CppUnit</a>. Secondarily, I needed to figure out where I was going to start.
<p>I needed to add some new capabilities to my software. The new capabilities paralleled some capabilities that the software already had. My best bet was to develop the new capability, existing in parallel with the old, and slowly migrate it in (I've heard this called ArchitecturalSubstitution<a href="http://c2.com/cgi/wiki?edit=ArchitecturalSubstitution">?</a>). However, to get my feet wet, I started to test a few classes that were already there. I noticed immediately some coupling that I didn't like and I worked to get rid of it. After doing that, I started testing other classes that I had and each time I learned a little more about some entangled dependencies that were not really necessary. Although reality set in and I had to get back to adding the new capability, the lesson was not lost on me: <em>Even though it is better to write <a href="UnitTests.html">UnitTests</a> before you code, you can learn a lot about existing code by writing <a href="UnitTests.html">UnitTests</a> for it.</em>
<p>I got a bit more of this insight later. I was using a component that someone else had written and the source was not readily available. I had a spec sheet with the signatures of all of the component operations. I knew the guy who wrote it, and I'd used it in another context. To see how well it might serve me now, I started writing <a href="UnitTests.html">UnitTests</a> for it. Based upon that experience, I tend to think that reuse can be handled by writing <a href="UnitTests.html">UnitTests</a> for existing things, and by writing <a href="UnitTests.html">UnitTests</a> for adapters on existing things. The big question is "how much do I trust what I am reusing?" Trust can be based on many things, many of them outside of the code realm. Sometimes tests are not enough to instill reuse confidence. Sometimes they are.
<p>Now, is this type of reuse Simple? Or Easy? (see <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> and <a href="http://c2.com/cgi/wiki?SimpleIsntEasy">SimpleIsntEasy</a>). The decision to use a black box and adapter rather than writing something from scratch is significant. Adapters uglify code, but on the plus side, you didn't have to write the code, and you have test cases that tell you (you hope) enough to be able to use the component with confidence. Moreover, because <a href="UnitTests.html">UnitTests</a> can act as specifications (<a href="http://c2.com/cgi/wiki?UnitTestingIsDesign">UnitTestingIsDesign</a>), you can always revisit your decision later and rip out the adapted component... provided you replace it with something that keeps the tests running.
<p>-- <a href="http://c2.com/cgi/wiki?MichaelFeathers">MichaelFeathers</a>
<hr>
Even with access to the source code (white box?, opaque box?), writing experimental applications or <a href="UnitTests.html">UnitTests</a> seems a good idea -- the <a href="http://c2.com/cgi/wiki?ScientificMethod">ScientificMethod</a> as a learning tool. --<a href="http://c2.com/cgi/wiki?ScottJohnston">ScottJohnston</a>
<hr>
I would like to bring up something slightly different.
<p>Programming without the use of libraries and other components is not possible in any reasonable size project. So there is a codebase that you have to trust in. Sorry enough, most libraries ship without any test framework.
The question really is: How do you integrate existing or foreign code into your own code? Do you just use it and trust that it's bug free? I would say No.
How do you write the tests? And what tests do you write?
<p>Should I write <a href="UnitTests.html">UnitTests</a> for all library functions I want to use?
That would create a test framework for the library really, which is not my job. It is way too much work as well. And if I find a bug in the library, I often can't fix it anyways. (no source)
<p>Should I write replacement methods for the library I use to generate working <a href="UnitTests.html">UnitTests</a>?
Should I use Adapters to attach the library and insert some kind of test there?
<p>What do I do if my code breaks because of a used library?
Sometimes I can program a workaround, but that's not always possible.
<p>That are a lot of questions....
What are your ideas or experiences? -- <a href="http://c2.com/cgi/wiki?MalteKroeger">MalteKroeger</a>
<hr>
To <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> would be to use the library without testing it.
What's to be gained from doing a lot of testing on a 3rd party library that you cannot change?
<p>Now, once you start using a library and find a bug in it, you should...
<OL><li> report the bug to the vendor,
<li> work around the bug, and
<li> write a <a href="http://c2.com/cgi/wiki?UnitTest">UnitTest</a> that illustrates the bug.
</OL>The <a href="http://c2.com/cgi/wiki?UnitTest">UnitTest</a> is documentation; it reminds you that you have to keep working around the bug when writing new software and maintaining the existing code.
It also helps notify you when the vendor fixes the bug, and to verify that it is indeed fixed.
<p>This may not be <a href="ExtremeProgramming.html">ExtremeProgramming</a>, but it's what I do:
If you have the source code for the library, and find a bug, it might make sense for you to fix it yourself.
But you must be absolutely sure to...
<UL><li> Report the bug to the vendor.
<li> Make <a href="UnitTests.html">UnitTests</a> for the code you are about to change.
<li> Use a source code control system to keep track of the original source from the vendor, and your changes to it.
<li> Make the smallest change possible. (Yes, I know their <a href="CodeSmells.html">CodeSmells</a>, but you don't really want to take over their job and abandon all hope of accepting upgrades from them later, do you?)
</UL>The vendor will, eventually, release a new version of the library.
What are you going to do then?
You have to know <em>exactly</em> what changes you made, so that you can repeat them,
to fix the bugs that the vendor <strong>still</strong> hasn't bothered to fix.
<p>I don't like changing 3rd party code.
It's dangerous, and can easily get out of hand.
But sometimes you have no other reasonable options.
-- <a href="http://c2.com/cgi/wiki?JeffGrigg">JeffGrigg</a>
<hr>
<DL><dt> <dd>What's to be gained from doing a lot of testing on a 3rd party library that you cannot change?
<p></DL>The most obvious benefit is that it can save you from writing a lot of code to a library that ultimately proves to be unusable. Since you need to evaluate a third-party component before you invest a lot of time and money in it (unless the component has such a reputation that there is no question of its suitability for your project), why not conduct this evaluation in such way that it produces <a href="UnitTests.html">UnitTests</a> as a side effect? (It may not be cost-effective to product <a href="UnitTests.html">UnitTests</a> for the third-party component that are as comprehensive as <a href="UnitTests.html">UnitTests</a> one would write for code developed in-house, but it's still something. Technically, I suppose, that means they're not "<a href="UnitTests.html">UnitTests</a>" if they don't test the component completely but they are, uh, er, AlmostUnitTests<a href="http://c2.com/cgi/wiki?edit=AlmostUnitTests">?</a>, which, as pointed out elsewhere on this site, is another way of saying NotUnitTests<a href="http://c2.com/cgi/wiki?edit=NotUnitTests">?</a>. But they're still useful tests.)
<hr>
I totally agree with Jeff. But I wonder if XP encourages code reuse. When I always just <a href="DoTheSimplestThingThatCouldPossiblyWork.html">DoTheSimplestThingThatCouldPossiblyWork</a> it might be simpler to code a piece of software myself instead of understanding and using a 3rd party library. But in the "long" run, I will do better using the library. So where are those "long term" decisions in XP? -- <a href="http://c2.com/cgi/wiki?MalteKroeger">MalteKroeger</a>
<hr>
If I understand XP correctly, it does encourage reuse. <a href="http://c2.com/cgi/wiki?OnceAndOnlyOnce">OnceAndOnlyOnce</a> discourages rewriting existing functionality and if you <a href="RefactorMercilessly.html">RefactorMercilessly</a> you'll end up with a lot of code reuse. Coding a piece of software yourself might be easier than using a 3rd party library (or, for that matter, other pieces existing code) but I don't think it's the simplest thing that could possibly work (see <a href="http://c2.com/cgi/wiki?SimpleIsntEasy">SimpleIsntEasy</a> and discussion above). -- <a href="http://c2.com/cgi/wiki?OliverKamps">OliverKamps</a>
<hr>
How do you define software reuse? Is it using a fixed capability from many places? Is it branching the development of pre-existing code? Is it the factoring of object-oriented methods? Is it a combination of these and more? Under <a href="http://c2.com/cgi/wiki?EvolutionaryProgramming">EvolutionaryProgramming</a> <a href="RonJeffries.html">RonJeffries</a> said XP wasn't about maximizing software reuse, but about maximizing developer productivity. -- <a href="http://c2.com/cgi/wiki?ScottJohnston">ScottJohnston</a>
<hr>
I see it like this. If you're going to use a library API that you haven't used before, especially one of those Microsoft or Java APIs with the incomplete documentation, you will inevitably write little programs to see what the API actually does in the situation you need it. Why not write that into a test object? You'd then have a test to make sure that when the library changes, your API still works the way you expected. In fact, if we all did this a lot, then perhaps Microsoft's service packs would come out sooner with better beta testing. We'd just run our test suites to tell them if they got it right. -<a href="http://c2.com/cgi/wiki?JohnDuncan">JohnDuncan</a>
<hr>
In an exchange on the e-group on reuse <a href="http://c2.com/cgi/wiki?UncleBob">UncleBob</a> said he would import a previously used piece of code with its tests, <a href="KentBeck.html">KentBeck</a> said he would re-write it (the CharlesMoore<a href="http://c2.com/cgi/wiki?edit=CharlesMoore">?</a> Forth approach).
<hr>
The <a href="http://c2.com/cgi/wiki?SimplestThing">SimplestThing</a> for me is to choose a third-party library or component, rather than implement my own, <strong>if</strong> this component conforms to a well-known API, or an open standard, or otherwise avoids lock-in. I'm a big fan of XML as a result of that policy.
<p><hr><a href="http://c2.com/cgi/wiki?edit=ExtremeReuse">EditText</a> of this page (last edited October 17, 2000)<br><a href="http://c2.com/cgi/wiki?FindPage&value=ExtremeReuse">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 + -