CHAPTER 14 ■ GOOD (AND BAD) PRACTICEMail package. PHP provides a perfectly good mail() function, so initially this would probably be your
first stop. As soon as you realize that you have a requirement to validate all e-mail addresses according
to the RFC822 standard and that the design team wants to send image attachments with the e-mails, you
may begin to weigh the options differently. As it happens, there are PEAR packages for both these
features.
Many programmers, myself included, often place too much emphasis on the creation of original
code, sometimes to the detriment of their projects. This emphasis on authorship may be one reason that
there often seems to be more creation than actual use of reusable code.
Effective programmers see original code as just one of the tools available to aid them in engineering
a project’s successful outcome. Such programmers look at the resources they have at hand and deploy
them effectively. If a package exists to take some strain, then that is a win. To steal and paraphrase an
aphorism from the Perl world: good coders are lazy.
Playing Nice
The truth of Sartre’s famous dictum that “Hell is other people” is proved on a daily basis in some
software projects. This might describe the relationship between clients and developers, symptomized by
the many ways that lack of communication leads to creeping features and skewed priorities. But the cap
fits too for happily communicative and cooperative team members when it comes to sharing code.
As soon as a project has more than one developer, version control becomes an issue. A single coder
may work on code in place, saving a copy of her working directory at key points in development.
Introduce another programmer to the mix, and this strategy breaks down in minutes. If the new
developer works in the same development directory, then there is a real chance that one programmer
will overwrite the work of his colleague when saving, unless both are very careful to always work on
different files.
Alternatively, our two developers can each take a version of the codebase to work on separately.
That works fine until the moment comes to reconcile the two versions. Unless the developers have
worked on entirely different sets of files, the task of merging two or more development strands rapidly
becomes an enormous headache.
This is where Subversion and similar tools come in. Using Subversion, you can check out your own
version of a codebase and work on it until you are happy with the result. You can then update your
version with any changes that your colleagues have been making. Subversion will automatically merge
these changes into your files, notifying you of any conflicts it cannot handle. Once you have tested this
new hybrid, you can save it to the central Subversion repository, making it available to other developers.
Subversion provides you with other benefits. It keeps a complete record of all stages of a project, so
you can roll back to, or grab a snapshot of, any point in the project’s lifetime. You can also create
branches, so that you can maintain a public release at the same time as a bleeding-edge development
version.
Once you have used version control on a project, you will not want to attempt another without it.
Working simultaneously with multiple branches of a project can be a conceptual challenge, especially at
first, but the benefits soon become clear. Version control is just too useful to live without. I cover
Subversion in Chapter 17.
Giving Your Code Wings
Have you ever seen your code grounded because it is just too hard to install? This is especially true for
projects that are developed in place. Such projects settle into their context, with passwords and
directories, databases and helper application invocations programmed right into the code. Deploying a
project of this kind can be a major undertaking, with teams of programmers picking through source
code to amend settings so that they fit the new environment.