Specifications

Even if all team members will be working on all pieces of the code, it’s generally a good idea
to assign primary responsibility for each component to a specific person. Ultimately this would
be the person who is responsible if something goes wrong with her component. Someone
should also take on the job of build manager—that is, the person who makes sure that all the
components are on track and working with the rest of the components. This person usually also
manages version control—we’ll talk about this more later in the chapter. This person can be
the project manager, or it can be allocated as a separate responsibility.
Using a Standard Directory Structure
When starting a project, you need to think about how your component structure will be
reflected in your Web site’s directory structure. Just as it is a bad idea to have one giant script
containing all functionality, it’s usually a bad idea to have one giant directory containing every-
thing. Decide how you are going to split it up between components, logic, content, and shared
code libraries. Document your structure and make sure that everybody working on the project
has a copy so that they can find things. This leads in to the next point.
Documenting and Sharing In-House Functions
As you develop function libraries, make them available to other programmers in your team.
Commonly, every programmer in a team writes her own set of database, date, or debugging
functions. This is a time waster. Make functions and classes available to others.
Remember that even if code is stored in an area or directory commonly available to your team,
they won’t know it’s there unless you tell them. Develop a system for documenting in-house
function libraries, and make it available to programmers on your team.
Implementing Version Control
Version control is the art of concurrent change management as applied to software develop-
ment. Version control systems generally act as a central repository or archive and supply a con-
trolled interface for accessing and sharing your code (and possibly documentation).
Imagine a situation in which you try to improve some code, but instead accidentally break it
and can’t roll it back to the way it was, no matter how hard you try. Or, you or a client decides
that an earlier version of the site was better. Or, you need to go back to a previous version for
legal reasons.
Imagine another situation in which two members of your programming team want to work on
the same file. They might both open and edit the file at the same time, overwriting each other’s
changes. They might both have a copy that they work on locally and change in different ways.
If you have thought about these things happening, one programmer might be sitting around
doing nothing while she waits for another to finish editing a file.
Using PHP and MySQL for Large Projects
C
HAPTER 22
22
USING PHP AND
MYSQL FOR
LARGE
PROJECTS
467
28 7842 CH22 3/6/01 3:37 PM Page 467