What are the advantages/disadvantages of monolithic PHP coding versus small specialized php scripts?

Question

I have historically used a monolithic approach to PHP coding.

That is, I write one index.php, with an average size of 70k-250k, and use

mod_rewrite

to turn the rest of the

REQUEST_URI

into parameters passed into the index.php to control what is happening.

The alternative would be to write many small php scripts, each specialized to a particular purpose. I'm thinking that some of my more active ajax scripts may benefit from this.

One thing that has kept me in this thought process is I don't know how using includes, especially conditional includes would affect the performance of the opcode cache.

I have generally avoided includes altogether if possible due to my paranoia about this, but this results in either duplicating code, or staying monolithic.

As I'm using mod_rewrite anyway, converting between the two methodologies should be simple.

I look forward to your comments.

EDIT: One of my target apps currently handles 80-100 page hits per second (I got some decent hardware). Most of those are ajax requests. Everything works and is snappy, but I've developed as a php programmer without critique and need it.

Answer 1

Modular code is easier to understand and maintain. A huge monolithic codebase can become like a house of cards. It works just fine in practice, but changing any of the lower elements becomes impossible. If you split up your code into clear abstractions, it can be much easier to make changes and you'll save yourself a nightmare if you ever add developers.

Answer 2

The performance bonuses of not using included files is far outweighed by the ease of maintaining and debugging a large application using included files.

Rework is waste. Copying and pasting code from one app to another is maintenance hell.

Answer 3

In addition to the other comments (with which I agree completely), another view: I have made the experience that a monolithic approach, if driven to extremes, costs valuable RAM - the whole file has to be loaded to be interpreted, no matter whether everything from it is needed or not, and that alone eats off a lot from the 8, 16, or 32 MB you get per instance.

Answer 4

Please don't forget about testing and maintaining the code. I can't image if you're able to write unit-tests to a project which is just in single file. Futher more, it's much harded to predict which functionality can be broken by changes you've just made. In case of modular architecture if you change some module then you can only break this module and modules which depends on it. Even a small changes can be fatal to single file projects (you can forget to close quote which will break all pages at once). I think you must retest all the functionality after even small changes we've made. And this can be a pain for testers ecpecialy you're not able to use unit-tests.

Also if all code i stored in a single file then you'll more likely have a bad code. Such code will tend you to use global variables. In this case it's hard to reuse such code in other project. Of cause you can copy it, but remember when you copy something you copy all its bugs. Just imagane the project where you can use set of well-tested (tell thanks to unit-tests) libraries. When new bug appear then it's just fixed in a single place.

One more thing, when you're working in a team using a single file will be pain. Even if there is only 2 developers they waste much time to merge changes.

Any way, if your project is not big at all you can use single file appoch.