in reply to Re: Re: Re: Re: Best way to 'add modules' to web app?
in thread Best way to 'add modules' to web app?

Can you give an example of where this happens?

In my experience a well-factored program means that you always have a codebase that is flexible enough to accept new features simply. However large.

There is also the advantage of avoiding the overhead of infrastructure until you need it, which means you have a smaller simpler codebase that is faster to develop and maintain.

  • Comment on Re^5: Best way to 'add modules' to web app?

Replies are listed 'Best First'.
Re: Re^5: Best way to 'add modules' to web app?
by Anonymous Monk on Jul 05, 2003 at 20:08 UTC
    Look at the older code for everybuddy. It's in C. They don't do anything with any idea of expanding on their source code, till now. You can't even do drag-and-drop withtheir current code base. It'd requier expert knowledge in the code to know HOW to refactor it.

    Incrememnttal is always good and all, but planning against extending or expanding is a shot in the foot.

[reply]

      Yes a lot of old code is in C, and a lot of it sucks quite badly.

      However, that's not the issue is it?

      I thought we were talking about whether adding infrastructure upfront that isn't needed until later is more/less efficient than adding the infrastructure at the point it is needed.

      My experience (and the experience of others - well chromatic at least :-) has been that the latter is a far better approach. You're not guessing at the requirements, and you don't have to carry the overhead of the extra infrastructure when it isn't needed.

      Nobody is "planning against extending" - just choosing not to extend until it is necessary by an actual requirement.

[reply]
        perl is not a panacea! and this is exactly the issue.

        everybuddy was written with 0 expandability, and it got rewritten twice 'cause no one could add simple things. heck, register.com is written in perl with 0 expandability and it was pure HELL trying to do things like, changing prices or changing behavior or writting api's.

        but it's not a matter of guessing requirements. it's a matter of staying organized. If you write for one way of expanding, and it doesn't work out, you still have something to mold. if you don't plan at all, you wind up with silly things like, 500 line functions, duplication of code, or just ugly algorithms that require more rewriting than refactoring.

[reply]

In Section Seekers of Perl Wisdom