Software design/architecture problems [closed]

问题:

I code for a while now and learned several programming languages. I programmed a lot of little tools and such. I think I master the act of coding itself pretty good so I have e.g. no problems with syntax, I got a pretty good understanding of what is going on under the hood (reasonable assembler knowledge) and so on.

My big problem though is: I just can't design bigger/more complex applications. I learned the principles of OOP, design patterns, learned some basic lisp programming and all stuff I could find and thought it would help me with my issue.

But no matter what I try, how long I try: I just can't get it right. My designs always seem wrong to me somehow. Cause of that I never drawn through a bigger project, i'm kinda never satisfied with the structure of my program.

Have you had a similiar problem? How did you manage to solve it? Got you any hints for me on how to go on?

回答1:

I think experience is a key factor here. Every design fails at some point, then it's up to you to improve it and learn from your mistakes.

In my opinion good software design is not something you can learn by reading a few books.

回答2:

Design itself is an iterative activity. You first start with a certain design and then in phases you make it better.

Design is not about achiveing perfection, which can't even be achieved in larger application. Design is all about making good balances and tradeoffs that in the end provide a good, robust and maintainable application, that conforms to the requirements.

You will never get it 100% right on all sides.

Reading a few good books on design/architecture will not make you directly a rock star on the matter but it will certainly give you the tools that you can use to improve and perfect your skills.

Here are some examples of books:

• Code Complete: A Practical Handbook of Software Construction
• Head First Design Patterns
• Design Patterns: Elements of Reusable Object-Oriented Software
• Patterns of Enterprise Application Architecture
• Microsoft .NET: Architecting Applications for the Enterprise (PRO-Developer)
• The Art of Unit Testing: With Examples in .Net

Of course practical experience also counts.

回答3:

 design bigger/more complex applications

When you say design bigger/more complex applications, i assume what you have in mind is what are generally referred to as "Enterprise scale applications". You can check out this question which talks about various criteria that help to try and objectify as to what it is that makes an application an enterprise scale application.

Talking about these concerns,

1. Small applications might not necessarily have a lot of these concerns applicable to them.

2. Even with enterprise apps, with such a large set of concerns that need to be addressed, what differentiates the design is what concerns are given more importance. Also, in case of conflicting concerns, which one is chosen over the other.

When designing for your application, if you try and keep these concerns in mind and make design decisions based on these concerns, then that will be one way to try of moving in the right direction.HOWEVER, this is easier said than done. Though seemingly a simple looking list, getting a design right is something seasoned architects lose sleep / hair / life over and is usually NOTORIOUSLY difficult to get right especially for a beginner.

Some of these decisions are things learnt only from experience. In my personal experience, what greatly helped me was working with and under the supervision of experienced architects. To be able to learn and gaining the benefit of their knowledge and experience teaches you things no book / blog can.

But no matter what i try, how long i try: i just can't get it right. 
My designs always seem wrong to me somehow. 

Frankly speaking, you are totally the wrong person to judge. How do you really know that your design is wrong? The only real way to say design is wrong is if your application doesnt do what it was supposed to do.

If you want to have some validation of your design, then i suggest you ask someone who has worked on similar size projects which you have in mind and ask them to look at your design and review it - from their perspective. That, will really give you some good idea as to where your design is really at.

Cause of that i never drawn through a bigger project, i'm kinda never satisfied 
with the structure of my program.

Unfortunately, some of the real complexities in designing an enterpise application result from a variety of things that are just not possible to simulate otherwise. Some of them can be organizational constraints e.g. my client's CTO does not use allow the use of X technology ) to others like we need to integrate our application with that home grown MS Access app that one of our vendors is using. Such complications to the application and its design is something that you have to experience and there is usually a lot to be learned from it.

To get such experience, you have to work in such places which provide this kind of opportunity. Usually, what i have seen is that the bigger the company, the more complicated their IT environment is and that gives the most opportunity for complex scenarios to arise

回答4:

First look at Uncle Bob Martins principle each design pattern covers some of this principles, Take attention to The Open Closed Principle always we fail to do this, but by increasing of experience makes easier to do this.

I think trying to solve and then refactoring is good approach it helps too problem be more sensitive and have a solution and makes us free from stress to how to solve it.

回答5:

Try to take it step by step, don't try to design it all at once.

1. Define the requirements of your application.
2. Think about the objects you will need, try to make every object as simple as possible and specific, don't make huge objects with many different functinalities.
3. Think about the relations between your objects.

Trial and error will get you there. After a few projects you will have enough experience to get it right the first time (although for many project there is no "right" design).

Remember make your design as simple as possible, using a complicated design to solve a simple problem is not a good thing.

回答6:

To add some more calendar wisdom: "Don't repeat yourself" and "Keep dependencies to a minimum". Those two are often competing, though.