On Tuesday I wrote about the start of this week’s gig. Now that the week is over I guess an update is in order.
In summary; I failed to work miracles this week…
Monday and Tuesday were spent on the low hanging fruit. Lots of simple transformations that made the code less flexible made it easier to see the wood for the trees. By the end of Tuesday I’d moved the code into a library, slipped in several interfaces, mocked up a few things and written a handful of tests.
There was a good reply by Dr. Real PC on one of Joel’s discussion threads recently;
“The most important thing is caring. If you don’t care it doesn’t matter how smart you might be. If you aren’t interested how could you have the patience that’s required?”
How true. I think it’s reasonably easy to spot if someone cares about what they’re doing, or, perhaps it’s just easy to spot when they dont…
I’m getting a bit fed up of hearing the word ‘Refactoring’ when what people really mean is just ‘hacking at code’. Back in May last year I responded to Bob Cringely’s piece on how bad the whole idea of refactoring was; I still stand by what I said and, looking back, I think the key point is this:
“Not all code changing is refactoring. Refactoring requires discipline. You need to balance the risk of refactoring with the risk of not refactoring.
I’ve got one of those ‘please dig us out of this hole before we ship on Friday’ gigs this week. I’m back with the refactoring project for a few days and, well, when the cat’s away…
So, we’re 80% done but none of it seems to work, no tests, and the design seems a tad overly complex and it just must go live by Friday… Our task is simple, just clean things up, make it work right and finish the other 80%.
Codemonkey uk has an interesting piece on the use of explicit initialiser and destroy member functions rather than allowing object lifetime to be managed by the constructor and destructor.
Codemonkey uk comes down on the right side of the argument, in my opinion; explicit initialiser methods are devil spawn.
The problem with classes that have a separate init method, no matter what it’s called, is that the class can exist at least two states; constructed and initialised.
A new posting in the blast from the past reprints area. First in a series that compares CORBA and COM; CORBA - Reference Counting.
Previously, on Practical Testing: Having bolted on some tests to an existing piece of code we’re now doing some “agressive refactoring” ;) and rewriting the code from scratch using the testing ideas we developed earlier. The whole point of this exercise was to fix a known bug, we did that in the existing code here, now we have a test that forces us to address the issue in the new code.
The one where I find that you can teach an old dog new tricks and almost use the ‘rocks’ word.
Just recently I’ve switched to using STLPort on two of the code bases that I’m working on. One of my clients wanted to use it because they were having some weird threading issues with the standard VC6 stl and their ’enterprise’ install of VC was too hard to patch with updated stl headers from dinkumware… (I’m starting to think that ’enterprise’ often means big, clunky, broken and incompetent, but that’s another story).
Previously, on Practical Testing: we fought through the pain of writing tests for hard to test code and then we decided to see what it could have been like if we’d developed the code test first… Now we’ll add some more tests and some more code, still keeping it all nice and simple…
In our BOT development our second test was a test for multiple timers. Unfortunately that will completely break our simplest possible implementation of a timer queue so we’ll ignore that test for now.
I’ve been writing some blog entries about a piece of code from my ‘back catalogue’ that didn’t have tests and that had a known bug that was reasonably hard to test for. Right at the start I commented that the code was a tad over complicated due to the way it had been developed using HITIW (Hack it till it works). The complexity in the code itself made writing tests for it harder than it should have been and, well, I wouldn’t write code like that these days (honest).