Mike Rivers wrote:
In article am writes:
Actually, there are a lot of us programmers who have learned that strictly
following processes that divide up refactoring and improvement stages are well
worth doing, and we do it pretty rigorously.
That's a good thing if you're working for customers who can afford it.
But it's one of the things that makes software more expensive than
many people believe it should be.
Some of the newer development environments will actually do automated
refactoring. In theory this makes it pretty cheap to do and makes it
less error-prone.
Even without automated help, you might be surprised how mechanical a
process refactoring is. There is a procedure, and it's designed to
minimize errors. For instance, when you are removing code from a
function and making it its own function, you create the new function
and *copy* the code into it without deleting the original. Then you
compile, then you comment out the copied code and replace it with a
function call. Then you compile and test. Or something like that.
The point is, the process is designed so that there are safeguards
to ensure you didn't screw something up, and even if you did, you
can easily put everything back like it was before.
Anyway, most of the work that's put in on a lot of software (games
excepted) is in maintenance, and it's often being done by someone
different than the person who wrote the original code. Cleaning
up the code can make that process smoother and less likely to
introduce new bugs.
- Logan