Now I want to conclude this discussion on refactoring by telling you
when you should not refactor. One first clear case is when
your code is broken. I want to make it very clear, refactoring
is not a way to fix your code in terms of its
functionality. It's a way to improve the design of your code.
So if your code does not compile or does not run
in a stable way, it's probably better to throw it away
and rewrite it rather then trying to refactor it. By definition refactoring
should maintain the functionality of the
system. It should be behavior preserving.
So if the code was broken before, it, it's probably going to be broken
afterwards as well. You may also want to avoid refactoring when a
deadline is close. Well, first of all, because refactoring might take a long
time and therefore might introduce risks of being late for the deadline.
And also, because of what we said before about introducing problems, you don't
want to introduce problems that might take you time to fix right before a
deadline. So if the deadline is too close, you might want to avoid
refactoring the code at that point. And finally, do not refactor if there
is no reason to. As we said before, you should refactor on demand. You
see a problem with the design of your code, with the structure of your
code, it's okay to refactor. If the code is fine, there is no reason
to refactor. I know that refactoring is fine, but you don't want to do
it all the time. The next thing I want to discuss, after discussing when
not to refactor, is when to refactor without an indication that will tell us
that it's time to refactor the code. And that leads us to the discussion
of a very interesting concept.