Home > Archive > Lisp > June 2005 > Agility sucks [Was: How long should a function be?]
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Agility sucks [Was: How long should a function be?]
|
|
|
| Christopher C. Stacy wrote:
> Or maybe I'm missing the point of this "agile" stuff?
> As far as I can tell, it's just some hype about a cookbook of
> recommendations for coping with incomplete and changing specifications.
If the specs don't change, "Agile" is still useful. As a design technique,
it finds a path towards a good design, where each step on that path is also
a good design that could be deployed and used.
The "non Agile" or "Agile is bad for Project X" idea is the idea that
certain projects must be designed in the absense of feedback. Don't delay
feedback - that's dangerous.
> Then you can go back and "refactor" (I hate that buzzword)
Deal. You refactor, just a little, continuously. That lowers the odds you'l
need a big refactor.
--
Phlip
[url]http://www.c2.com/cgi/wiki?Z Land[/url]
| |
| Christopher C. Stacy 2005-05-30, 8:57 pm |
| "Phlip" <phlip_cpp@yahoo.com> writes:
> Christopher C. Stacy wrote:
>
>
> If the specs don't change, "Agile" is still useful. As a design technique,
> it finds a path towards a good design, where each step on that path is also
> a good design that could be deployed and used.
>
> The "non Agile" or "Agile is bad for Project X" idea is the idea that
> certain projects must be designed in the absense of feedback. Don't delay
> feedback - that's dangerous.
>
>
> Deal. You refactor, just a little, continuously. That lowers the odds you'l
> need a big refactor.
I don't mean that I hate "refactoring", I mean that I think its
silly to have invented that buzzword to describe what's going on there.
The programming techniques described by the "agile" crowd are
just what some people have been doing for decades (only without
the buzzaords). I suppose it's nice that someone write a book
telling people something aout how to program computers, after
all this time. It just scares me to wonder that it was needed,
that's all.
| |
| Peter Seibel 2005-05-30, 8:57 pm |
| cstacy@news.dtpq.com (Christopher C. Stacy) writes:
> "Phlip" <phlip_cpp@yahoo.com> writes:
>
> I don't mean that I hate "refactoring", I mean that I think its
> silly to have invented that buzzword to describe what's going on
> there.
Hmmm. What was the "real" word that "refactor" is a buzzword for?
-Peter
--
Peter Seibel peter@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
| |
|
| Christopher C. Stacy wrote:
> I don't mean that I hate "refactoring", I mean that I think its
> silly to have invented that buzzword to describe what's going on there.
What's silly is changing the design of code at the same time as changing its
behavior. Explicitely doing only one or the other constrains your changes.
Hence, make a word for changing design while leaving behavior the same.
> The programming techniques described by the "agile" crowd are
> just what some people have been doing for decades (only without
> the buzzaords).
Sorry - here's why one as brain-damaged as me _needs_ those buzzwords.
Before those peesa-shit drippy fru-fru XP books came out, I tried _very_
hard to learn the good process that people had been doing for decades. What
I got were books like Booch's Orange book, which was incredibly unreadable.
These books said blah-blah-blah, and made both me and many people I worked
with think they were promoting pure Waterfall. (And I also failed to miss
the concept of virtual methods from reading that specific book, too!)
Don't let my playful self-deprecating attitude fool you - I am a _very_ good
reader. Anything from the Notebooks of Leonardo DaVinci to the Sirens of
Titan by Kurt Vonnegut, Jr...
> I suppose it's nice that someone write a book
> telling people something aout how to program computers, after
> all this time. It just scares me to wonder that it was needed,
> that's all.
What was needed was to say "do this, at this time, call it this, stop when
you get this". What was needed was a description of a healthy lifecycle,
from beginning to end, with a name for each component of that cycle, and
each component described at the necessary scale.
Some people started their careers and got lucky; they fell in with the right
team, under the right guru. Some did not, hence we need books on this topic.
Lots of them.
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
|
| Peter Seibel wrote:
> Hmmm. What was the "real" word that "refactor" is a buzzword for?
Here's how to cause lots of rework. Collect many requirements, then design
them all, then release them all. When you surprise the customer and get
change requests, you may need to edit some requirements. That requires
redesign, etc. This is an example of process waste.
Was that the word you were (smugly) thinking of?
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| Pascal Costanza 2005-05-30, 8:57 pm |
| Christopher C. Stacy wrote:
> The programming techniques described by the "agile" crowd are
> just what some people have been doing for decades (only without
> the buzzaords). I suppose it's nice that someone write a book
> telling people something aout how to program computers, after
> all this time. It just scares me to wonder that it was needed,
> that's all.
The practices described in Kent Beck's book about Extreme Programming
are described in a pattern-like form. That is, like in patterns as
discovered by Christopher Alexander (and abused in the well-known Design
Patterns book).
The good thing about patterns is a) that they describe well-known
working solutions to recurring tasks and b) that they can explain why
things work in non-obvious ways. (Design Patterns are vey boring in that
regard.)
Patterns are by definition highly unoriginal. If your reaction is that
they are obvious, then they are probably correct. However, patterns give
you a language to talk about what you do.
Furthermore, what's obvious to you may not be obvious to others.
Aggressive code refactoring without asking other programmers involved in
a project sounds highly dangerous to the uninitiated. It's good to know
how that danger is compensated for by other techniques.
The problem with XP and agile methodologies is that people have started
to use them without reflecting about them. This will create the same
problems like any other development process.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
| |
|
| Pascal Costanza wrote:
> The problem with XP and agile methodologies is that people have started
> to use them without reflecting about them. This will create the same
> problems like any other development process.
The book /Agile & Iterative Development: A Manager's Guide/ by Craig Larman
contains an amazing statistic. The more closely a team tried to follow
Waterfall, the more likely they were to fail.
I'm not so worried about folks following XP practices without reflecting on
them. Everyone get in the same room, and hit the test button after 1~10
edits. What's to reflect on?
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| Christopher C. Stacy 2005-05-30, 8:57 pm |
| "Phlip" <phlip_cpp@yahoo.com> writes:
> Sorry - here's why one as brain-damaged as me _needs_ those buzzwords.
> Before those peesa-shit drippy fru-fru XP books came out, I tried _very_
> hard to learn the good process that people had been doing for decades. What
> I got were books like Booch's Orange book, which was incredibly unreadable.
What do they teach in school?
| |
| Christopher C. Stacy 2005-05-30, 8:57 pm |
| Pascal Costanza <pc@p-cos.net> writes:
> Furthermore, what's obvious to you may not be obvious to others.
It's only obvious to me with a lifetime of hindsight, but I was
imagining (wildly?) that these sorts of practices were the
standard fare in undergraduate study of computer programming.
The fact that there are popular press books about it,
and hype and buzzwords, suggests otherwise,  ly.
| |
| Peter Seibel 2005-05-30, 8:57 pm |
| "Phlip" <phlip_cpp@yahoo.com> writes:
> Peter Seibel wrote:
>
>
> Here's how to cause lots of rework. Collect many requirements, then
> design them all, then release them all. When you surprise the
> customer and get change requests, you may need to edit some
> requirements. That requires redesign, etc. This is an example of
> process waste.
Yes. Though I'm not sure why you're telling me.
> Was that the word you were (smugly) thinking of?
Huh? I'm not thinking of any word. I'm asking Christophe. He's the one
who called "refactor" a buzzword. I personally think "refactor" is a
fine word than names a concept (making changes to software that don't
affect it's functionality but do improve it's internal quality) that
deserves to have its own name.
-Peter
--
Peter Seibel peter@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
| |
|
| > > Was that the word you were (smugly) thinking of?
>
> Huh? I'm not thinking of any word.
Sorry; I'm a little sensitive today.
Christophe just meant that a project should flow and not give names to the
various aspects of that flow.
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| Paul Sinnett 2005-05-31, 4:00 am |
| Peter Seibel wrote:
> Hmmm. What was the "real" word that "refactor" is a buzzword for?
Rewrite.
| |
| Peter Seibel 2005-05-31, 4:00 am |
| Paul Sinnett <paul_sinnett@yahoo.co.uk> writes:
> Peter Seibel wrote:
>
> Rewrite.
I'm not sure that captures the notion of explicitly *not* changing the
functionality. You might say, "this program doesn't have the feature's
I need--I'm going to rewrite it". But you wouldn't say the same thing,
replacing "rewrite" with "refactor". Similarly, "refactor" importantly
implies that one is proceeding in small steps such that the program's
functionality is the same after each step--the program is never "in
pieces all over the floor" the way a program in the midst of being
rewritten often is.
-Peter
--
Peter Seibel peter@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
| |
|
| Peter Seibel wrote:
> Paul Sinnett writes:
>
>
> I'm not sure that captures the notion of explicitly *not* changing the
> functionality. You might say, "this program doesn't have the feature's
> I need--I'm going to rewrite it". But you wouldn't say the same thing,
> replacing "rewrite" with "refactor". Similarly, "refactor" importantly
> implies that one is proceeding in small steps such that the program's
> functionality is the same after each step--the program is never "in
> pieces all over the floor" the way a program in the midst of being
> rewritten often is.
It's difficult to under-emphasize the importance of that last point. No
matter how big the refactor - from one design to the other - the program is
never too far away from a state where it can be integrated, featurized,
deployed, or delivered. If the tests don't care, the customer doesn't care
that an executable came from source with half one design and half another.
Rewrite don't mean that. It means you go back before going forward again.
Halfway thru a rewrite, you have no deliverable.
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| Kenny Tilton 2005-05-31, 9:10 am |
|
Peter Seibel wrote:
> Paul Sinnett <paul_sinnett@yahoo.co.uk> writes:
>
>
>
>
> I'm not sure that captures the notion of explicitly *not* changing the
> functionality.
uh-huh, but "rewrite" has bigger problems than that. It is simply wrong,
conveying nothing of the specifics in mind when the term refactoring
caught on. It is a superset kinda thang, like saying "motion" is an
adequate substitute for "hopscotch". Refactoring means reshuffling
existing code, usually deleting some code no longer necessary because of
the design improvement.
Is that a rewrite? Sure, and hopscotch is motion.
How about "reorganize"? That is what companies call their upheavals
(also usually involving deletions).
kt
| |
| Marco Antoniotti 2005-05-31, 4:01 pm |
|
Paul Sinnett wrote:
> Peter Seibel wrote:
>
>
>
> Rewrite.
Perestrojca :)
Cheers
--
Marco
| |
|
|
|
| Marco Antoniotti wrote:
>
> Perestrojca :)
Did that pass its tests?
If not, did they undo their changes and start again?
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| Paul Sinnett 2005-05-31, 8:58 pm |
| Peter Seibel wrote:
> Paul Sinnett <paul_sinnett@yahoo.co.uk> writes:
>
> I'm not sure that captures the notion of explicitly *not*
> changing the functionality. You might say, "this program
> doesn't have the feature's I need--I'm going to rewrite it".
You might. But how are you going to re-write something that has
yet to be written (ie. the new features)?
The reason, I think, that the term "refactor" evolved, was to
distinguish what a writer means by re-write and what, for
example, a Hollywood exec. means: the latter being somewhat
ironic. What they mean is "we didn't like your story so we wrote
one of our own and cut and pasted some of your dialogue /
characters / scenes into it..."
The problem with trying to distinguish using the new term is that
it will be used in exactly the same way by exactly the same type
of insincere persons. "I refactored your function," meaning... I
think you can guess what it might mean.
I think of re-writing in the Hemingway sense:
Paris Review: How much rewriting do you do?
Hemingway: It depends. I rewrote the ending to A Farewell To
Arms, the last page of it, thirty-nine times before I was
satisfied.
Paris Review: Was there some technical problem there? What was
it that stumped you?
Hemingway: Getting the words right.
| |
| Peter Seibel 2005-05-31, 8:58 pm |
| Paul Sinnett <paul_sinnett@yahoo.co.uk> writes:
> Peter Seibel wrote:
>
> You might. But how are you going to re-write something that has yet
> to be written (ie. the new features)?
The program has already been written (without certain features). Now
it can be rewritten (possibly with those features). What's the
problem?
> The reason, I think, that the term "refactor" evolved, was to
> distinguish what a writer means by re-write and what, for
> example, a Hollywood exec. means: the latter being somewhat
> ironic. What they mean is "we didn't like your story so we wrote
> one of our own and cut and pasted some of your dialogue /
> characters / scenes into it..."
Hmmm. Speaking with my writer's hat on when I say I'm going to
/rewrite/ something I usually mean I'm going to throw away what I've
got and start over from scratch. However if I said I was going to
/revise/ something, then that'd imply something more like what I do
when I refactor code. However I still think "refactor" has a stronger
implication of of "not changing the functionality" than "revise" does.
> The problem with trying to distinguish using the new term is that it
> will be used in exactly the same way by exactly the same type of
> insincere persons. "I refactored your function," meaning... I think
> you can guess what it might mean.
Well, just because people tend to ignore nice distinctions of meaning
(particularly when looking for euphemisms to describe their own
behavior) doesn't mean that there's no distinction to be made.
-Peter
--
Peter Seibel peter@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
| |
| Paul Sinnett 2005-06-01, 8:58 pm |
| Peter Seibel wrote:
> Hmmm. Speaking with my writer's hat on when I say I'm going to
> /rewrite/ something I usually mean I'm going to throw away
> what I've got and start over from scratch.
The equivalent method in refactoring is named "substitute
algorithm". If the new code fails to carry out some important
function of the original, then it's not a viable substitute. It's
also not a viable rewrite - for the same reason.
> However if I said I was going to /revise/ something, then
> that'd imply something more like what I do when I refactor
> code.
My understanding of /revise/ in this context is to change or
correct the meaning of something. I hope that's not what you had
in mind since it's not even close to the originally intended
meaning of refactoring.
> just because people tend to ignore nice distinctions of
> meaning (particularly when looking for euphemisms to describe
> their own behavior) doesn't mean that there's no distinction
> to be made.
I agree. But the same can be said of write, rewrite, and revise:
write ~ say something ~ code
rewrite ~ say the same thing a different way ~ refactor
revise ~ say something else ~ debug or modify
| |
| Ron Jeffries 2005-06-04, 8:57 pm |
| On Tue, 31 May 2005 07:12:06 +0200, Paul Sinnett
<paul_sinnett@yahoo.co.uk> wrote:
>Peter Seibel wrote:
>
>Rewrite.
Ah, but refactor isn't rewrite.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Paul Sinnett 2005-06-05, 8:56 am |
| Ron Jeffries wrote:
>
> Ah, but refactor isn't rewrite.
Is.
| |
| Arafangion 2005-06-05, 8:56 am |
| Paul Sinnett wrote:
> Ron Jeffries wrote:
>
>
>
> Is.
imho, refactoring *is* rewriting, but not necessarily all of an app.
In general, one aims to change the design a bit while modifying the code
as little as possible.
| |
| Tim Josling 2005-06-05, 8:56 am |
| Ron Jeffries wrote:
> On Tue, 31 May 2005 07:12:06 +0200, Paul Sinnett
> <paul_sinnett@yahoo.co.uk> wrote:
>
>
>
>
> Ah, but refactor isn't rewrite.
>
People used to talk about "cleaning up" code. Now they talk about
refactoring.
Tim Josling
| |
| Pascal Costanza 2005-06-05, 8:56 am |
| Tim Josling wrote:
> Ron Jeffries wrote:
>
>
> People used to talk about "cleaning up" code. Now they talk about
> refactoring.
"Cleaning up" is probably quite close. "Refactoring" has gotten the
specific meaning that a program doesn't change its behavior under a
refactoring, in the sense that all the tests of a test suite work as
before. It's possible to formalize this notion by providing
preconditions and postconditions under which a refactoring is
applicable. This in turn allows you to have automatic or semi-automatic
tool support. So, for example, you can move a method down an inheritance
hierarchy if all call sites call it through a respective subclass anyway
(that's the precondition). There are some limitations when your language
supports reflective calls, but in general this seems to work quite well.
As far as I can tell, this specific notion of "refactoring" is
relatively new.
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
| |
| Kenny Tilton 2005-06-05, 8:56 am |
|
Tim Josling wrote:
> Ron Jeffries wrote:
>
>
>
> People used to talk about "cleaning up" code. Now they talk about
> refactoring.
I can refactor perfect code, but I cannot clean it up.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
| |
| Paul Sinnett 2005-06-05, 8:56 am |
| Pascal Costanza wrote:
> Tim Josling wrote:
>
> "Cleaning up" is probably quite close.
Yes. "Cleaning up" is also close to rewriting as writers use it
in the saying "writing is rewriting."
But if you step over into correcting errors then you're no longer
refactoring: you're debugging. Similarly you're no longer
rewriting: you're revising. In both cases you are changing the
literal meaning of the text.
> "Refactoring" has gotten the specific meaning that a program
> doesn't change its behavior under a refactoring, in the sense
> that all the tests of a test suite work as before. It's
> possible to formalize this notion by providing preconditions
> and postconditions under which a refactoring is applicable.
> This in turn allows you to have automatic or semi-automatic
> tool support.
There is some (very limited at the moment) semi-automatic support
for this in writing tools too. The main difficulty with such
tools is the flexibility of natural language in comparison with
programming languages. However, this is a difference of scale.
Most programming languages also share this feature to a lesser
degree. Somewhere in a programming language definition, you
will find the phrase "the result of this is undefined." A good
tool could present the user with several well defined (but not
necessarily compatible) alternatives.
> As far as I can tell, this specific notion of "refactoring" is
> relatively new.
The word refactoring is relatively new. The origin of the word is
somewhat hazy. But the idea of changing style without changing
content; changing form without changing function; changing
presentation without changing meaning, is so old that it has been
embodied in sayings, maxims, and proverbs. This idea is also
a fundamental part of mathematics (where the 'factor' part comes
from.) The meaning of refactoring will (over time) be defined by
how people use the term and people are generally using the term
as a buzzword for rewriting.
http://www.irregularwebcomic.net/cg...ic.pl?comic=687
However, the idea of inventing a word to make some precise
distinction is also not new. Here is what the other Fowler
wrote about that in 1908:
> Among other arts and sciences, that of lexicography happens to
> have found convenient a neologism that may here be used to
> help in the very slight classification required for the new
> words we are more concerned with—that is, those whose object
> is literary or general, and not scientific. A 'nonce-word'
> (and the use might be extended to 'nonce-phrase' and
> 'nonce-sense'—the latter not necessarily, though it may be
> sometimes, equivalent to nonsense) is one that is constructed
> to serve a need of the moment. The writer is not seriously
> putting forward his word as one that is for the future to have
> an independent existence; he merely has a fancy to it for
> this once. The motive may be laziness, avoidance of the
> obvious, love of precision, or desire for a brevity or
> pregnancy that the language as at present constituted does not
> seem to him to admit of. The first two are bad motives, the
> third a good, and the last a mixed one. But in all cases it
> may be said that a writer should not indulge in these unless
> he is quite sure he is a good writer.
--
H.W. Fowler (1858–1933). The King’s English, 2nd ed. 1908.
http://www.bartleby.com/116/103.html
| |
| Stefan Ram 2005-06-05, 3:57 pm |
| Pascal Costanza <pc@p-cos.net> writes:
>"Cleaning up" is probably quite close. "Refactoring" has gotten
>the specific meaning that a program doesn't change its behavior
>under a refactoring, in the sense that all the tests of a test
>suite work as before.
In school, I learned the notion "equivalence transformation"
for something similar.
While teaching programming languages and before ever having
heard of "refactoring", I got the idea, that teaching should
involve teaching and exercising common equivalence
transformations, such as
( if c x y )
is (often or always?) equivalent to
( if( not c )y x )
Possibly a set of such transformations can even be used
to define the semantics of a programming language to some
extend.
| |
|
| Kenny Tilton wrote:
> I can refactor perfect code, but I cannot clean it up.
The clean spot moves over time. What worked today might not be good enough
tomorrow.
> "If you plan to enter text which our system might consider to be
> obscene, check here to certify that you are old enough to hear the
> resulting output." -- Bell Labs text-to-speech interactive Web page
And the odds this will reduce our lawsuit exposure from irrate parents is..?
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| Kenny Tilton 2005-06-05, 3:58 pm |
|
Phlip wrote:
> Kenny Tilton wrote:
>
>
>
>
> The clean spot moves over time. What worked today might not be good enough
> tomorrow.
My point was that "cleaning up" cannot be a synonym for refactoring,
because sometimes I have a very nice function which I eventually
discover contains some subprocessing which is desirable as a standalone
function, or undesirable in calls by a new client. Then I take what had
been a prime to my mind and factor it, such that the original function
now takes a new parameter (to suppress the subprocessing) or it now
calls a new function to do the subprocessing, which new function is now
available to clients.
That is not cleaning up.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
| |
|
| So if refactoring is doing the factoring again, what was the
original factoring? In mathematics, we speak of factoring,
but I cannot recall anyone deliberately using the term,
refactoring. I suppose we do refactor in mathematics,
but we usually simply do a continuous process of factoring.
So, how is refactoring different from continuous factoring?
It seems to me that those who speak of refactoring are actually
talking about continually simplifying the code, making modules
more cohesive, where appropriate, and getting control over
coupling issues. So, refactoring is probably just a process of
managing the cohesion and coupling of the code. This is not
particularly new. We have been doing it from the beginnings
of software. It is nice, I suppose, to have a special term for
it, though the choice of the word seems a little strange to me.
Richard Riehle
| |
| Kenny Tilton 2005-06-06, 8:57 am |
|
adaworks@sbcglobal.net wrote:
> So if refactoring is doing the factoring again, what was the
> original factoring? In mathematics, we speak of factoring,
> but I cannot recall anyone deliberately using the term,
> refactoring.
It is just a metaphor. An agile programmer tackles a problem by tossing
off some reasonable code. They do not spend eighteen months collecting
requirements to determine all and every bit of functionality hence code
required. (In vain, I think we all know by now.) They get away with this
if they are using an agile language such as Common Lisp, which lets you
change a class hierarchy while a program is running and then continue,
as when a backtrace occurs and one realizes, doh!, I need this behavior
(but not that) from this other superclass. OK, it is not /that/ hard to
quit and restart, but it is a blast being able to slice and dice the
class hierarchy and then retry a function call with existing instances
of the affected classes. And, more relevantly, it is nice not having to
sit through a massive recompile/link of every line of code extant.
--
Kenny
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"If you plan to enter text which our system might consider to be
obscene, check here to certify that you are old enough to hear the
resulting output." -- Bell Labs text-to-speech interactive Web page
| |
|
| Kenny Tilton wrote:
>
> adaworks@sbcglobal.net wrote:
>
> It is just a metaphor.
Of course I agree with you in spirit, but I "need" to bust on your verbiage
here.
"Refactor" is absolutely not a metaphor, it is a distinction. That's a
definition that continuously and unambiguously separates two groups. Any two
software engineers who know the definition (regardless whether they agree
with it) can observe a third engineer and determine if they are Refactoring
or not. The two will always reach the same conclusion, in isolation from one
another. Okay, now she's adding new code. Okay, now she's refactoring it.
> An agile programmer tackles a problem by tossing
> off some reasonable code.
For the newbs: "...with the _intent_ to refactor it, very soon. The
reasonable code is in a state ready to be refactored."
Some methodologies cut a design, and then debug until the behavior is right.
We test-first behavior, then refactor until the design is better. Nailing
down the behavior first, then drawing the lines of control together under
test, improves bug resistance.
> They do not spend eighteen months collecting
> requirements to determine all and every bit of functionality hence code
> required. (In vain, I think we all know by now.) They get away with this
> if they are using an agile language such as Common Lisp, which lets you
> change a class hierarchy while a program is running and then continue,
> as when a backtrace occurs and one realizes, doh!, I need this behavior
> (but not that) from this other superclass.
TDDers should stop and start an entire program, now and then, to make sure
the entire thing passes all tests in one batch.
> OK
"Okay" is a word, not an acronym, from the Wolof language in North Africa.
It entered English at a time when the USA's outsourced labor was not allowed
to learn to write, and it sounded like an acronym, so various newspapers
picked that up as a sly joke, which everyone back then would "get".
Dictionaries incorrectly start with this backronym, misinterpreting that
mileux. "OK" independently appeared as an acronym in many different and
widespread contexts during that period, indicating a common verbal origin.
> it is not /that/ hard to
> quit and restart, but it is a blast being able to slice and dice the
> class hierarchy and then retry a function call with existing instances
> of the affected classes. And, more relevantly, it is nice not having to
> sit through a massive recompile/link of every line of code extant.
But that's when I ink evil comics.
This explains a lot!
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| David Lightstone 2005-06-10, 4:00 am |
|
"Phlip" <phlip_cpp@yahoo.com> wrote in message
news:RrKme.1164$iA6.417@newssvr19.news.prodigy.com...
> Peter Seibel wrote:
>
>
> Here's how to cause lots of rework. Collect many requirements, then design
> them all, then release them all. When you surprise the customer and get
> change requests, you may need to edit some requirements. That requires
> redesign, etc. This is an example of process waste.
>
> Was that the word you were (smugly) thinking of?
>
Hmmm, active listening, followed by switching the subject. The work of
experts
The word is Hacking as in Hacking out the design
> --
> Phlip
> [url]http://www.c2.com/cgi/wiki?ZLand[/url]
>
>
>
| |
| arthernan@hotmail.com 2005-06-10, 4:00 am |
|
David Lightstone wrote:
> "Phlip" <phlip_cpp@yahoo.com> wrote in message
> news:RrKme.1164$iA6.417@newssvr19.news.prodigy.com...
> Hmmm, active listening, followed by switching the subject. The work of
> experts
>
> The word is Hacking as in Hacking out the design
>
>
I'm new to the thread but I'll still put my two cents.
In one of my multiple travels througt the internet in search for useful
information. I stumbled across programs that would analyze huge amounts
of code and find nonexplicit relationships in the code. In this case C
or C++, I can't remember.
This would be a very useful tool for the case of a new team taking over
legacy code that works and trying to make sense out of it. A lot of
people would argue that is much better to start from scratch because
technology changes ...blah blah blah. That all depends on the amount of
code and how much access do we have to the knowledge embeded on the
lines of the source code. This knowledge might be very valuable and we
might want to rescue it form the ashes.
Anyway, following the idea; Say we had several request of changes to
the code. A "refactoring" tool would allow a team of programmers to
slowly make design changes to the code until it's architecture took in
the changes nicely. This would not be a one time two step process, more
like complimentary activities in a process. If our code editors were
more interactive this design changes (refactorings) would be made part
of them.
OK, there you are.
PD. I do also dislike buzzwords, like any commonsensical programmer
should
| |
|
| arthernan wrote:
> This would be a very useful tool for the case of a new team taking over
> legacy code that works and trying to make sense out of it. A lot of
> people would argue that is much better to start from scratch because
> technology changes ...blah blah blah. That all depends on the amount of
> code and how much access do we have to the knowledge embeded on the
> lines of the source code. This knowledge might be very valuable and we
> might want to rescue it form the ashes.
>
> Anyway, following the idea; Say we had several request of changes to
> the code. A "refactoring" tool would allow a team of programmers to
> slowly make design changes to the code until it's architecture took in
> the changes nicely. This would not be a one time two step process, more
> like complimentary activities in a process. If our code editors were
> more interactive this design changes (refactorings) would be made part
> of them.
How much experience have you with tests?
If you were to pick between two generally equal projects to join, you would
pick the one that had wall-to-wall unit tests.
You use them to make changes safe.
If you want to add features, or upgrade the design, you can change the code
while never departing very far from running tests. This, in turn, makes the
odds of a big bug hunt very low. When tests fail, you have the option
Tests ARE a "refactoring tool". The "refactoring browsers" we have heard of
are just elaborate keyboard shortcuts. None of them are perfect, so you
should always run all the tests between each tiny step of a refactor. The
ability to do this generally leads to code is clean and doesn't need to be
refactored.
(And please don't feed the troll;)
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
|
| > If you want to add features, or upgrade the design, you can change the
code
> while never departing very far from running tests. This, in turn, makes
the
> odds of a big bug hunt very low. When tests fail, you have the option
of hitting Undo until the tests pass again.
(And no programming after 10 pm, either!!)
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
| |
| David Lightstone 2005-06-10, 4:00 pm |
|
<arthernan@hotmail.com> wrote in message
news:1118376493.224094.125340@g49g2000cwa.googlegroups.com...
>
>
> David Lightstone wrote:
>
> I'm new to the thread but I'll still put my two cents.
>
> In one of my multiple travels througt the internet in search for useful
> information. I stumbled across programs that would analyze huge amounts
> of code and find nonexplicit relationships in the code. In this case C
> or C++, I can't remember.
Theoretically such tools certainly would be useful. I have never seen them
in action, so they are on par with the search for the Holy Grail.
(in this case a machine that can appear to think)
>
> This would be a very useful tool for the case of a new team taking over
> legacy code that works and trying to make sense out of it. A lot of
> people would argue that is much better to start from scratch because
> technology changes ...blah blah blah. That all depends on the amount of
> code and how much access do we have to the knowledge embeded on the
> lines of the source code. This knowledge might be very valuable and we
> might want to rescue it form the ashes.
The refactoring argument or rhetoric, depending on your perspective, is
based upon having a new development, not the restructuring of a legacy
system.
With a legacy system, you know a priori that which you must achieve and can
choose both a reasonable arthitecture and implementaion schedule. In the
proverbial refactoring (aka hacking) oriented development there are no
guarentees that the requirements can be achieved (because they may
substancially be changed mid -tream), that the candidate architecture is
scalable (nothing like mis-estimating the thruput requirements) or for that
matter even close to correct. (ie devoid of obvious race conditions).
The intent is little more than we will fix the problems as they are
discovered (sugar coated with a tenuous relationship to darwin and the
thousands of years it took for new species to evolve)
>
> Anyway, following the idea; Say we had several request of changes to
> the code. A "refactoring" tool would allow a team of programmers to
> slowly make design changes to the code until it's architecture took in
> the changes nicely. This would not be a one time two step process, more
> like complimentary activities in a process. If our code editors were
> more interactive this design changes (refactorings) would be made part
> of them.
>
>
>
>
> OK, there you are.
>
> PD. I do also dislike buzzwords, like any commonsensical programmer
> should
>
|
|
|
|
|