Design it right

The choices that you make initially affect your degrees of freedom when you code later. This makes proper design an important prerequisite. While design can become an extra ceremony when you are solving a trivial problem, you must at least acknowledge that this is the case. Many people think of design and planning as extra overhead. But starting with a bad design, or no design at all, always results in slip-shod code. Remember, no amount of clever coding can compensate for bad design. Although how to design applications is beyond the scope of this series of articles, I will suggest some issues that you should keep in mind when designing Web applications.

Divide and conquer

It is always preferable to design and code a big application in smaller loosely coupled parts. Then, each part stays maintainable. For example, a Content Management System (CMS) may be distributed over many smaller modules like user authentication, presentation, content parsing, and viewing statistics. And if your modules are generic enough, you can reuse your code in other applications that you develop. Programmers often do this and still complain. For coding, the trick is to let each module have the functionality it absolutely needs and stop there. Give a module nothing more and nothing less.

Never think in pages

If you took interest in PHP to make your HTML pages more dynamic, this bit is for you. This habit generally starts when you want the date and time displayed on every page to make it look fresh. Every HTML page turns into a small PHP script with a skimpy line with the date function tucked in somewhere. If this is what one wants, one must agree that this is the simplest way of getting the job done. But just imagine what you will have to do to change the format of the date that appears on the page. You will have to change the code in every page.

There are obviously better ways to do this. My favorite is to use a configuration file and define a constant in it that holds the format string for the date() function. You can then use the date() function wherever you need it. Every page will still end in a script, but you will have drastically minimized places where you must make a change to a single line of code.

Figure 1. Avoid hard-wiring code

As shown in Figure 1, a change in the date format will be visible on all the pages. The idea here is to avoid duplicating and hard-wiring code. Keep this in mind when writing large applications. When you avoid duplicating code, you make debugging and maintenance easier.

Reduce client-side requirements

The types of Web pages and applications have grown in many directions. First it was image and image maps, then Java applets and client-side scripts that did cool animations. Today it is Flash. It is good to have impact, but one must remember the whole idea behind the Web was to make information accessible to anyone who wanted it at any time. By employing technology that not all browsers and platforms support, you deny information to people. The person that could not access your Web site may have been your next customer!

Your application design should minimize network traffic as much as possible. It is common to see sites that go over-the-top and give browsers an assortment of cookies just to work. Juggling a lot of cookies not only consumes bandwidth, but also makes things unmanageable. As a rule of thumb, if your application sends more than 40 KB of data or if your page requires more than 5 seconds to load, it is time to take the application back to the drawing board. Small tweaks here and there do not last for long. If you look around, the most popular and visited sites are very simple.

You should also take into account the next wave of mobile devices and the connection they will use to access your application. As a best practice, your application must tailor content according to the client that is requesting it. As Leon Atkinson puts it in his book Core PHP Programming, page 720, "We can try to keep the size of the HTML documents small, and we can try to avoid complex HTML like nested tables, but we can't upgrade everyone's 28.8 modem".

Separate code, content and presentation

HTML is a markup language to present content and PHP is an HTML-embedded scripting language. This does make simple tasks easy -- take the date example, for instance. However, when you have complex requirements to implement, embedding PHP in HTML takes away simplicity from the code. Separating code, content, and presentation as much as possible is good. Consider this very document you are reading. This document was first created as an XML file. HTML and PDF versions were automatically generated using style sheets. The code (application that shows you this page), content (the XML document) and presentation (style sheets) are different.

Just as encapsulating core functionality in modules and avoiding code duplication is important, using a single source for content and presenting the content the way it is wanted on demand is also important. Your flexibility to tailor pages according to the client and connection speeds is increased. Another spin-off is that programmers, designers, and writers work independently of each other -- a good thing if you are handling a large project.

Don't be afraid to scrap designs

No matter what anyone tells you, application design is best learned by practice. If you are just getting started, you may make many mistakes -- that is how you learn. Bad designs deserve to be scrapped. That is why you must keep code, content, and presentation loosely coupled -- scrapping bad designs becomes a lesser pain. You can keep the content and the presentation while losing your older code to something better.

Now, back to what I promised, making your code rock-solid. You must remember at all times that your code will power someone else's content and presentation. If your code is not up to it, no amount of spectacular efforts from other departments can make up for deficiencies.