Programming .. in the LARGE

from writing scripts and smaller apps to bigger apps

[jaski]

It was a big app I must say at the out set.
I wrote a prototype for it.

The client liked it.

We started writing the app (PHP and MySQL). With time requirements changed .. he came up with many more ideas .. we kept on adding features .. sheer volume of funtionality rose and rose .. code started getting messy .. the original architecture of the app .. well its still there but not as intact it ought to be.

Now its like 18 months from the time when first lines of code were written .. and the app has grown real big .. and the code messy.

Its quite clear to me now that unless I do some thing about it .. re-write or refactor the whole thing .. its going to be a big problem adding any more functionality .. which is almost certain that we will.

But .. the question that I am pondering over for many days now is what can I do to manage complexity.

What can I do to write an application which is HUGE and yet be able to maintain it.

I have been reading a very good book by Grady Booch .. "Object Oriented Analysis and Design - With Applications". Its a very good book but to me web applications sound quite different from other applications .. not quite as amenable to that approach.

Any ideas .. any suggestions for reading .. just any thing is welcome .. :)

Thanks
Jaski

[andreasfriedrich]

OOP works well for the web as well. Start out with a general framework that handles basic, yet rather abstracts tasks: Loading, showing, changing of modules (I´m using modules here since they need not be classes, i.e. OO is not required for such a task. But OO features make it easier in a lot of cases). Define a set of common functionality and make a set of helper modules to provide that functionality. Whenever you add a feature think hard whether it is new indeed or whether your current modules may already provide the functionality.

Be open in your design. Do not make the mistake of providing too few hooks as the Apache [httpd.apache.org] 1.x design did. Be liberal in that respect. Be concise in defining the interfaces but pass along a reference to the main object for flexibility

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one -- and preferably only one -- obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

[python.org...]

I like the above Python design critera very much. They are not rules that you need to follow but principles that you ought to apply as best is suitable in any given situation.

Andreas