I've still only done a quick read through the article and will probably go back over a few more times to digest specific sections. The last part about the need for practice really resonates with me, which made me think about principles. When I practice, I always try to tie whatever I do back to key principles. When I'm practicing TDD and working on recognizing smells (potential violations of design principles), I keep principles like SOLID, KISS, DRY, and GRASP in mind. When designing at a higher level, I keep in mind things like decoupling, layering, and ports and adapters.
When practicing volatility-based decomposition, what are some of the key design principles that you use to guide your design choices? What are some "smells" that you watch for to avoid? Also, how much of a factor does being able to refactor your designs play in your process/method?
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
Of the various threads you posted today, this one is the most important.
In general, you don't want to just practice, because you may get it wrong and no know it.
To practice correctly, you should do these three things:
*Set specific goals
Don’t go all over the place. Focus on what you practice now. Avoid going down into the weeds of detailed design and technology.
Actively look for opportunities to concentrate, to improve, to further your learning.
*Obtaining immediate feedback
Is it working? Attack it. See how it handles change. View the guidelines from Chapter 3 on structure, and from Appendix C to see that you have not violated any of the directives and guidelines.
Share your work with like-minded peers and have them critic it.
*Concentrate on technique as much as outcome
Design all types of things, not just the current project, to become really good at volatility-based decomposition.
Learn to do it both efficiently (quickly) and effectively (correctly).