Nick,
As PHP becomes more accepted in the corporate world, it is only logical
that larger and more complex applications are going to be developed using
it.
To start I will state this: I am one of the consultants of a project
run by 70 developers for the period of 2 years at the Ministry of the
Economy and Finance of Italy.
This is supposed to be the world's first or the second biggest project
in the (depending on whatever size Yahoo is like, Rasmus is there :) The
project is mostly in PHP/Apache/Linux and uses Oracle and PL/SQL plus a
lot of other things like Java, Ruby, C/C++, C# and even old-friend COBOL
and NatStar. Most of the whole thing is PHP/Oracle though. There are
approximately 104 servers in all the regions of Italy and are some
5-8.000 authenticated users.
Best part of PHP was not really the price (there were money) but the
compatibility for all the technologies we needed to communicate within
the framework. There are also parts written in other languages and PHP
handles them just well.
Normally, one chooses Java for such things as Java is supposed to be the
most dymanic and flexible language. But, personally, I don't see it that
way - I prefer PHP because of the faster development times what makes
the application's quality much higher and things much quicker to
implement.
While there is an abundance of information out there about making
specific things work, there seems to be a shortage regarding the big picture.
Because of this, PHP is also cheaper - you need less time for debugging
and researching online. Bigger you go - more you appreciate things like
this mailing list and the tons and tons of online resources.
Need a check for the email format?
in PHP - a) Google / SourceForge / app you know has it.
in 3-5 minutes you got it.
in Java - a) What Sun's CD was that? b) What class was that? c) Is it
copyrighted? d) Can it be used for free???
So, you end up making it on your own, even if Java makes all these
`reusable components' you still need to tripple-check the things and so
on
As such, my question is this: What methods and techniques can be used to
help design and build complex, medium to large PHP applications that are
not only scalable, but maintainable and extensible?
Obviously separating application and business logic from interface code is
a given, but what about other things? Are the object orientated facilities
of PHP currently worth really trying to take advantage of? If so, what are
you doing to take advantage of them? Are design concepts such as design
patterns relevant at this level? What frameworks, if any, currently exist
to assist in rapid, structured development, and what specific benefits do
they bring to the table?
Everyone says OOP. But, in reality I'd say: OOP only for the things you
reuse more that once. The rest of application should be written in plain
concept of
1. Auto-prepend
2. Prepare XML output
3. Auto-append for the layout
Which is something like, let's load a few classes every file needs. Then
simply make the file's functionality based on params received and output
some XML. The XML will then be used or laying out the page and the rest
of the process.
Everyone this way gets much a simpler framework to develop with.
The important parts of a large PHP project, in my opinion, are:
1. High and solid standardization of the framework and coding. Meaning
that everyone works in the same way and not `as he thinks is the best'.
This will give the possibility for the team to work better together and
move between the sub-projects easier. It's same in every language, so
one should really care.
2. Have at least a one or two people who maintain the commonly shared
libraries. This is, when someone says Hey, I want this code to my page
too the team answers: which code? and then takes that code, creates a
library component, document it and organizes it within the libraries.
3. All of the output for the application is better to be an intermediate
mark-up like XML. This way you can have the designers who get XML and
apply whatever templates to it. Programmers should never care how
something looks - their output is plain XML and that is it. Other
technics are good too - for instance Smarty if a good idea. But, I'd
still prefer XML and then XSLT and then caching mechanism to avoid
overload.
4. 30% (AT LEAST!!!) of thee development times should be spent for
planning. That is - no coding just sitting with the pen and paper in
the meeting room and designing the framework till everyone agrees. After
that point everyone knows exactly what is where and things becomes very
fast.
5. team should have tools already ready AND STANDARIZED for them to do
the development. Thus, CVS is a must. No one should care what OS one
uses for development workstation, but the way it is organized on the
server should be once agreed and never changed. It is too expensive to
change even a simple .htaccess file - take one hour from 70
