>> One of the things that frustrates me about my job is that I want to
>> refactor things, and people complain that it would take too long and so
>> we won't do it.
>>
>> Obviously the customers aren't going to be too impressed if we spent 2
>> years restructuring the codebase with no user-visible change in
>> functionality. But that doesn't mean that *all* refactoring should be
>> put off...
>
> Remember that refactoring is not the same as rewriting. Refactoring - at
> least as I understand it - is a sequence of many small baby steps.
> Ideally, the steps should be small enough that you can formally prove
> that they don't change functionality in any way. Such as moving some
> portion of code into a separate function. Or making a public member
> variable protected and providing getter and setter functions for access.
> Or renaming a function.
>
> Each such step is a separate refactoring action, so it shouldn't be too
> difficult to interweave it with your daily job.

Another theme of the book. The author states that your goal should be to 
have the class fully covered in unit tests, and each change must keep 
all the unit tests working.

Suffice it to say, changing code in a way that doesn't break existing 
stuff is far, far harder than just throwing the lot in the bin and 
starting again.

The other Fun Thing is that there are subsystems which are used 
*everywhere*. Some of them have awful design, we all know it's awful, 
but if you changed it, you would have to touch every client of that 
subsystem - i.e., the entire application. For this reason, we never make 
any improvements to these systems.

I personally am of the opinion that it would be *that* damned hard to 
change all the code; there are automated refactoring tools and such to 
help you do it. But it seems I am in the minority...

Post a reply to this message