What does "refactoring" of a project mean ?

E

Elspeth Thorne

Roedy said:
Refactor is the opposite philosophy to "if it isn't broken, don't fix
it". Refactoring suggests code should be continuously kneaded like
bread to get the lumps out. If you let it sit still too long it will
crystallise and be harder and harder to change later.

This is somewhat off-topic...but there's a flaw in your metaphor. You
*don't* knead bread to get the lumps out. If you've still got lumps in
your bread at that stage, that's either intentional (eg, the lumps are
grains or fruit or whatever) or you've let yourself in for a lot of
extra work, and mess, and probably an inferior product. You knead bread
to distribute the yeast (or other raising agent) throughout the dough,
in the first kneading, and in the second kneading (after the bread has
risen and been knocked back), it is to get some of the carbon dioxide
out of the bread, so that the baking process doesn't give you huge
bubbles in the loaf.

</bread geek>


Elspeth.
 
P

P.Hill

Jacob said:
Refactoring - Rewriting crappy code so that
it can meet its requirements.

Redesign - Rewriting good code so that it
can meet new requirements.

;-)

LOL, I like those! :)

Except in truth neither refactoring nor redesign may have the
intention of changing the behavior. The goal in refactoring
is to make the code better (easier to read, easier to re-use, easier
to maintain, easier to understand ... ) but keep the same
behavior. So unless you have the non-functional requirement
that lists some of the 'betters' I just mentioned, you are not meeting any
requirements.

In agile test driven development (TDD)
methodology you often define what the code should do by: creating a test, make
it work, then examine it for any appropriate refactorings and then refactor, so
you are most often asking the question: does it still do what it was doing before?

Of course you are being too critical to suggest the only time something needs to
change is that it qualifies as "crappy". Often in either case you are trying to
move from more crappy to less crappy, but of course to be polite to the dork in
next cube you tell him in either case you're moving from good to 'even better'.

I might also put in a plug for the idea of refactoring by pointing out that
given the two possibilities above when you're given "crappy code" you need
to first refactor before redesigning, so you have good code then you are in a
position to redesign.

So to be less synical, but not anywhere near as entertaining, redesign and
refactoring really could be thought of as the above two definitions without the
value modifiers "crappy" or "good".

-Paul
 
T

Thomas G. Marshall

P.Hill said:
You seem to be ignoring Roedy's later post where he agreed with the
idea that 'redesign' could be applied to different levels of detail
of the design.

Ok, I guess I missed it. Sorry.
 
S

Stefan Poehn

Jacob said:
Following this thread I'm left with this impression:

Refactoring - Rewriting crappy code so that
it can meet its requirements.

Redesign - Rewriting good code so that it
can meet new requirements.

My Suggestion: Read Fowler's Refactoring Book:
http://www.amazon.de/exec/obidos/ASIN/0201485672/qid=1091119517/028-230945
9-6072551

I have read parts of it. It is fun to read and you can get some ideas of how
to write code or rewrite code if you want.

Don't take the terms to seriously, just try to find out (over years), how
_you_ can do coding best. I have done that and, looking back on my last
projects the last two years, I understand my code very much better than my
code from 3 to five years ago. Also, I can write code much faster now than I
could a few years ago. I think I am doing refactoring or redesign or
whatever, but it does not matter to me how you call it or how you define
those terms.
 
P

P.Hill

Stefan said:

Excellent suggestion!

[...]
I think I am doing refactoring or redesign or
whatever, but it does not matter to me how you call it or how you define
those terms.

I have had a similar experiance. Despite my postings it is not
very important to define the exact boundary between the two, only to understand
the area each defines. They each probably qualify as something akin to fuzzy
sets with 'soft' boundaries.

-Paul
 
J

Jim Cochrane

Following this thread I'm left with this impression:

Refactoring - Rewriting crappy code so that
it can meet its requirements.

Not really. Refactoring involves restructuring code in order to improve
the design - for example creating a new class that two existing classes
are modified to inherit from in order to move duplicated code from
the child classes to the new parent. The goal is to keep the system
well designed and well structured so that future maintenance and
extensions will cost less (take less time) than they otherwise would.
(Changing poorly designed code can be confusing and very time consuming.)
Often (probably usually) this restructuring is done with the goal of
keeping the functionality exactly the same.

It's like the scientific method - once a refactoring task is complete,
the system can be tested to ensure nothing was broken; at that point,
the code can be modified to meet new or changed requirements. But if
you add new functionality and refactor at the same time you inviting
unnecessary complexity and are thus greatly increasing the risk that you
will make a costly (time-consuming) error.
Redesign - Rewriting good code so that it
can meet new requirements.

IMO, the meaning of redesign is quite broad. I'll be lazy and let others
address this one. :)
 
J

Jim Cochrane

Stefan said:

Excellent suggestion!

[...]
I think I am doing refactoring or redesign or
whatever, but it does not matter to me how you call it or how you define
those terms.

I have had a similar experiance. Despite my postings it is not
very important to define the exact boundary between the two, only to understand
the area each defines. They each probably qualify as something akin to fuzzy
sets with 'soft' boundaries.

However, it is helpful to be somewhat formal in the sense that when doing a
substantial refactoring task, you will decrease your chances of introducing
defects if you refactor without adding or changing functionality, then test
to verify lack of defects, then make the functionality changes. This saves
time/money.
 
J

Jim Cochrane

[Rereading my post, I think it needs a bit more elaboration wrt your
statement - see below.]
Not really. Refactoring involves restructuring code in order to improve
the design - for example creating a new class that two existing classes
are modified to inherit from in order to move duplicated code from
the child classes to the new parent. The goal is to keep the system
well designed and well structured so that future maintenance and
extensions will cost less (take less time) than they otherwise would.
(Changing poorly designed code can be confusing and very time consuming.)
Often (probably usually) this restructuring is done with the goal of
keeping the functionality exactly the same.

It's like the scientific method - once a refactoring task is complete,
the system can be tested to ensure nothing was broken; at that point,
the code can be modified to meet new or changed requirements. But if
you add new functionality and refactor at the same time you inviting
unnecessary complexity and are thus greatly increasing the risk that you
will make a costly (time-consuming) error.

Refactoring may or may not involve improving "crappy" code. It often
involves improving a good design to make it better. I suppose you could
say that it often involves fixing a small design flaw - and the affected
code could be considered "crappy".

However, usually the code already meets its requirements and is
well-designed such that future requirement changes can easily be met.
Refactoring is simply intended to allow this to continue to be the case.

Alluding to your definition, you could say that refactoring is: As the
code evolves, expending effort on keeping it well-structured so that
modifications to meet new or changed requirements can be acomplished in
a reasonable time frame.
 
R

Roedy Green

However, usually the code already meets its requirements and is
well-designed such that future requirement changes can easily be met.
Refactoring is simply intended to allow this to continue to be the case.

Perhaps an agricultural analogy would be in order. Refactoring is
like weeding. Redesign is like ploughing.
 
J

Jim Cochrane

Perhaps an agricultural analogy would be in order. Refactoring is
like weeding.

That seems to work well. One weeds to keep one's garden "well-designed"
(healthy, well ordered, and beautiful); the more one neglects the weeding,
the more work and expense will be required in the future to keep the
garden healthy and well-ordered.
Redesign is like ploughing.

For the major rewrite type of redesign, I suppose that works pretty well,
too, though I like the refactoring/weeding analogy better.
 
S

Stefan Poehn

Jim Cochrane said:
[...]
However, it is helpful to be somewhat formal in the sense that when doing a
substantial refactoring task, you will decrease your chances of introducing
defects if you refactor without adding or changing functionality, then test
to verify lack of defects, then make the functionality changes. This saves
time/money.

This leads directly to software metrics. Here you can define much better
what you are doing, instead of saying "I am refactoring", you define goals
for a few metrics and check that you achieve these goals. By using software
metrics you can say your software is better because e.g. the cyclomatic
complexity is never more than 12. Cyclomatic complexity is a measure for the
minimum number of test cases you need for C1, but you can use it to improve
code readability.
 
P

P.Hill

Stefan said:
This leads directly to software metrics. Here you can define much better
what you are doing, instead of saying "I am refactoring",

I hope not! Many refactorings are simple 1 minute tasks. The power
comes from doing many of them, but the idea is do each as the developer(s)
see them. They write something, it works, they can clean it up by refactoring
right there, before they check it in, but running the units tests as they go
along. Do you really think that productivity is improved by first
measuring the last hours of code, compare it to last nights code, refactor,
then measure again? No, of course not.

I CAN see the place for metrics but it isn't one to one with refactoring
efforts, because many refactoring tasks are just too small to measure. Metrics
could be used to identify and quantify 'smelly' parts of the code (as certain
folks like to call less than great code). This might
generate a "story" (part of the backlog) which can become a task that a
developer can work on for a day or two. Metrics before and after such a
multi-day task would be very useful. Metrics before/after any refactoring would
be rediculous, but code metrics as part of nightly builds would help to
illustrate any emerging trends.

A nightly build set of metrics could be used in combination with other project
metrics.
Sort of good we really got a lot of the tasks for the next release complete,
bad the complexity metrics shot up during the efforts.
Implication: put a little more effort into refactoring the complexity during the
next iteration.
By using software
metrics you can say your software is better

Yes, but, asking another programmer if the class is understandable, or
explaining the code, can show them where the code is not as organized as it
could be. Many times engineers can see disorganization as soon as they have to
talk about code with each other, so they don't need to have tools to help them
determine where it stinks.

One thing for everyone to keep in mind is that many refactorings aren't A is
better than B, they are make "A into B", but there is also a cooresponding
possibility to make "B into A".

As the article by Joel Spolsky referenced by Karl v. Laudermann said

"All I would do is logical transformations -- the kinds of things that are
almost mechanical and which you can convince yourself immediately will not
change the behavior of the code."
and "And in fact I never really had to think very hard, and I never had to
design a thing, because all I was doing was simple, logical transformations."

-- http://www.joelonsoftware.com/articles/fog0000000348.html

But also note that before and after Joel great 3 week effort some metrics would
have been great.

In summary: when measuring the results of lots of refactoring, metrics are
useful, but they don't have much of a role when speaking about everyday refactoring.

-Paul
 
R

Roedy Green

Many refactorings are simple 1 minute tasks.

The idea is you can clean up the code now, or you can procrastinate
and clean it up later.

There are three problems with procrastinating.

1. You have dirty code in the interim, which is harder to maintain.
You will introduce more bugs and take longer to make your changes.
If you tidy early and often, then you get to live most of your life
surrounded by clean code. It is very much like having an organised
kitchen where you can easily find everything.

2. the longer you wait the harder the job. You spend more overall
effort. It is like weeding a garden.

3. the longer you wait the more Murphy's law will spring on you the
need for a massive refactor the night before Comdex.

Tidying code is something I do to procrastinate OTHER tasks. I like
tidying code. Messy code makes me wake up in the middle of the night
thinking about it. My most common dream is about tidying code, often
worrying I have broken something in the process, then waking up and
finding I have accomplished/harmed nothing. Writing code without
refactoring when you are done is like having sex without orgasm. You
deny yourself the pleasure of the perfect completion.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top