user396089 is more than competent when it comes to writing code in "bits and pieces." Planning and synthesizing that code into a complex, coherent app is the hard part. "So, my question is, how do I improve my design skills," he asks. And to that, some more experienced programmers answered...
See the original question here.
Be a bad designer for a bit
Amadeus Hein Answers (8 votes):
Well, there's no golden apple for this kind of question, and I feel perhaps this is for every coder himself to find what's right for him. Here's my take, anyway.
You could read books on the subject. Great books. Fantastic books. But I find that these books only help you once you've tried to build and design an application—and failed.
For me, it's all about experience. When I started as a rookie I read books on how to design. I didn't understand much of the content back then. When I started working and had to design applications myself, I made very messy applications. They worked, but they were a pain to maintain. Then I read those books again—and this time I better understood them.
Now, I continue making new mistakes and learning from the old ones.
Related: "What to plan before starting development on a project?"
Stick to some basic rules
Konrad Morawski Answers (4 votes):
Read about patterns, sure, but first and foremost read about anti-patterns. Recognizing anti-patterns is important, and it's easier to understand why something shouldn't be done in such a way than why it should.
See SourceMaking's post on anti-patterns, for example.
Write code so that it can be adjusted quickly if requirements changed (which is very common in production environment).
Be super-skeptical about adding "just one more little hack." One more here, one more there, and the code becomes unmaintanable.
Value the open/closed principle.
Write tests (as in TDD). They force you to think your design through even before you actually implement it.
Browse the code of open source projects (reasonably sized ones, that is). I used to be surprised at—usually—seeing so many levels of abstraction. Now I understand it's not art for art's sake, there's a reason why it's done this way.
Decompose it
One principle that I find very important for good design is decomposition:
- If a class is too big (more than, say, 300-400 lines of code) break it up into smaller classes.
- If a method is too big (say, more than 50 lines of code) decompose it; if a project contains more than 50 classes, decompose it.
The key is to estimate the size of your system and construct several abstraction layers (e.g. subsystem, application, project, module, class, method) that allow you to decompose your code into understandable units with clear relationships between them and few dependencies.
Forget about design
kevin cline Answers (2 votes):
Stop designing and learn to refactor code. Incremental development with continuous and aggressive refactoring will result in a much cleaner end product than any up-front design.
Find more answers or leave your own at the original post. See more Q&As like this at Programmers, a site for conceptual programming questions at Stack Exchange. And of course, feel free to login and ask your own.
reader comments
40