COM372: Notes, Chapter 25

Using PHP and MySQL for Large Projects
pages 535-549

As we undertook the relatively simple assignments of building a database-driven front end (assignment 6) and a secure back end for administering the database (assignments 7 and 8), we did so in a coding structure using Select...Case, keeping code segments organized on a single page. This made it easy to see that our code had quickly grown to a few hundred lines, and we began to experience a degree of frustration as we hunted down sections to fix bugs, etc. With more complex and larger-scale coding tasks awaiting us, chapter 25 causes us to pause and reflect on coding practices that might make scaling up a lot easier. This includes using principles of software engineering, planning, reusing code, writing code that is easier to maintain, keeping track of new versions, documenting, and prototyping, as well as simple good coding practices for writing well structured, valid html, css, and php.

Software Engineering: Larger projects and increased functionality mean more code, and more complex code. This takes greater planning and organization.

Planning and Executing:

• All web projects need to begin with pre-project planning. The first step in every project is audience identification, asking "Who will be using this project?", "What will they expect to find here?", and "What behavior(s) do I expect to change in my target audience as a result of their using my website?" (Website Redesign 2, by Kelly Goto and Emily Cotler, is an excellent guide to all aspects of project development, from client survey to launch and followup).
• Break the project into components. Break the components into tasks. Assign the tasks to staff, if you have separate experts. Modularize.
• Don't reinvent (you don't have time and your client doesn't have money)! When feasible, use existing code—yours, public domain, or purchased. It makes no sense to use up hours (think $'s) of your programming time when you can acquire and use existing open source code, or purchase commercial applications for less.
• Make (and in teams, share) decisions on coding standards, directory structures, version management, development environment, documentation, and task assignments.
• Build prototypes (site maps, wire frames) and share. Build iteratively.
• Test as you build.

Reusing Code: Before writing code from scratch, look for code already written into function libraries, browsing the online php manual function reference, for example, by function group to see whether existing code can't do what you want. The manual also includes numerous user comments, appended to each function, and these may be helpful.

Maintainable code:

Coding Standards
• Naming conventions. Conventions make code easy to read, more like English. Make identifier names easy to remember. Variable names should describe the data they contain. Balance conciseness with clarity in choosing names. Be consistent in your use of capitalization (PHP variable names are case sensitive; function names are not); a good suggestion is to use all lowercase for variables, and all uppercase for constants. Be consistent in formatting multi-word variable names ($firstname, $FirstName, $first_name, etc.)
• Comment code. Comment files, explaining what they do, who wrote it, and when it was last updated. Comment functions, with purpose, input expected, and what it returns. Comment class purpose and treat methods as any other function. Comment code blocks within scripts; these comments can provide an initial outline for the block, guiding you as you then fill in the code itself, leaving the comments in place. Make note of complex code so that you will understand it the next time you read it. Comment as you go, or it won't get done.
• Indent. The extra spaces in php won't be downloaded to the client, so there is no performance hit for setting up your code in a way that makes the branches and loops clear. Indent any code block inside a branching structure; use 2 or 3 spaces, but don't tab. Be consistent in laying out curly braces, too.
• Break up code: Putting code into functions and / or classes, or into include files,
  • Makes for easier to read code
  • Makes code reusable, reducing redundancy
  • Facilitates teamwork
• Use a standard directory structure. Modularize file, organize, and document.

Version Control: You want to keep archives of previous versions of code, both as a fall-back when newer versions fail, or as an option should a client decide they prefer the older version instead. Also, when a team may be working on a code block simulateously, implement a Concurrent Versions System that tracks changes, making sure that two versions are compatible. Dreamweaver allows file checking (check in, check out) for this purpose, and there are other CVS versions available (p. 542).

Choosing a development environment: Code environments facilitate and expedite code building. What can i say? Use Dreamweaver until you find something better (and then write to tell me about it!)

Documenting: Keep written notes on design, techniques used by the developer, and a data dictionary for databases. Several utilities for assisting with this are listed, page 544.

Prototyping: Prototypes are preliminary versions of pages, with limited functionality and little if any attention to visual design. Wireframes are one form of prototype, allowing you to see a preliminary layout for text and images, without the actual text or images. Prototypes allow you to discuss with a client the basic layout of the site, paths through pages, etc., without having to make a final page. (again, see Goto and Cotler, Website Redesign 2)

Separating Logic and Content: As you have separated content from layout via php, also separate content from programming (i.e., html from php) as much as possible.

• Use include files and functions
• Use functions or class API's to plug sets of member functions into pages
• Use templates for redundant page designs. (see Smarty)

Optimizing code: Delays in the web come mainly from client-server connect and download time. Writing lean, minimum characters html output is therefore important. Less important is the reduction of code size or execution time for php, as this runs on the server and is generally quick, relative to client-server times. Connections to databases may take time (more so if the database is on another computer, and obviously if there are many or frequent connections), so the primary focus on the server is to optimize these:

• Reduce the number of connections, if possible
• Reduce the number of queries, and write them with as few joins as possible
• Minimize the number of separate echo or print() functions to generate static html.
• Use string functions instead of regular expressions where possible (they run faster)
• Use single-quoted strings instead of double-quoted, which are parsed in search of variables to replace (single-quoted strings are not parsed, so they are faster).

The Zend Optimizer: Zend, which makes the php scripting engine, also makes an optimizer, available as a download (here).

Testing: Have someone else look at your final code, looking for errors, test cases you haven't considered, optimization, security, existing components to replace code you have written, and additional functionality.

Try to have real users test your applications as well, especially with an eye to usuability. Offer incentives in exchange for feedback on a beta release, to see what users can come up with. If you are building for a corporate client, get some actual staff users to try it out and provide feedback.