The importance of planning is stressed throughout this book. Although not every job allows for a good deal of planning up front, it's always best to fight for the time to properly plan your applications. Once you've invested the effort to plan your application, coding it almost becomes a breeze.
Formal Software Development Processes
There are any number of formal software development processes you might use; all have certain features in common, such as writing a specification, developing testing protocols, and so forth. If you work for a company that builds software for the government, you may be required to adhere to a software development process defined by a standard, such as ISO 12207 (ISO stands for International Standards Organization). Or, perhaps your company uses a less formal approach such as Rapid Application Development, in which several developers share responsibility for rapidly creating and modifying the workings of an application.
Whichever development process is used, following formal procedures in a standard way increases the odds of successfully completing the project on time and within budget. As you can imagine, a scattershot approach is very inefficient, especially if there are multiple developers at work.
That said, it isn't unusual for even the most well-managed projects to have delays, changing specifications, mistakes, hard-to-find bugs, and so on. That just means that deciding upon and following a formal procedure is more important than ever.
The next few sections discuss some of the basic features that formal software development processes share.
Writing a Specification
Writing a specification is a great first step, but one that's often ignored or slighted because it is often difficult to accurately and completely define what the final product should be. If you've ever read about how movies are made, for example, you know that the finished product may bear little resemblance to the original book or screenplay. A movie may not follow the script exactly, but there is always a script—it'd be very hard to convince anyone to put up money to make a movie without a script.
How much specification writing should be used for various applications? Let me give you some analogies to photography or movie-making:
- Snapshot: Some applications are like amateur photography—an abrupt snapshot and that's it. Of course, the result you get is much like that quick photograph, but sometimes that's all you need. A minimal application, such as displaying the current date on a Web site, doesn't really require any written specification. Little thought is used in deciding its location, and certainly no heavy thinking is involved in writing the code.
- Portrait: Even small applications, if done competently, are more like professional photography. The lighting is good, the subject is framed properly, and the quality of the image is excellent. They cost a bit more in both money and time, but some thought is put into how the result looks onscreen, and the color, font, weight, and size of the text. The programming is commented correctly, with proper use of conventions (even for a very small application). One or two paragraphs of specification may be all that is needed to completely define what's required.
- Commercials: Commercials are much more expensive, professionally done, and scripted. They are akin to small but professionally designed applications for a specific use. Likely there is little improvisation in them, and it's pretty easy to predefine (and ensure during production) all aspects of the process so that the final product is very closely aligned with the original script and goals of the production. Applications such as an e-mail newsletter manager are similar in that they are fairly simple in design and architecture. A good specification can be created in advance of production, and can be followed to completion without much deviation.
- Movie: A movie is like a very complex application in that it even though it may be scripted from end to end, the final cut may be very different from what was originally specified. That's because many of the final decisions are made once filming is finished, and depend upon the reaction of the filmmakers to what they have on film. A complex application is similar because you often won't know what is good or bad (or unnecessary) about the application you've created until beta testers or users use it a bit. And as an expensive project, once you're committed to it, it deserves as much modification as needed to make it right (from the user's standpoint, making it right can be summed up as "it works").
The point of these analogies is that some projects don't require much (if any) specification, and others require lots, but even when a good specification is created prior to any coding, there's still likely to be much change and retooling as the application takes shape. And that leads directly into the next subject, the coding process.
The Coding Process
There's a school of thought that says, "If you program all the little functions independently, then put them together, you'll have a finished application." The idea is that, if you can define what each part is supposed to do, and program that, then you should be able to put all of the parts together and have a working application. This is true to a degree, but often what distinguishes a (technically) working application from a great application is how well integrated the parts are (how efficiently and elegantly they work together).
The ease with which other people grasp how to use the application is also very important. Because many applications are intended for use by people, and people have varying perceptions and understandings of words, images, forms, and so on, the design of user interfaces is actually more art than science.
Given that there are so many tools that make it easy to develop a working model of an application fast, it's no surprise that Rapid Application Design (RAD) and Extreme Programming are popular. There are several definitions of RAD, but basically it means quickly developing a user interface that does the required tasks, and exposing it to users early in the development cycle. This is a relatively inexpensive process, and because you repeat the process several times quickly, you can hone in on a user-friendly design in a very short time. Once you have a good feel for all the aspects that are needed to satisfy the basic goals of the application, you can then spend the effort to properly organize, document, and optimize your application.
Extreme Programming is similar to RAD, but generally means you use two programmers to write the code so that they can assist each other, fill in for each other if one must take a break (or leaves the company), and otherwise arrive at the solution much quicker. Extreme Programming puts into practice the notion that "two heads are better than one," with real results in many cases.
Testing, Debugging, and Maintenance
Ever hear of a program or application that stopped at version 1.0? A program that was designed so well that it's never needed a revision, change, update, bug fix, etc.? Of course, not. There aren't any! And for good reason. Not only do most applications have bugs even after they're released, there's really no end to bugs, only the prospect of getting them to be insignificant enough so that for most people, under most circumstances, the application works well.
In addition, the environment in which applications operate (including protocols, operating systems, and other applications) changes constantly. And sharp hackers continually find new and interesting ways to defeat security and crack applications. Finally, good users will provide comments about other features they'd like in the application.
The bottom line is that the cycle of testing, debugging, and improving applications doesn't really end, but the rate of fixes and changes drops to a manageable level and becomes maintenance. This portion of the development process can't be avoided, but there's always the capability to manage the process well.
Optimizing Your Code
Imagine for a moment that you have 1,000 Web pages, and that each needs to display the current date and today's welcome message. Knowing PHP, you immediately see that it would be less work to have the pages dynamically generate the date and a message via a line or two of PHP code than to manually update 1,000 pages every day.
But you also want some way to write the code once and insert it into all the pages dynamically, so that if you ever changed the message it would change across all the pages at once. And of course, this common problem is solved easily in a number of ways with PHP functions such as include and require.
Using PHP and other functions to save yourself work is one way to optimize your code. Optimization isn't limited to just reusing code; the word also describes many techniques you can use to make your code run faster and more efficiently (using less computational resources such as CPU cycles, RAM, or hard drive space), to avoid rewriting code, or to make your programs easier to debug or maintain.
The rest of this chapter focuses in detail on practices that can save you lots of time and make your code more robust as well. These practices include formal coding standards, writing program logic as functions, and using the require() and require_once() functions.
