This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!
This excerpt is copyright 2007, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.
Every day, our code is better than it was the day before.
Traditional approaches to design assume code shouldn’t change. Instead, new features and capabilities are supported by adding new code. A traditional design supports this by anticipating what might be needed and building in extensibility “hooks,” in the form of inheritance, dependency injection, and so forth, so code for those features can be added in the future. The Open-Closed Principle, a classic design guideline, illustrates this mindset: “Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”
- Simple Design
But Agile teams create simple designs that don’t anticipate the future. Their designs don’t have hooks. Instead, Agile teams have the ability to refactor their code and change its design. This creates the opportunity for an entirely different approach to design: one in which entities are not designed to be extended, but are designed to be modified instead.
I call this approach reflective design.
...to continue reading, buy the book!
In this Section
- Reflective Design
- How Reflective Design Works
- Reflective Design in Practice
- Reverse-Engineering the Design
- Identifying Improvements
- Code Smells
- Shotgun Surgery and Divergent Change
- Primitive Obsession and Data Clumps
- Data Class and Code Class
- Squashed Errors and Coddled Nulls
- Time Dependencies and Half-Baked Objects
- Incrementally Refactor
- Sidebar: A Reflective Design Étude
- Alternatives and Experiments
- Further Reading