Tip:
Highlight text to annotate it
X
What have we learned or what conclusions might we draw, what
kind of activities can we compare refactoring to? Because a lot
of people don't really think about refactoring until they find
themselves in a situation where they're forced to do it. For
example, you need to extend some code and the only way to create
an extension point or create the seam that you want is to first
do some refactoring in that place or in an example like the one
we saw there is a bug that you're trying to isolate and to put
that bug into a place where you can test is separately you might
need to do some refactoring. The reality is refactoring is
something you should be thinking about all the time. As a
motivating example from this, here is the first draft of a
document you might recognize. When in the course of human
events, it becomes necessary for people to advance from that
subordination in which they have, what is this, right? This is
somebody's first draft. This is a true first draft by the way.
This is the version that you're probably familiar with. If
you're a student of American History it becomes necessary for
one people to dissolve the political bonds which have connected
them with another. That sounds a lot better, doesn't it? It's
the same content but the structure has been vastly improved. You
could think of this as a refactoring of the declaration of
independence or the opening passages thereof. To me the moral of
the story is just because your code works it doesn't mean you're
done, it just means that you have a first draft. As with writing
the first draft is good enough to get the idea across but the
final draft is the one that the people are going to read, it's
the one that other programmers who come after you are going to
depend on. Refactoring is worth doing because unless you're the
kind of person who'd be satisfied with your first draft of
writing and I really hope you're not. Refactoring is how you get
from something that works and expresses the idea to something
that somebody else would be happy to take over. Some fallacies
and pitfalls, as usual, what are some ways that you can avoid
common problems if this is your goal, first, realize that most
of your programming time is going to be spent in this activity.
It's not going to be fixing bugs, the statistics already tell us
that and it's not going to be creating new code, it's going to
be improving the code you do have either for your own sake or
for the sake of others. What's the counter point to this? One
counter point is the code has gotten so ugly that you say,
forget it, let's just start over. Throw out this code, we
understand what suppose to do, let's rewrite it. This is the
worst thing you can possibly do. This is almost never the right
thing. It is possible to get to a point where you've accumulated
so much technical that there's really nobody in the organization
who understands the code well enough to do anything but start
over but this is the standard program or optamism, right?
Getting the first 50% of the code working from scratch seems
like it's easy and then the last 50% is mostly impossible. This
is almost the right thing to do. This is like the nuclear
option. This is like, I don't know, shutting down the government
because you disagree with certain legislation. Almost never the
right thing to do. As we said, several times and several
different guide is stick to one activity. Program are also
easily destructible. When you're refactoring remember what your
goal is, you're not changing behaviors, you're not fixing bugs,
you're improving the structure and leaving everything else
alone. Resist the temptation to say, " Oh, I know I'm
refactoring this other method but I'm just going to fix up this
little thing over here that looks sloppy. That's a separate
task, stick to the task at hand. We talked about metrics and how
just like test it's bad to slavishly follow the metrics and have
all of your refactoring aimed at getting those numbers to go
lower. Sometimes the version you have is the version you really
wanted and even if there's a version that would have made some
of the metric numbers improved, it doesn't necessarily mean that
it's easier to read. What's a good example? I suppose you could
say a good example from the literature is something like these
are the times the try men's souls. I could also say so wise
these time are trying, that's shorter but it doesn't have the
emotional impact somehow. There is a time to know when your code
is beautiful as it's going to be. Don't over rely on metrics.
Use them as a general guideline, right? Nothing code climb that
sets a good example on this regard. The computer number of
metrics and this sort of computer an overall aggregate score
that really tells you which parts you've recorded are generally
good and which parts are generally in need of attention. Of
course, the corollary, if you don't do these things is you're
going to get to a point where you have to do a big refact. Let
me tell you a big refactorings are painful. I've been doing a
big refactoring on software that I wrote three or four years
ago. I thought about it. I thought about I'll just throw it out
and start over. This is working code, working code as we'll soon
see is a rare and beautiful thing so I decided to take the pain,
go through the refactoring, I'm learning a lot from it but the
big thing I'm learning is don't let it slide for too long
because after a certain point, it gets exquisitely painful to do
refactoring. With those fallicies and pitfalls in mind we can
ask which is true regarding refactoring that usually results in
fewer total lines of code that it should not cost existing test
to fail when you start doing your refactoring that it addresses
explicit versus implicit customer requirements or that it often
results in changes to your tests. Which of these is true?