In every project I take on, I reduce the "pieces" of the project down to individual lumps. Several reasons. One is to find overlapping functionality and stop duplication of efforts. Another is to make development/debugging easier as I am now debugging small pieces of code. The next big reason is that I can then dynamically load (in most cases) only the pieces I need for that individual run (or CGI hit).
I find that all of these things improve development time, quality and my teammates (if I have any) ability to contribute to what I am focused on. In the long term, it promotes reusability, scalability and maintainability (and puts me into a better position with my management).
The calendar based applications I have written in the past always had many functions, though only a few were used on each call. I was able to write much faster functioning code (did not have the ability to use mod_perl or anything similar in most cases) and we were able to quickly extend core components to the "new" requests that inevetiably come in (come to mind) after a neat new tool is put online.
In a nutshell, many small pieces (with very few exceptions in my experience) almost always work better than large chunks of code.</P.
There is a simple way to load an unknown object (module) at run time. Rather than have a bunch of use this; use that;s up front in my code. For me, using a dynamic system has cut down on overall loading, memory, time, etc.
In reply to Re: One Big Script vs Several Specialized Scripts
by digiryde
in thread One Big Script vs Several Specialized Scripts
by jerrygarciuh
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |