Inherited a PHP nightmare, where to start? [closed]

Answer 1

Consider a re-write and use the old site as a feature specification

Surprisingly, no one even mentioned this, as far as I can see, but there is another alternative: give up on the code and just use the functionality of the site itself as a new feature set specification (i.e., the first one ever for this project) and then re-build the site, based on those features, with an established framework (such as Symfony, Laravel, or Drupal).

Yes, there are those who would cringe at the evil word re-write ... but there are cases when this is actually a better way to go, and you hinted at some reasons:

• you're fairly new to PHP development, yourself
• you will probably be better off starting out with something clean instead of the pure crap code you've inherited
• in the final analysis, most users don't give a damn about the source code, and if it looks like it "works" to them, they may look at you like you're crazy if you try to tell them something is dreadfully wrong
• you will have more fun and live a longer life if you pick up the practices of source revision control and database design within a unified framework that looks like someone actually cared enough to have their name attached to it

Sure, everyone in this position has had to work with code like this before, but sometimes enough is enough and it's better to scrap the spaghetti and start with a fresh plate.

If you read Joel's article on why it's bad to do a re-write, you will notice almost none of the circumstances he cites apply to you here.

Answer 2

I've done this. You have my sympathy. If your passport isn't current or for some other reason you can't dodge doing this, here's how I'd approach it:

Step Zero is to get it into version control, no matter how crappy it is. If it even kind of works, and you break something, you need to be able to go back to the working state - or at least compare your changes to it to figure out what went wrong. Do frequent, small check-ins as you're refactoring, and you'll have less code to roll back when things mysteriously go wrong. (Things WILL mysteriously go wrong.)

After that, I'd start at the database. Make sure everything is relatively well-normalized, columns are clearly named, etc.

Do the PHP code next. If the code is really that much of a patchwork, I'd go ahead and fit it to a framework. Look into CakePHP or Symfony - their Rails-ish manner of separating concerns makes the question "where should this piece of code go?" easy to answer. It's not a small task, but once you've done it, you're probably better than half-way to having a sanely-constructed app. Also, the built-in test facilities of a good web framework make refactoring FAR easier - write a test to cover an existing piece of functionality before you change it, and you'll know whether you broke anything after the change.

Once you've got your database sorted and have the model code in the models and the controller code in the controllers, then you can worry about presentation-level stuff like standardizing on a single JS/AJAX library, cleaning up CSS, etc.

As for a dev environment: You should absolutely set up a local dev environment. There are turnkey WAMP packages out there, or you could install to a Linux box/VM (I recommend VirtualBox for virtualization). You should also have a separate integration test environment that mimics the live server. Nothing but live code should run on the live server.

As far as debug/profiling tools, I know that Symfony comes with a pretty slick set of tools, including a little JS toolbar that comes up on your pages (only in debug mode) with logging & profiling information.

Good luck.

Answer 3

I know how you feel. I inherited the development of such a project. It stayed with me for a year and to be honest it made me the developer I am today. There is no better opportunity for personal advancement than working knee deep in shit.

Here are the things that helped me to most:

• identify which are the key files of the system. You will find them because the most of your work will be done in them
• create a local version of the project (including the database) and put it under version control
• work only on a small amount of files with small changes
• do not put anything inside the production version until you have it tested thoroughly, and then be ready to put the old version back

• find out how the users of the system are handled (sessions , cookies). Create a super user and then when you need to test your code live on the system put it in a block like this:

  if($_POST['your_registered_user_name']{
     //Your live code being tested, which will be visible only to you when you are logged in
  }
  

  other users wont be able to feel the changes. This technique helped me a lot when I was unable to replace the system state on my local machine

• write test, and follow strict engineering guidelines for all the code you are writing