Slash Boxes
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

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Monday November 18, 2002
02:38 PM

Eating your own cooking

[ #9007 ]

I would kill to get a brand-new project where I get to design everything from the ground up without worrying about refactoring legacy code. I have been working continuously on a horrible code base, most of which I wrote a couple of years ago. I suspect that nothing teaches about the horrors of bad design faster than being faced with your own. After all, you know why you made the "design" decisions you made back then and you're left wanting to go back and slap some sense into yourself (which means, of course, that then you wouldn't have made those mistakes and couldn't go back to slap yourself which means you would have made ...).

Testing problem of the day: generally, writing tests first is great because you can nail API problems pretty quickly. In theory this means you can keep your pretty API and muck with the internals all you want and your code (and tests) still pass. Legacy code, on the other hand, often has rotten APIs. I bit the bullet and cleaned up many of them after writing the tests, but since my tests no longer match the code base, it's been tricky. grep -r is my friend.

All tests successful.
Files=5, Tests=458, 7 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • One nice bit about writing tests after the fact is that it's immediately apparent what needs to be fixed: it's usually hard to test. (The other nice bit is that you have tests. There aren't really any other nice bits for test-after development.)

    • No, no... writing the tests after the fact shows you what you need to push your billing up ... er ... to redesign :)

      As a side note, I think our experiment with XP is failing miserably. As of this writing, I am the only programmer out of four who is bothering to write tests. The others, while acknowledging the tests are important, don't bother with them much, if at all. We still can't get good story cards, we have no iteration planning and we're still stuck in an ad hoc development mode. We made a stab

      • Unfortunately, no software development method works if you don't have people willing to follow some sort of organized method. I second ziggy []'s recommendation of Software Craftsmanship. Quality has to come from people who intend to do quality work. (Quality doesn't come from CMM, but that's another story!)