1. Plan. Do some design mockups, work out what functionality will go in what classes. You can never plan enough, and good planning can save you days of code rewriting later.
2. Research. This is probably one of the most-forgotten areas of project planning. Chances are what you’re building has been done before, so do a bit of research on existing applications similar to yours. Consider any problems you may encounter and see how other applications handled these challenges. SourceForge is a great place to start.
3. Future proof. Depending on your application, this might not be terribly important, but consider what technologies are being used at the moment and may start being used. This article has a few suggestions. For example, maybe in future you’ll add a microformat-export function, and your code needs to be structured differently to support that?
4. Don’t reinvent the wheel. Most developers I’ve seen simply don’t practice this enough. Sure, you’re using your framework for some common tasks, but many people assume they’ll need to write a lot of their own code for complex routines. Before you start, check out PEAR and PHP Classes.
5. Set some timeframes and get into it! Now that you have a good idea of what you’re going to build, and how you’ll make it happen, set some goals and get coding!

1. Frameworks
Frameworks are arguably one of the most important areas of PHP development. With no single accepted way of developing web applications in PHP, a number of open source frameworks are available, helping you code quicker, more consistently and more effectively. Some of the best include CakePHP, Symfony and CodeIgniter. A lot of the frameworks also follow the MVC design pattern, which you should definitely be familiar with should you ever have to work on code that follows it. After a while, you may even feel inclined to create your own framework to meet your needs.

2. Templating engines
If you’re not using a framework that enforces a specific design pattern, chances are you want to be using a templating engine. Whether you create your own or using one of the existing options (like Smarty), a templating engine allows you to entirely seperate your code logic from your HTML interface code (and associated CSS/JS/etc.). This considerably simplifies your code, allows quick and easy modifications to the actual front-end of your application, and makes it easier for non-developers to modify your application’s visuals.

3. Code availability
As I mentioned in a previous post, PHP has some of the best code availability of any language. From various snippet archives to entire class databases, PHP developers are really spoilt for choice when it comes to reusing existing code. In fact, you can almost get away with building an entire application without writing a single line of code.

4. Don’t reinvent the wheel
This might seem fairly obvious, and a little part of the previous point, but very few PHP developers realise how much power is already available as part of PHP itself. Forget pulling in new libraries, or writing long complex code routines - first take a look at the PHP manual. For example, have you ever heard of number_format(), parse_url(), wordwrap() or bbcode_parse()? Take a look at the entire function reference, pick a category and have a browse - you’re bound to find something new.

5. IRC is a wonderful thing
For when you’re stuck on a complex problem that you just can’t make sense of, hop on IRC. The ##php unofficial support channel on Freenode is always full of experienced PHP developers happy. You’ll need an IRC client - ChatZilla is great if you’ve got Firefox - and a little patience; when you need help, pastebin your code and head to irc://irc.freenode.net/php. Post your question and wait patiently; some kind soul (or multiple kind souls!) will answer. When you’ve finished, consider lurking in the channel to help others with their problems. No man is a mountain, especially with PHP’s enormous library of functions; on IRC, the pool of collective knowledge can solve just about any problem.

Of course, it isn’t nearly that simple. Everyone writes code differently; different naming conventions, different approaches to achieving common tasks (e.g. configuration), even different ways of interacting with the code (functions, classes static/non-static etc.). The problem is compounded when you start using a framework, with the intention of enforcing some basic convention - convention which your existing code libraries may not follow.

Frameworks can’t - and shouldn’t - include masses of functionality by default; an easy way to extend them with existing code is pretty important. Of all the PHP frameworks I’ve tried, CodeIgniter seems to have one of the most flexible approaches; drop a class into the libraries folder, and as long as it doesn’t need data passed through the constructor, chances are it just works. (Slight filename and class name changes might be necessary).

I’ve managed this effortlessly with an XML parsing class from phpclasses.org: in under two minutes I had added an XML parser interface that I could use just like any native CodeIgniter library.

So, how have your attempts at code reuse inside frameworks gone? I haven’t had a chance to test CakePHP yet; please comment if you’ve tried it in the past.