| Thinking in C++ Vol 2 - Practical Programming |
|
Prev |
Home |
Next |
Writing software is all about meeting requirements. Creating these
requirements is difficult, and they can change from day to day; you might
discover at a weekly project meeting that what you just spent the week doing is
not exactly what the users really want.
People cannot articulate software requirements without
sampling an evolving, working system. It s much better to specify a little,
design a little, code a little, and test a little. Then, after evaluating the
outcome, do it all over again. The ability to develop in such an iterative
fashion is one of the great advances of the object-oriented approach, but it
requires nimble programmers who can craft resilient code. Change is hard.
Another impetus for change comes from you, the programmer.
The craftsperson in you wants to continually improve the design of your code.
What maintenance programmer hasn t cursed the aging, flagship company product
as a convoluted, unmodifiable patchwork of spaghetti? Management s reluctance
to let you tamper with a functioning system robs code of the resilience it
needs to endure. If it s not broken, don t fix it eventually gives way to, We
can t fix it rewrite it. Change is necessary.
Fortunately, our industry is growing accustomed to the
discipline of refactoring, the art of internally restructuring code to
improve its design, without changing its behavior. Such
improvements include extracting a new function from another, or inversely,
combining member functions; replacing a member function with an object;
parameterizing a member function or class; and replacing conditionals with
polymorphism. Refactoring helps code evolve.
Whether the force for change comes from users or
programmers, changes today may break what worked yesterday. We need a way to
build code that withstands change and improves over time.
Extreme Programming (XP) is only one of
many practices that support a quick-on-your-feet motif. In this section we
explore what we think is the key to making flexible, incremental development
succeed: an easy-to-use automated unit test framework. (Note that testers,
software professionals who test others code for a living, are still indispensable.
Here, we are merely describing a way to help developers write better code.)
Developers write unit tests to gain the confidence to
say the two most important things that any developer can say:
1. I understand the requirements.
2. My code meets those requirements (to the best of my knowledge).
There is no better way to ensure that you know what the code
you re about to write should do than to write the unit tests first. This simple
exercise helps focus the mind on the task ahead and will likely lead to working
code faster than just jumping into coding. Or, to express it in XP terms:
Testing + programming is faster
than just programming.
Writing tests first also guards you against boundary
conditions that might break your code, so your code is more robust.
When your code passes all your tests, you know that if the
system isn t working, your code is probably not the problem. The statement All
my tests pass is a powerful argument.
| Thinking in C++ Vol 2 - Practical Programming |
|
Prev |
Home |
Next |
