All the Perl that's Practical to Extract and Report

Sort of slacking?

gizmo_mathboy on 2002-03-17T03:41:30

Is it slacking when one decides to think about refactoring/rewriting your code (checking module dependencies, maybe even look at stuff at the function level) instead of doing another, prioritized task?

Well, that's what I'm intending to do for the next few hours. Heck I'm even thinking of redoing the thing with Mason. It might be more practical to look at Template Toolkit since I want to put up a Slash site. Eh, just one more thing I can learn.

Here's to meta-slacking (or is it virtual slacking?) Maybe I should ask TorgoX for a ruling since he seems to a resident linguist (or at least more familiar with linguistics and language than I). :-)

It's definitely not slacking

pdcawley on 2002-03-17T13:22:07

If anything, it's investing in the future. If you go with a constant 'Make it run, make it Right' cycle of extension and consolidation then both extension and consolidation will be easier to do.

I'm in the process of working on a system which has become terribly badly factored (but which works) and it's become intractable; changing almost anything would require massive and far reaching changes which cannot be tested effectively (and those tests cannot be automated) without pushing stuff live. It's painful.

And it's easy to see how it go that way. Expediency. People have spent time making it run, but almost no time has been spent making it right.

So now, we've got to rewrite it all from the inside out.

Re:It's definitely not slacking

gizmo_mathboy on 2002-03-17T23:23:33

Amen to that. Looking back over the code I'm shuddering. There are many functions I don't think I'm even using anymore. I've also really started to like Tie::DBI. Makes some part of the system trivial and nicely compacted.

It really makes it glaring how important good design is. Oh well, write once to through away as they say.

Re:It's definitely not slacking

pdcawley on 2002-03-18T08:43:00

I'm not entirely sure I agree that you should write it once to throw away. But I'm absolutely certain that you shouldn't hang on to stuff for 'sentimental' reasons or because 'I might need it'. After all, CVS will hang on to that stuff for you.

My general approach when removing 'dead' code is to stick a
carp "Function foo is deprecated, use bar"
line at the start of all the functions that I think are dead then, if I'm confident that the test suite has good coverage, I run the tests, watch for warnings, fix them and then remove the dead function. If I don't have confidence in test suite then I deploy the new version, watch the logs, fix the warnings and try and write a better test suite.