Product Description
This book doesn't tell you how to write faster code, or how to write code with fewer memory leaks, or even how to debug code at all. What it does tell you is how to build your product in better ways, how to keep track of the code that you write, and how to track the bugs in your code. Plus some more things you'll wish you had known before starting a project.
Practical Development Environments is a guide, a collection of advice about real development environments for small to medium-sized projects and groups. Each of the chapters considers a different kind of tool - tools for tracking versions of files, build tools, testing tools, bug-tracking tools, tools for creating documentation, and tools for creating packaged releases. Each chapter discusses what you should look for in that kind of tool and what to avoid, and also describes some good ideas, bad ideas, and annoying experiences for each area. Specific instances of each type of tool are described in enough detail so that you can decide which ones you want to investigate further.
Developers want to write code, not maintain makefiles. Writers want to write content instead of manage templates. IT provides machines, but doesn't have time to maintain all the different tools. Managers want the product to move smoothly from development to release, and are interested in tools to help this happen more often. Whether as a full-time position or just because they are helpful, all projects have toolsmiths: making choices about tools, installing them, and then maintaining the tools that everyone else depends upon. This book is especially for everyone who ends up being a toolsmith for his or her group.
From the Publisher
About the Author
Matthew Doar has been a professional toolsmith and software developer for over ten years at a number of different companies. He wrote this book because he was frustrated with the lack of books about how to create good software development environments. He also wrote JDiff, an open source tool for comparing the APIs of different versions of large Java projects. He has a Ph.D. in computer networking from the University of Cambridge.
Excerpted from Practical Development Environments by Matthew Doar. Copyright © 2005. Reprinted by permission. All rights reserved.
This chapter briefly describes the different parts of a project and then introduces the main activities involved in software development and the corresponding tools that make up a development environment. The activities are software configuration management (SCM), building software, testing software, tracking bugs, writing documentation, releasing products, and maintenance. This chapter ends with some personal recommendations of tools for three different types of development environments.
Whether you are starting a project from scratch or looking to improve an existing development environment, my opinion is that you should consider the different parts of the environment in the same order used in this chapter and in this book. That is, SCM is the most important part of an environment; next in importance are the build tools, then testing and bug tracking, and so on. This is because your choice of SCM tool is likely to have the largest impact on your environment. This is not to say that any of the parts are unimportant, just that improving how your SCM tool and build tool are used will probably improve your environment more than improving the bug tracking tool or release process. Similarly, if you are creating a new project, an SCM tool should be chosen before a bug tracking tool.
The Parts of a Project
Figure 2-1 shows the different parts of a single project. This project has source files that become products, and those products have customers who use the products. The project has project members (developers, testers, technical writers, tool smiths, managers, and product marketing staff), who are also customers for their own products. The development environment for this project is made up of both the tools and the local processes and policies for using those tools.
If there are many projects within an organization, then each project will have some areas that overlap and some that don’t. For instance, two projects may have different policies about how to use the same bug tracking tool. The processes and tools are chosen to work with the source files but need to be able to operate even when the same source files are used by different projects with different policies.
Software Configuration Management
SCM, the subject of Chapter 4,is the ability to keep track of different versions of the source files that are used to create software products. Even when just one person is changing these source files, it ’s very useful to be able to see how a file evolved over time or even to undo some changes that in hindsight you regret making. As projects grow in size and complexity, effective SCM tools become vital. To put it another way, projects that don ’t use an SCM tool won ’t grow successfully.
SCM tools also provide a good way to share your work with other people in a controlled manner. Rather than just using a common location such as a directory to exchange files with other people, with an SCM tool you can make sure that interdependent files are changed together and you can control who is allowed to make changes. SCM tools also allow you to save messages about what changed in the source files, and also why the files were changed, which can be used to work out which releases a particular bug was fixed in.
Many SCM tools provide ways to support one or more existing releases of a product, while still allowing the team to develop the next release using different versions of the same source files. For instance, after a product is released, all the source files for that release can be marked (or even branched )to allow future bug fixes for that release, while the next release is developed independently.
Chapter 4 describes all of the above in more detail and examines seven of the most commonly used or promising SCM tools: CVS, Subversion, Arch, Perforce, BitKeeper, ClearCase, and Visual SourceSafe.
Building Software
Software products are built from their source files, also known as source code , which is often the collection of files stored in an SCM tool. A build tool uses the source files and follows some specified build rules to run other tools such as compilers to create the product from the source files. These build rules are usually specified in configuration files known as build files, which are part of the source files for a product.
Build tools have to be aware of which products can be built from a given set of source files and other files such as libraries. They also have to know which parts of the product depend on which other parts, so that if one source file is changed by a developer, then all the other affected parts will also be rebuilt. Build tools should be able to execute the correct commands for building the same product on different platforms, while hiding the idiosyncrasies of each platform from the product ’s developers as much as possible. Build tools are also used to generate executables that run on platforms other than the platform that the build tool is actually run on; this is known as cross-compiling.
Chapter 5 describes what to look for in a build tool and examines some commonly used build tools such as make, Ant, Jam, and SCons in more detail.
Testing Software
Testing a product spans the range from individual developers writing unit tests that check small parts of an application, to system tests that use the whole application, to customers giving feedback about how they really want the product to work. Chapter 6 focuses on, testing environments for unit tests and system tests.
One of the cornerstones of the XP (extreme programming) methodology is the importance of extensive unit tests, written even before the functionality that they test has been written. No matter what your methodology or style of programming is, a healthy test suite is good for reassuring yourself that your latest changes haven ’t broken some other distant part of the product.
