Refactor now and pay less later?
I read some blogs from time to time. Not a lot, but usually I search them when I am looking for a fellow programmer who feels my pain. I was searching tonight and came across a great blog post by Mark Heath that really hit the nail on the head of what I have been living this week.
Refactoring to the rescue?
Does refactoring code improve it? I guess that depends. All too often I see people stick the label on what they are doing as refactoring when the reality is they are fixing past mistakes, or things on their personal todo list.
This is especially true during death march ship deadlines. "nice" things like testing, docs, pulling out common code, decoupling dependencies all get thrown out the window. Then when they get back to clean all that up they call it refactoring. Isn't it really just playing catchup on things you should have done?
Refactoring to blame?
When the changes result in new bugs the refactoring is often quoted as the reason why the bugs cropped up. Quite often they actually already existed, but you didn't know about them (no tests for them). Finding a bug that already exists in a shipping product is not the same as a new bug introduced during coding.
Or they are introduced as a by product of decoupling the code. This is really an unintended consequence of working on code that you no longer remember why it does what it does. If you had taken the time in the first place to put some docs on WHY things work that way, or notes for yourself of things todo it probably would not have happened in the first place. Afterall, when you originally wrote the code you didn't put bugs in it on purpose did you? You had valid reasons for all the code, but now you forget what they were.
Even worse - now your buddy next to you might have to rip apart that class. And he won't know what you were thinking FOR SURE. Which hopefully is a point everyone who makes a living coding understands by now: You probably won't be the one to come back and cleanup a piece of code. There will be other things for you to do!
Refactoring - er Cleanup in VistaDB
All of this is a long winded way of saying we have been cleaning up code ourselves. Clean up, decouple, strongly type, etc. In some cases we have seen huge performance gains of certain operations. And in a few places we have totally broken objects because no one understands the depencies reasons any longer.
I expect to publish a new beta build next week for everyone. And though it may not appear to have much in the way of new stuff, under the hood a lot has changed. In some cases objects were totally rewritten to take advantage of strongly types lists rather than generic object lists. In others classes had to be decoupled for memory or reference counting.
I don't think we are done yet either. So far we have only been focused on the lowest level of VistaDB (Data I/O). But this is a good a time as any to make these changes. They need to be done. And if we find bugs along the way to fix it doesn't mean they weren't there already - just no one had a test for them yet.
Of course the hope is that the time spent now will speed things along later. Much of this IO cleanup is being made with an eye towards the server edition. But it is slow and painful in the meantime.
Similar Posts
- The GC does not solve all memory leaks
- Looking ahead to 2008, and back at 2007
- Set any 2008 Resolutions or goals?
