views:

69

answers:

5

I've just inherited a project, and been told that an entire folder, "includes/" needs to be removed due to licensing issues -- We don't have the right to redistribute the files in that folder, so we need to cut our dependencies on them, and fix whatever breaks. I've been told "Less than 5% of the lines in that folder are ever even called by our program", but I have no way of verifying this.

There are about 50 files in the folder, each with a couple hundred lines of code. There is no unit testing currently in place. There's one master file, include.php, that require()s all 49 other files, so I can't just grep for any file doing import() on 'includes/.*'.

This is about as much detail as I've really figured out at this point. I spent all last week reading through the files in the includes/ folder, and it won't be hard to rewrite any of this, but I'm having trouble deciding where to start. I tried deleting the folder and slowly fixing things that break, but I'm afraid that this route will cause me to miss some crucial functions in my rewrite.

Can anyone point me in a direction to get started? Are there tools that will simplify this process? I'm looking at xdebug right now, but I'm not sure exactly how I'd use it for this.

Thanks in advance!

+2  A: 

You may want to search for "php code coverage." That should help you figure out what code is used. For instance, this appears like it might help:

http://www.xdebug.org/docs/code_coverage

konforce
This is exactly how I'd like to do this. My final approach will, of course, be to delete the folder, but profiling for code coverage gives me a 100% complete view of exactly what I'll affect before I put anything into place.Thanks a ton!
linked
A: 

Your initial approach isn't bad at all. It's certainly a reasonable place to start:

  1. delete that code that isn't allowed.
  2. try to run what's left.
  3. if things break: create a stub for a method that is now missing, and set it to return some sensible "default" value for now.
  4. goto 2.

Then, itemize all the things that were missing, and make a sensible schedule to re-implement each thing.

Ether
A: 

I would start by grepping for files that reference include.php. Check through them if they're manageable, one by one. Then I'd grep for each of the functions in the /include/*php files. See if they're called anywhere, find 'em, replace 'em.

Because PHP is so dynamically typed, I don't think there's going to be a tool for this.

(Eagerly awaiting someone to prove me wrong because I have similar tasks all the time... )

Scott Saunders
A: 

See SD PHP Test Coverage Tool. It will provide a visual view of what code actually executes, as well as a report on what parts of files are used (including "no parts", which is your cue that the code is a likely candidate to delete).

It doesn't require any hand-modifications of your code, or any unit tests to run it.

Ira Baxter
A: 

To answer my own question, I wound up using xdebug profiler to do the job, as I was initially investigating (after a friend's suggestion prompted me to take a second look).

In my /etc/php5/apache2/conf.d/xdebug.ini (on ubuntu 9.10), I set xdebug.profiler_enable=1 and xdebug.profiler_output_dir=/var/log/xdebug/, then loaded up the resulting cachegrind files with KCacheGrind and just ran a search on filenames for "includes/".

Now I have a mountain of work ahead of me to remove all this, but at least I've got a good overview of what I'll be modifying!

linked