327
Part of preparing for construction is deciding which of the many available good
328
practices you’ll emphasize. Some projects use pair programming and test-first
329
development, while others use solo development and formal inspections. Either
330
technique can work well depending on specific circumstances of the project.
331
The following checklist summarizes the specific practices you should
332
consciously decide to include or exclude during construction. Details of the
333
practices are contained throughout the book.
334
Checklist: Major Construction Practices
335
Coding
336
Have you defined coding conventions for names, comments, and formatting?
337
Have you defined specific coding practices that are implied by the
338
architecture, such as how error conditions will be handled, how security will
339
be addressed, and so on?
340
Have you identified your location on the technology wave and adjusted your
341
approach to match? If necessary, have you identified how you will program
342
into the language rather than being limited by programming in it? 343
Teamwork
344
Have you defined an integration procedure, that is, have you defined the
345
specific steps a programmer must go through before checking code into the
346
master sources?
347
Will programmers program in pairs, or individually, or some combination of
348
the two?
349
Quality Assurance
350
Will programmers write test cases for their code before writing the code
351
itself?
352
Will programmers write unit tests for the their code regardless of whether
353
they write them first or last?
354
Will programmers step through their code in the debugger before they check
355
it in?
356
Will programmers integration-test their code before they check it in?
357
Will programmers review or inspect each others’ code?
358
CC2E.COM/ 0496
CROSS-REFERENCE For
more details on quality assurance, see Chapter 20, “The Software-Quality Landscape.”
Tools
359
Have you selected a revision control tool?
360
Have you selected a language and language version or compiler version?
361
Have you decided whether to allow use of non-standard language features?
362
Have you identified and acquired other tools you’ll be using—editor,
363
refactoring tool, debugger, test framework, syntax checker, and so on?
364 365
Key Points
366
● Every programming language has strengths and weaknesses. Be aware of the
367
specific strengths and weaknesses of the language you’re using.
368
● Establish programming conventions before you begin programming. It’s
369
nearly impossible to change code to match them later.
370
● More construction practices exist than you can use on any single project.
371
Consciously choose the practices that are best suited to your project.
372
● Your position on the technology wave determines what approaches will be
373
effective—or even possible. Identify where you are on the technology wave,
374
and adjust your plans and expectations accordingly.
375
CROSS-REFERENCE For
more details on tools, see Chapter 30, “Programming Tools.”
5
1Design in Construction
2 Contents 3 5.1 Design Challenges 45.2 Key Design Concepts
5
5.3 Design Building Blocks: Heuristics
6
5.4 Design Practices
7
5.5 Comments on Popular Methodologies
8
Related Topics
9
Software architecture: Section 3.5
10
Characteristics of high-quality classes: Chapter 6
11
Characteristics of high-quality routines: Chapter 7
12
Defensive programming: Chapter 8
13
Refactoring: Chapter 24
14
How program size affects construction: Chapter 27
15
SOME PEOPLE MIGHT ARGUE THAT design isn’t really a construction
16
activity, but on small projects, many activities are thought of as construction,
17
often including design. On some larger projects, a formal architecture might
18
address only the system-level issues and much design work might intentionally
19
be left for construction. On other large projects, the design might be intended to
20
be detailed enough for coding to be fairly mechanical, but design is rarely that
21
complete—the programmer usually designs part of the program, officially or
22
otherwise.
23
On small, informal projects, a lot of design is done while the programmer sits at
24
the keyboard. “Design” might be just writing a class interface in pseudocode
25
before writing the details. It might be drawing diagrams of a few class
26
relationships before coding them. It might be asking another programmer which
27
design pattern seems like a better choice. Regardless of how it’s done, small
28
CC2E.COM/ 0578
CROSS-REFERENCE For
details on the different levels of formality required on large and small projects, see Chapter 27, “How Program Size Affects Construction.”
projects benefit from careful design just as larger projects do, and recognizing
29
design as an explicit activity maximizes the benefit you will receive from it.
30
Design is a huge topic, so only a few aspects of it are considered in this chapter.
31
A large part of good class or routine design is determined by the system
32
architecture, so be sure that the architecture prerequisite discussed in Section 3.5
33
has been satisfied. Even more design work is done at the level of individual
34
classes and routines, described in Chapters 6 and 7.
35
If you’re already familiar with software design topics, you might want to read
36
the introduction in the next section, and hit the highlights in the sections about
37
design challenges in Section 5.1 and key heuristics in Section 5.3.
38
5.1 Design Challenges
39
The phrase “software design” means the conception, invention, or contrivance of
40
a scheme for turning a specification for a computer program into an operational
41
program. Design is the activity that links requirements to coding and debugging.
42
A good top-level design provides a structure that can safely contain multiple
43
lower level designs. Good design is useful on small projects and indispensable
44
on large projects.
45
Design is also marked by numerous challenges, which are outlined in this
46
section.
47