C H A P T E R 14
■ ■ ■
Good (and Bad) Practice
So far in this book, I have focused on coding, concentrating particularly on the role of design in building
flexible and reusable tools and applications. Development doesn’t end with code, however. It is possible
to come away from books and courses with a solid understanding of a language, yet still encounter
problems when it comes to running and deploying a project.
In this chapter, I will move beyond code to introduce some of the tools and techniques that form the
underpinnings of a successful development process. This chapter will cover
- Third-party packages: Where to get them, when to use them
- Build: Creating and deploying packages
- Version control: Bringing harmony to the development process
- Documentation: Writing code that is easy to understand, use, and extend
- Unit testing: A tool for automated bug detection and prevention
- Continuous integration: Using this practice and set of tools to automate project
builds and tests and be alerted of problems as they occur
Beyond Code
When I first graduated from working on my own and took a place in a development team, I was
astonished at how much stuff other developers seemed to have to know. Good-natured arguments
simmered endlessly over issues of vital-seeming importance: Which is the best text editor? Should the
team standardize on an integrated development environment? Should we impose a coding standard?
How should we test our code? Should we document as we develop? Sometimes these issues seemed
more important than the code itself, and my colleagues seemed to have acquired their encyclopedic
knowledge of the domain through some strange process of osmosis.
The books I had read on PHP, Perl, and Java certainly didn’t stray from the code itself to any great
extent. As I have already discussed, most books on programming platforms rarely divert from their tight
focus on functions and syntax to take in code design. If design is off topic, you can be sure that wider
issues such as version control and testing are rarely discussed. This is not a criticism—if a book professes
to cover the main features of a language, it should be no surprise that this is all it does.
In learning about code, however, I found that I had neglected many of the mechanics of a project’s
day-to-day life. I discovered that some of these details were critical to the success or failure of projects I
helped develop. In this chapter, and in more detail in coming chapters, I will look beyond code to
explore some of the tools and techniques on which the success of your projects may depend.
Borrowing a Wheel
When faced with a challenging but discrete requirement in a project (the need to parse a particular
format, perhaps, or use a novel protocol in talking to a remote server), there is a lot to be said for