Developer Best Practices

In this section, we describe some of the more popular best practices for designing, implementing, and unit-testing code; we also indicate when the practices are applicable . Many of these practices have been around for some time but have been further elaborated on and popularized by the Agile Movement, especially XP. ^[4] Some of these best practices were described earlier in this chapter:

^[4] See Beck 2000.

• Test frequently (see the sections Developer Testing and Produce a Build).

• Integrate continuously (see the section Frequently Integrate Your Application with the Work of Other Developers).

• Perform runtime analysis (see the section Developer Testing).

Other best practices are

• Test first.

• Refactor your code.

• Use patterns, architectural mechanisms, and other reusable assets.

• Keep your design simple.

• Pair programming.

Test First

The idea behind test first ^[5] is to write and implement the test cases first and then write the code. The code is written as simply as possible and then improved until the test case passes . The programmer selects a task, writes one or two very simple unit test cases that fail because the unit is not performing the task, and then modifies the program to make the tests pass. The programmer continually adds more test cases and makes them pass until the software does everything it is supposed to do. If you apply this best practice, you should consider combining it with refactoring, or you may end up with overly complex implementations . Test first works well with a use-case-driven approach, since use cases provide you with a good base for early identification of test cases. Kent Beck and others are also working on an approach called Test-First Design that describes how to integrate test first into your design process.

^[5] See Beck 2000.

Refactor Your Code and Design

Refactoring ^[6] is building a component or set of components by making numerous small and well-defined changes to improve their structure without modifying their functionality. The aim is to simplify and improve upon the existing solution to get higher quality and more maintainable code. After each small improvement, you need to run through your tests to ensure that nothing broke. This means that you need to combine refactoring with the test-first best practice. The combination of test first and refactoring has been successfully used in many projects.

^[6] See Newkirk 2001 and Fowler 1999.

Note that refactoring should not be used as a substitute for good design and architecture. There are limits to what refactoring can accomplish. It is also important to remember that "Perfection is the enemy of success." ^[7] There is a time when a component is sufficiently structured and further improvements will have a very low return on investment.

^[7] See Gilb 1988.

Use Patterns, Architectural Mechanisms, and Other Reusable Assets

The "not invented here" mentality is a major hurdle to overcome in becoming a good developer. Rather than submitting to this way of thinking, you should seek opportunities to reuse solutions that work. You need to be aware of the architectural mechanisms you are using within your projects, and which patterns are available from platform vendors and other sources. ^[8] Naturally, you can also use other sources such as project class libraries, as well as other available third-party components. Note that to reduce potential liabilities, some companies have clear restrictions in terms of which shareware components can be used.

^[8] See Gamma 1995.

Working closely with the architecture team and reviewing the Software Architecture Document should help you in maximizing reuse. If your company is producing reusable assets, you should consider documenting and packaging these assets using a standard called Reuse Asset Specification (RAS). This specification provides guidelines for how to structure and document the assets so they are easy to understand and use. RAS assets can automatically be understood and unpackaged by other tools, such as Rational XDE.

Keep Your Design Simple

The fundamental idea behind keeping the design simple is to only design for what is needed right now. The underlying assumption is that when you design for future capabilities, you do not have enough information to create the right design, and you typically end up with a more complex design than is warranted by the problem you are trying to solve.

On the other hand, if you create a design without considering future capabilities, you may end up with a nonoptimal design requiring major rework . You need to balance the benefit of making a simple design with the advantage of thinking one step ahead. The more experienced you are and the better you know what the future application looks like, the more you can think ahead. But be careful not to add unnecessary complexity, making your product overly intricate and difficult to maintain.

When designing, always make sure that you work with the architect to ensure that your design is consistent with the overall architecture. The architect may also be able to guide you in the appropriate level of simplicity for the design versus how much to design for future capabilities.

Pair Programming

Pair programming ^[9] is a practice of two developers working side-by-side to produce code while sharing one workstation. One developer drives the workstation while the other looks on, carefully watching the code being produced. The driver thinks tactically and is concerned with the code. The observer validates syntax and thinks strategically about the whole program. It is important that the roles are traded frequently.

^[9] See Martin 2001.

Many projects, and some preliminary research, reveal that code is written with fewer defects when using pair programming than when a single developer writes the code. ^[10] However, a fair amount of people dislike this best practice; they find that it slows down skilled programmers. As with all best practices, you need to figure out what fits your project, your culture, and the personality of your developers.

^[10] See Williams 2000.

The Developer Role in the Rational Unified Process

The RUP product provides a more fine-grained representation of the Developer role by describing more specialized roles. This chapter describes the responsibilities of the specialized roles listed here in italics. The roles of a Software Architect and Architecture Reviewer are described in Chapter 16, and the role of a Test Designer is described in Chapter 18. We do not describe the Capsule Designer in this book, since this role is applicable only for real-time systems.

• Capsule Designer

• Code Reviewer

• Database Designer

• Implementer

• Integrator

• Software Architect

• Architecture Reviewer

• Design Reviewer

• Designer

• Test Designer