Tag Archive for 'php'


Managing Legacy Code While Remaining Somewhat Sane

I think every coder and every company that’s been around long enough arrives at a situation where for whatever reason, old code needs to be re-used. But not in a ‘Hey, I’ll grab this function from the site’ way but in a ‘Hey, we need to redo the frontend for this site without redesigning the code base’ way. But seemingly without fail, this code was created three versions of coding language ago using barely logical, much less programmatically sound, methods. As a coder, how do you avoid pulling out all your hair in an instance like this?

There could be a number of reasons for doing this. One, there may not be enough budget to redesign the code. The idea is that by not spending the time necessary to document and and then reprogram the code base, time is saved because the code, in theory, already works. Two, if no one really knows how the code works and a deadline is approaching, it may be hard to justify spending lead time on the process necessary to document code that seems to work. However, I might argue that when making a decision like this, one should consider the support time that might be required to ensure that everything is working properly once the site goes live, the time cost of combining two or more disparate types of code which may not want to ‘play nice’ with each other, and other similar factors.

Ultimately, whether or not to re-use or reappropriate legacy code depends on the budget, time constraints, and other business factors. If the person who designed the code is available, then this process is made easier; if not, the person who picks up the project has to make some tough decisions. If the decision is made to use legacy code, a developer’s best plan is to:

1) Be organized. Keep notes on everything and refer to those notes frequently. The code may be unorganized, but that doesn’t mean you have to be.

2) Have a plan and follow it throughout your development. If you have a certain way of formatting code, make sure you do it everywhere. Come up with way to address general problems you will encounter. If a function doesn’t work, are you going to rewrite it from scratch? Are you going to attempt to fix the code in-place? Whatever you decide, apply the same thing everywhere.

3) Be patient. Dealing with legacy code can be frustrating and slow. Take it one page / function at a time. Speed is always important, but never at the expense of good code.

4) Keep perspective. Yes, you will encounter crazy, illogical ways of doing things. You will not believe that someone could think this way. However, the point is not to let that distract you from the goal of creating good code. Create a ‘Wall of Fail’ like we have where we poke fun at these things.

So if you are presented with legacy code that needs to be reappropriated, try to follow these steps. If you do, hopefully at the end of the project you will be able to don a smoking jacket, and not a straitjacket.


Setting up PEAR on a Linux web server (CentOS)

Installing pear lets you take advantages of some really interesting way to extend PHP. This should be a fairly simple install, so we hope this helps.

First shell into your machine. This is a personal preference, but if you don’t have an “installs” directory, your home directory can get messy. Let’s cd into it.

% cd installs

Now get the pear code:

% wget http://pear.php.net/go-pear

What? No wget? Install wget and come back.

The following is at the top of the file that wget just downloaded, but they don’t seem to mention it, so we will. Just run this file as a php script from the command line.

% php -q go-pear

The only thing you need to change is the install path. The default is where you are now. Use /usr/local.

For some reason the default looks like this:

Below is a suggested file layout for your new PEAR installation.  To
change individual locations, type the number in front of the
directory.  Type 'all' to change all of them or simply press Enter to
accept these locations.

1. Installation prefix ($prefix) : /Users/mlavista
2. Temporary files directory     : $prefix/temp
3. Binaries directory            : $prefix/bin
4. PHP code directory ($php_dir) : $prefix/PEAR
5. Documentation base directory  : $php_dir/docs
6. Data base directory           : $php_dir/data
7. Tests base directory          : $php_dir/tests

1-7, 'all' or Enter to continue:

Type “1″ to change the path. Go with /usr/local/ and hit enter

The rest is all defaults and let it install.

To test, when you’re done check to see if it’s in your path:

% which pear

You should be all set. To install something

% pear install NAME_OF_MODULE