About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.
Send comments to:
keithray@mac.com
| For Agile Training, eLearning, or Coaching contact: |
| Industrial Logic, Inc. |
| 866-540-8336 (toll free) |
| 510-540-8336 (Berkeley, California) |
| Links |
| xpminifaq |
| Résumé |
| “Adopting XP” Article 2002 (pdf) |
| “ Refactoring” Article 2006 |
| AYE Conference |
| Lucien W. Dupont |
| Elisabeth Hendrickson |
| Johanna Rothman's Managing Product Development |
| Brian Marick's Exploration Through Example |
| Esther Derby's Insights You Can Use |
| Laurent Bossavit's Incipient(thoughts) |
| Dale Emery's Conversations with Dale |
| Martin Fowler's Bliki |
| Creating Passionate Users |
Archives
Subscribe
RSS Exploring Solution Spaces XML
2006.Sep.22 Fri
In large applications, just to be able find classes and functions, and to be able to comprehend the structure "in the large" (to see the forest and the trees), you want "layers". Or "modules". Or "packages". Some division of responsibilities larger than the individual classes. In the image below, I show a hypothetical ideal application with eight modules or layers, compared to a near-worst-case legacy application.
The order of the layers/modules in this diagram is arbitrary and not meant to imply the amount of connections between layers, nor the directions of those connection. (But keeping the connections between modules going one-way, even if that requires adding additional "interface" modules, is a Good Thing.)
When you are doing iterative/incremental development, as recommended by all agile methods, how do you keep to the ideal layering and avoid that legacy code scattering of responsibilities? By paying careful attention to the Single-Responsibility Principle and other principles of good design, and by cleaning up any the code smells that you notice which indicate violations of SRP and other good design principles. Decide on which layer a class belongs to, each time you create a class. (Create new layers as needed.) Each feature that you implement will likely involve several layers, so pay attention to where those layers are.
If you don't pay attention during agile development, your application structure could look like a Tetris game gone badly. Refactor every day to keep the structure clean and well-organized.