Revealing Design Flaws
Learn how to uncover design flaws early through test-driven development practices.
Good design
Bad design is truly bad. It is the root cause of software being hard to change and hard to work with. We can never quite be sure whether our changes are going to work because we can never really be sure what a bad design is really doing. Changing that kind of code is scary and often gets put off. Whole sections of code can be left to go to waste with only a /* Here be dragons! */ comment to show for it. The first major benefit of TDD is that it forces us to think about the design of a component. We do that before we think about how we implement it. By doing things in this order, we are far less likely to drift into a bad design by mistake.
Outside-in vs. inside-out
The way we consider the design first is to think about the public interfaces of a component.
We think about how that component will be used and how it will be called.
We have yet to consider how we will make any implementations actually work. This is outside-in thinking. We consider the usage of the code from outside callers before we consider any inside implementation. This is quite a different approach for many of us.
Typically, when we need code to do something, we start by writing the implementation.
After that, we will ripple out whatever is needed in method signatures, without a thought about the call site. This is inside-out thinking. It works, of course, but it often leads to complex calling code. It locks us into implementation details that just aren’t important. Outside-in thinking means we get to dream up the perfect component for its users. Then, we’ll begin the implementation to work with our desired code at the call site. Ultimately, this is far more important than the implementation. This is, of course, abstraction being used ...