views:

113

answers:

1

Hello,

I don't know if I am only like this or maybe some people has same problem. Always when I get a project I don't know how to design it well. I mean I just try to make UML design, but always it doesn't show the final result. In the end project has so many changes which aren't in the design, so my drawn UML gets useless to people who gonna use it.

Imo it does so because I get stuck on many obstacles which I haven't predicted in the design. Also all this leads to unreadable/unmaintainable code for people who gonna use it, because after I get unpredicted situation I start writing code step-by-step(instant solutions), so the inner code and mostly functions aren't structured well. In example in the beginning of the function I define some variables, after that I call/do stuff and after that I am doing it again in the same function. So the design and readability isn't friendly at all. I can refactor it in the end, but the time of the project always ends, so I need to release it and code is shitty there.

What could you suggest me? Read more literature related to design patterns? Investigate more on framework/libraries I am working on? Or everything will come in time? Thanks for all help!

P.S. - This is my first job. And I only have 6 months of experience. I want so much to get better so my designs which I make at the start of the project would be more precise and with less obstacles.

+7  A: 

You need to practice for some time to learn how to do things right. The fact that you are questioning your work is already a good sign.

You have likely heard of agile development. Basically, it's about the fact the people long ago understood that an attempt to design everything in the beginning and then go implementing it (waterfall model) does not work in practice. You will end up with what you have, either the end system does not meet the customer's needs or after a number of fixes along the path it got messy. That's where agile comes in.

  • Design and develop in iterations. Don't try to think of all little things before and cover all options. Just drop it. Think of what you would like to have for the first iteration then design and code for it.

  • After each iteration you look at what you have, show it your manager, your customers, based on feedback adjust your strategy

  • Forget about UML. Just have some sketches of what you are going to do. You may draw detailed diagrams for future supporters afterward, if they are really needed.

  • Try to avoid immediate hacks wherever possible. Keep things as clear as you can. If something smells, redesign it. Hacks tend to accumulate to result in unmaintainable code. Don't follow that way.

  • "In example in the beginning of the function I define some variables" - if that's what they they taught you in college, forget that immediately. Declare variables where they are needed for the first time and keep their visibility scope the shortest possible. if you need a variable only inside a condition branch and nowhere outside, then declare it inside.

  • Read books on software design and investigate the source code of good projects. Just pick up small ones for the start, not to get overwhelmed.

  • Learn from your colleagues and people online

  • If you're always running out of time, then it's either you work speed is not enough or the time assignment is being done wrong. I do not know exactly your situation, but if there are time problems that you are sure are not your fault, speak up to the management. Explain that these restrictions only lead to low quality work. Maybe you can reach an agreement there.

  • Practice, practice, practice. After some time it will come to you.

Developer Art
I disagree with the advice to throw out UML. UML class diagrams are valuable as tools for designing object models. I do agree they should be used for sketching on blackboards/whiteboard/paper, at a stage where you're contemplating how to break up the design into classes and interfaces, and where the dependencies between them should run. They're useful for the big picture, not so much for details (which are much easier to grasp from code).
reinierpost
@reinierpost: I was expecting comments on UML. Yes, they can be useful, for sure, but people often tend to dive into UMLing with all its decorations and complexities which leads to real complex painting. That's why I suggest to only do some sketches, either in UML or anything else, not to get lost in details.
Developer Art