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 people to explain what happened and you ended up with 70 hours (2 weeks of amployee's time) lost. There can be no mistakes. So, in conclusion I'd say - language doesn't really make a big deal out of itself when this is a BIG project, what matter is the professionality and knowledge of people. PHP can do almost all of it, so as long as the management is good, times are not idiotically strict and people are enough - you can do it just fine. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
