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

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.
  • Hi Ovid!

    I just returned from work when I saw your message and I can understand it and relate to it. There may be one of the so-called "anti-patterns" [] about this, but since there are quite a few of them, I'm not sure if it will be easy to find. I'm not much of a pattern/anti-pattern freak myself (as I like to think of good solutions to problems when they are needed, and not waste precious memory remembering tons of patterns), but there are people who are more into this kind of thing. I can try asking so

    • Well, I talked with my "patterns" guy. He said that one may find what you're describing in the "Big Ball of Mud" [] article that describes how a software project goes on to having a lot of bad code, possibly in terminal state. (Note that I have yet to read it)

      As for my "lazy refactoring" or "just-in-time refactoring" - he called that "continuous refactoring", or at least thought it was a good name for it, and said refactoring should be done at small, atomic steps. You can consult Joel on Software's Rub-a-dub-dub article [] for documenting a one-time, lengthy and top-to-bottom refactoring, which may also be sometimes necessary.

      I've done both kinds of refactorings in the past, and I hope everyone has.

      • You've nailed it. Originally I didn't think about that because I had the incorrect impression that a big ball of mud primarily referred to a reasonable system which decayed with age. From reading the first bit, I see that the BBOM also refers to what I described. I think I need to reread that article again. Thanks, Shlomi!