Comment by buckbova
12 years ago
This shouldn't replace understanding the problem domain and carefully planning before tackling a moderate to large scale project. Yes, one shouldn't tune each individual piece with unjustified optimization but the high level design should be thoughtfully laid out prior to hammering out large swaths of code.
Too many developers plow forward in a brute force manner creating unmanageable inconsistent messes and use rules like these to justify their lousy (lack of) design choices.
My rules:
1. Understand the problem domain.
2. Design flexible solution using common patterns.
3. Stub out skeleton of system encompassing majority of specs.
4. Revisit design and consider all conceivable exceptions and outlier and tweak design as necessary.
5. Review above work with others and tweak design further as necessary.
6. Coding.
> Design flexible solution using common patterns.
Maybe this is part of the problem. I'm relatively young, so I've only seen a few design patterns, but it'd be interesting to have a high-level look at some of the most common patterns and what they're good at and what they aren't. For instance, I've never really used a messaging queue, but it seems like a genius design for a particular type of problem. I wonder how many other designs are out there that I'm not using, instead opting to shoe-horn in my existing ways of thinking.
Just in case, here's the 'Gang of Four' book on design patterns: http://www.amazon.com/Design-Patterns-Elements-Reusable-Obje...