On Thu, Sep 07, 2000 at 01:49:36PM -0400, Peter Allen wrote:
> They have a catchy slogan for it. They call it the
>
> test --> code --> design
>
> development cycle.
That sounds bad. I've heard about this style. Code now, refactor
later. Its supposed to avoid the need for sweeping architectural
decisions early in the project, allow you to recover from bad design
decisions and return flexibilty to old code.
It may be good for rapid development projects, but I don't think we
should apply it to Perl. We have a very good idea of what our
requirements are (especially compared to most software out there), a
solid prototype to work from (perl 5), and some very solid ideas of
what the architecture should be. Furthermore, I don't think there are
any refactoring tools for C. I've only heard of them for Java and
Smalltalk (maybe C++).
> Of course, the design phase is characterized exclusively as
> 'refactoring'...
For the record...
"Refactoring" is only one tool used in that design philosophy.
Unfortunately, its apporaching buzzword status lately and the
test->code->design approach you mentioned and the technique of
refactoring are kind of ooozing together in the public's perceptions.
I'd like to point out that they are seperate entities.
Refactoring is simply the automated alteration of code without
effecting its purpose. A simple example would be reversing the order
of arguments in a subroutine. A refactoring tool would be able to do
this for you automatically and in all code which uses that subroutine.
Handy. It does this by defining a set of simple operations which a
refactoring tool must be able to perform. From those simple
operations, it can do much more complicated things.
Unfortunately, Perl's dynamic nature makes most refactoring
impossible. Furthermore, refactoring loses much of its power when
applied on Open Source libraries since you are no longer in control of
all code which uses said library. In a controled environment, you can
alter interfaces to your heart's content. With Open Source, if you
alter a function's interface you may break the code of hundreds of
programs.
Still, it has its uses and can be helpful in localized parts of the
code. I've been going through the catalog of refactorings and trying
to determine what can currently be done in Perl and how much change in
Perl it would take to reimplement the rest. It doesn't look good, but
I'll publish what I've got once its complete.
Martin Fowler wrote a book "Refactoring: Improving the Design of
Existing Code"
http://www.refactoring.com/
Bill Opdyke's original thesis paper on the subject is here
ftp://st.cs.uiuc.edu/pub/papers/refactoring/
> Also, don't you want to refer more to 'unit tests', rather than
> regression testing
<snip>
They could be called "Mr. Wosabe tests" for all I care. Terminology
was never my strong point (above rant is the rare occasion). :)
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Work like hell, tell everyone everything you know, close a deal with
a handshake, and have fun.
-- Harold "Doc" Edgerton
