Programming Methodologies and Practices

Let's look briefly at the build process itself. There are a couple of best practice methodologies you may wish to adapt during the build process, regardless of the overall project process you have opted for.

Test-Driven Development

In the previous section of this book, you met PHPUnit, and with it you learned how to build Unit Testing frameworks. This knowledge can be applied, of course, only if you have built your application in a unit-driven fashion.

Test-driven development requires that you write the test before the code. The act of writing the test for the class in which you intend to code forces you to think about exactly how you mean to use a particular class, what it needs to do, and what its interface should be. PHP Unit (available through PEAR at http://pear.php.net) is a good framework for testing.

You will want to check that your unit test works before attempting to write the class itself. This may require using a dummy class with the same interface as that of your real class to make the test run and naturally fail.

The unit tests for that class, after being constructed, will probe the interface of your PHP class and analyze in detail the data it gets back. As a developer, your responsibility is to code the class in order to satisfy your unit tests.

Try to keep your unit tests as generic as possible; if you have numerous classes with similar interfaces, you can combine your unit tests into a single PHPUnit instance.

Using unit testing has numerous advantages, which are explored in more detail in Chapter 22, "Assembling the Sales Force Automation Toolkit.'' Whether it's right for your project is, once again, a judgment call. It is a testing methodology arguably much better suited to larger projects with more distinct components than to simple traditional "database applications.''

eXtreme Programming

The concept of eXtreme Programming, or XP, is perhaps the truest example of a programming paradigm. It is a paradigm in the sense that is perhaps more aspirational than it is practical in every development case. However, as a working model, it has many facets from which to pick and choose as required.

What is XP?

The description of XP is realized through a number of distinct working practices. They are too numerous to list in full, but we look at a few in detail.

The main goal of XP is to deliver quality software driven by the needs of the client. It achieves this goal by managing complexity. As a system grows more and more complex, the cost of adding and modifying features increases. But the reverse is also true: If the system does not get unnecessarily complex, then the cost of adding features later is roughly the same as adding features now.

This is a very powerful weapon, because traditional methodologies tend to follow the curve where the software modification cost increases significantly as more time is spent with all the phases of development.

For instance, it is more cost effective to add features in the requirements phase rather than during implementation, when it costs significantly more.

But, suppose your project development followed a curve where the costs of change grow more slowly and level off more quickly.

If you had the freedom to add, remove, and modify features whenever you'd like, then there would be pressure or reason to try to predetermine the entire feature set during the initial phases of the project.

The act of extreme programming is that of following a set of practices, best said by Kent Beck in Extreme Programming Explained:

• Planning Determine the scope of the project by combining business priorities and technical estimates, continually updated.

• Small releases Get the system used by the people to be using it and release new versions on a very short schedule.

• Simple Design Keep the design as simple as possible at all times. Complexity is removed on an ongoing basis.

• Testing Developers continually write unit-tests to ensure that the system runs flawlessly all the time. Customers write tests to demonstrate that features work as required.

• Refactoring Restructuring the code without modifying the behavior in order to keep it easy to read, to remove duplication, or to simplify.

• On-site customer The client should always be available to answer questions at all times throughout the development process.

The client, always being available throughout the build process, is in effect made part of the development process instead of simply driving it forward through his or her requirements. If at all possible, this is best accomplished by having the client, preferably some reasonably technical representative with domain expertise, on site at key stages during the development process. Don't worry about clients unnecessarily harassing your team; as long as they are suitably involved, your team will upward-manage the clients. This tenet of XP is particularly important in the attainment of elevated customer satisfaction; there can be no cries of "this isn't what I wanted'' if the customer has been involved from day one.

By creating unit tests for your classes before the classes themselves, you save time should your code not work the first time. Across a larger project with a number of distinct classes, this time saving can easily amount to days.

Using unit testing brings with it other benefits. Psychologically, it conditions software architects and engineers into considering more fully and thoroughly the requirements of a given component, meaning that the finished product is often a closer fit to the true requirements than a non-unit-driven approach would have permitted. In addition, there is a positive, direct impact on coding style that is highly beneficial to all those involved in the development process.

Second, it ensures that coding standards are determined early on in the project, and that the entirety of the development team sticks to them. There is no "code ownership,'' and as such any developer is allowed to modify any piece of code as long as the unit tests continue to work.

Perhaps the most famous aspect of XP is its permitting two software engineers, or perhaps a software architect and engineer, to code at a single workstation simultaneously. Generally, the best configuration is for both individuals to sit side by side but with one driving that is, controlling keyboard and mouse and another guiding the code-authoring process. With two people actively involved in the development of each piece of code, the business and technical expertise is not stuck inside any single developer's head, which makes for a more even distribution of information and avoids the project's being dependent on any specific developer. Besides, two heads are almost always better than one, and pair programming doesn't just affect the quality of code but also results in the reduction of bugs.

Finally, the most controversial of XP's tenets is that overtime that is, working programmers until they collapse is frowned upon. The argument is that if a project is properly specified, budgeted, and managed, there should be no need for overtime in the first place, and when overtime is generally needed, the project is doomed to late completion anyway.