A community in which webmasters can ask for help with topics such as PHP coding , MySQL , IT jobs, web design, IT security.
Current location:homephp forumphp talk in 2008 yearInherited a PHP nightmare, where to start? - page 1
User InfoPosts
Inherited a PHP nightmare, where to start?#1
I've inherited a PHP project that's turning out to be a nightmare. Here are the salient points:


All the original developers have left
The code has no version control
All development and testing was done on the live server by renaming and editing the PHP files. There are multiple copies of each file index.php, index2.php, index3.php etc. and it's unclear which files are really being used
There are multiple includes in each file to files that include other files that include other files, etc.
There have been a multiple developers on the project that each had there own way of doing things. For example, there is a hodgepodge of JavaScript frameworks, some database queries use SQL, others an XML interface and others call procedural functions in the database.


Because of all of these problems, development is frustratingly slow. Besides venting my frustrations to Stack Overflow, any recommendations on how to get started on this mess? I'm fairly new to PHP development myself, but it seems like setting up some kind of development environment so that changes can be tested without breaking the live server is the first step. Any tips on how to get started here? What is a typical way to do testing? Setting up a local version of the site on my desktop seems like a lot of work (server is Linux, but desktops here are Windows). Can I create a subdirectory on the live server for testing, or..? What about the database?

Secondly, is there some kind of profiling I can enable to track which files on the server are actually being used? I'd like to delete the renamed copies of things that aren't actually being included. Even better, is there a way to tell which parts of a file aren't being executed? There are lots of copied functions and garbage in that I suspect aren't being used either. Similarly, for the includes, any tips on straightening out the mess?

Well, I'll stop venting here and throw myself at the mercy of everyone here. :)

posted date: 2008-12-09 10:48:00


Re: Inherited a PHP nightmare, where to start?#2
I had made out the solution of this problem. click to view my topic...

hope that hepls.

posted date: 2008-12-09 10:48:01


Re: Inherited a PHP nightmare, where to start?#3
The first thing I would do is set up a testing environment using a virtual machine of some sort. VirtualBox or Virtual PC would be fine choices. That way you can start changing things without fear of breaking the production environment. No matter how much work this seems like it will be (with the database and web server and everything), in the end it will be worth it. One of the great benefits is you can copy the VM and give it to somebody else, if you find you need assistance.

posted date: 2008-12-09 10:50:00


Re: Inherited a PHP nightmare, where to start?#4
You definitely need a development environment. If you don't want to mess with running the site on your windows box, you could grab a VMWare image of some Linux distro.

posted date: 2008-12-09 10:53:00


Re: Inherited a PHP nightmare, where to start?#5
Set up a development server (as GregHewgill mentioned, VirtualBox andVirtual PC are good choices forthis).Put the current site files(including the relevant web serverand PHP configurations!) intoversion control.Find out what files are being used -use your development server setup totest by removing all the fooN.phpfiles and see if it still works.Pray...lots (OK, this isn'trequired, but it sounds like you'llneed it).

posted date: 2008-12-09 10:57:00


Re: Inherited a PHP nightmare, where to start?#6
Try to get detailed stats on the site and find out where the entry and exit points are. A decent way to find out what files are being hit off the top (and then look into those files to see which includes are being pulled).

posted date: 2008-12-09 10:58:00


Re: Inherited a PHP nightmare, where to start?#7
I would put everything into version control and then begin deleting. One can't really know if something in this mess could be useful.

posted date: 2008-12-09 11:00:00


Re: Inherited a PHP nightmare, where to start?#8
First step of course would be to put it under version control. This way at least you can go back to the original working version. Secondly it might be a good idea to overwrite the include, require, etc functions to, for example, write the filename of the file that's being included to some log file, this way you can find out which files are actually being included (thus hopefully ruling out a lot of the index2.php, index3.php, etc.To find out, if necessary, if some classes are used and some aren't, you can use get_declared_classes in conjuction with get_defined_vars and gettype to see which types are being instantiated.As for issue 4 and 5, those are probably a bit harder to solve, but this should get you started hopefully.

posted date: 2008-12-09 11:01:00


Re: Inherited a PHP nightmare, where to start?#9
Yeah, switch 2 and 3.

posted date: 2008-12-09 11:02:00


Re: Inherited a PHP nightmare, where to start?#10
I would:Sit down and take a deep breath;Decide if that's really where you want to work;Assuming yes, then I would roll up my sleaves, pick one mess to work on at a time and get to work.I know that we can't limit ourselves to just one task at a time; however, you can limit your work to solving one mess at a time while working on the daily tasks that come in.

posted date: 2008-12-09 11:09:00


Re: Inherited a PHP nightmare, where to start?#11
Personally, I disagree with Adam & Atesch. Leave 2 & 3 in the order they are in, so you don't mess up your version control. But obviously, make a back up before you start doing this ... and obviously ... don't do your cleanup on production.

posted date: 2008-12-09 11:17:00


Re: Inherited a PHP nightmare, where to start?#12
How does it mess up version control? Once you delete them, they're gone from the current revision and you don't have to think about them anymore. If, for whatever reason, you find you still need one (maybe one was used, and your tests didn't catch it), you can then go back and retrieve it.

posted date: 2008-12-09 11:20:00


select page: « 1 2...»
Copyright ©2008-2017 www.momige.com, all rights reserved.