Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I know a lot about programming syntactically. What I am unsure is about how should I go to build a software from scratch. How should be the objects be designed and how should they interact with each other.

To learn how good softwares are written I have tried to read code of some good open source softwares but could not get a slightes of idea, how they are designed as there is no availble documentation available regarding the code.

I want to become a more skilled programmer but I could not go any further, I am well versed in programming but now i am stuck as I have no way to go forward.

Please guide about how should I learn the software design and what should be next to improve the skills.

P.S : I am a hobbiest programmer, i have never worked in a software house neither am i looking forward to it.

share|improve this question

marked as duplicate by Robert Harvey, gnat, Martijn Pieters, Kilian Foth, Bart van Ingen Schenau Apr 9 '13 at 8:03

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
Look for "modularity" and "dependency injection". –  Jean-Philippe Leclerc Apr 8 '13 at 19:44
3  
Look for "Gang of Four" and/or software patterns and practices. –  Jon Raynor Apr 8 '13 at 20:09
3  
Just like any other skill: practice. Design (and write) little programs until the design is good, then get a little bigger; repeat. –  Telastyn Apr 8 '13 at 21:27
    
Search for Object Oriented Programming and look for Agile and Software Development –  Mushy Apr 8 '13 at 21:32
    
@Jean-PhilippeLeclerc It might be too soon for the OP to read about dependency injection. It would confuse him rather than help him at this time. –  marco-fiset Apr 8 '13 at 23:26
show 4 more comments

4 Answers

up vote 2 down vote accepted

Start building small "completable" projects from scratch using your existing knowledge on your own as side "projects" ..just make them up. Then refine / refactor the design by identifying and implementing Patterns / "good principles" you've learned from your reading / learning. Once the project has been completed and "refactored thuroughly", Do it again...

There are definitely some architectural "starting points" like keeping various "code layers" separate (DB access layer, Biz Logic layer, etc..). As well as trying to identify where "Interfaces" can be used so you can "extract" their "implementations" and begin introducing some kind of Dependency Injection framework... But that can be done during later passes of your "refactoring" efforts (if that's a path you even want to go down).

I would say there's no "silver bullet" or "this is how you do it" because projects vary so greatly. You can watch pod casts and read books, which all help becoming an export, but until you are able to implement what you've learned, there's still a pretty large gap, and the only way to implement what you've learned is to either do it and learn from your own mistakes, or find a good mentor who can teach you what they've learned from their mistakes..

"Just having the map doesn't get you to your destination"

share|improve this answer
add comment

You are basically asking how to design programs. It turns out there is a book which teaches you that, and it is called … How to Design Programs (aka HtDP). It teaches you, well, how to design programs. And it does this by giving you recipes to follow for how to analyze problems, solve them, transform them into algorithms and further into working programs.

Note that "recipe" is basically another word for "program", so in other words, the book teaches you programs for humans to run in their heads in order to generate programs to be executed by computers. How cool is that? :-)

The authors are currently working on a draft for a second edition of HtDP, which you might want to read instead of the first edition. The material about imperative programming has been removed, and is going to be covered in the as-of-yet unwritten second volume How to Design Components, but you can read those missing chapters from the first edition.

Note that HtDP assumes no programming knowledge and is targeted at high school students. But don't let that stop you: it just means that you'll probably be able to finish some early chapters faster, but I don't think you will be bored.

Concrete Abstractions is also a good read along similar veins. Like HtDP, it doesn't assume any programming knowledge.

Another book that you might hear mentioned is Structure and Interpretation of Computer Programs aka SICP. It is one of the greatest programming books ever written, and again, it doesn't assume any programming knowledge.

It is, however, geared to complete newbies who study at MIT. And so, while it does not assume any programming knowledge, it does assume quite a bit of domain knowledge, e.g. in the fields of electrical engineering, physics and math. Note: these have nothing to do with the concepts being taught, they are just needed to understand the exercises and examples. So, it might be better to read HtDP or Concrete Abstractions first, and then read SICP.

share|improve this answer
add comment

I would suggest a book by uncle bob: Agile Software Development, Principles, Patterns, and Practices. Also take a look at some of the clean coders videos. This is not quite architecture, but it sounds like the next step up from where you may be.

share|improve this answer
    
You're right; it's not quite architecture. –  Robert Harvey Apr 8 '13 at 20:45
add comment

Look up "Design Patterns". Here are a few links you could look at:

An introduction to design patterns: http://en.wikipedia.org/wiki/Design_Patterns A book on design patterns: http://www.amazon.com/Design-Patterns-Object-Oriented-Professional-Computing/dp/0201634988

share|improve this answer
3  
I'm not sure that simply stating "look at design patterns" is the way to go here. Many design patterns are viewed as workarounds for problems in OO languages that are not problems in, say, functional programming languages. Some design patterns, such as Model-View-Controller, are useful for specifically studying software architecture, but many are not; they are just building blocks for that architecture. –  Robert Harvey Apr 8 '13 at 20:44
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.