■Chapter 14: Good (and Bad) Practice ................................................................
building a component that addresses the need. It can also be one of the best ways to learn your craft. In
creating a package, you gain insight into a problem and file away new techniques that might have wider
application. You invest at once in your project and in your own skills. By keeping functionality internal
to your system, you can save your users from having to download third-party packages. Occasionally,
too, you may sidestep thorny licensing issues. There’s nothing like the sense of satisfaction you can get
when you test a component you designed yourself and find that, wonder of wonders, it works—it does
exactly what you wrote on the tin.
There is a dark side to all this, of course. Many packages represent an investment of thousands of
man-hours: a resource that you may not have on hand. You may be able to address this by developing
only the functionality needed specifically by your project, while a third-party tool might fulfill a myriad
of other needs as well. The question remains though: if a freely available tool exists, why are you
squandering your talents in reproducing it? Do you have the time and resources to develop, test, and
debug your package? Might not this time be better deployed elsewhere?
I am one of the worst offenders when it comes to wheel reinvention. Picking apart problems and
inventing solutions to them is a fundamental part of what we do as coders. Getting down to some
serious architecture is a more rewarding prospect than writing some glue to stitch together three or four
existing components. When this temptation comes over me, I remind myself of projects past. Although
the choice to build from scratch has never killed a project in my experience, I have seen it devour
schedules and murder profit margins. There I sit with a manic gleam in my eye, hatching plots and
spinning class diagrams, failing to notice as I obsess over the details of my component that the big
picture is now a distant memory.
Now, when I map out a project, I try to develop a feel for what belongs inside the codebase and what
should be treated as a third-party requirement. For example, your application may generate (or read) an
RSS feed; you may need to validate e-mail addresses and automate mailouts, authenticate users, or read
from a standard-format configuration file. All of these needs can be fulfilled by external packages.
Once you have defined your needs, your first stop should be the PEAR web site at
http://pear.php.net. PEAR (PHP Extension and Application Repository) is an officially maintained and
quality-controlled repository of packages. It is also a mechanism for installing packages seamlessly and
managing package interdependencies. I will cover PEAR in more detail in the next chapter, in which I
look at the way that you can use PEAR functionality to prepare your own packages. To give you some
idea of what’s available in the PEAR repository, here are just a very few of the things you can do with
PEAR packages:
- Cache output with Cache_Lite.
- Test the efficiency of your code with Benchmark.
- Abstract the details of database access with MDB2.
- Manipulate Apache .htaccess files with File_HtAccess.
- Extract or encode news feeds with XML_RSS.
- Send mail with attachments with Mail_Mime.
- Parse configuration file formats with Config.
- Password protected environments with Auth.
The PEAR web site provides a list of packages categorized by topic. You may find packages that
broadly address your needs there, or you may need to cast your net wider (using the major search
engines). Either way, you should always take time to assess existing packages before setting out to
potentially reinvent that wheel.
The fact that you have a need, and that a package exists to address it, should not be the start and end
of your deliberations. Although it is preferable to use a package where it will save you otherwise
unnecessary development, in some cases, it can add an overhead without real gain. Your client’s need
for your application to send mail, for example, does not mean that you should automatically use PEAR’s