Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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.
    • 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.
      • 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.