Best way to plan a task ?

Question

Hi All,

As I am very new to programming, I am very curious about learning the best ways/practices of programming.

Whenever I want to write any program, I start directly with coding while some guys say that you should plan your program first before starting the code.

But I don't understand the real value of creating the class diagrams and all that kind of stuff coz I think that ultimately I have to write the code.

Can you guys please share your experiences about how you are doing your programming? I mean what is your first step when you start an application?

Answer 1

I'm a fan of CRC Cards.

CRC stands for Class, Responsibility, Collaboration. You use a set of postcards, where each card represents one class, and lists what it is responsible for, and how it collaborates with other classes.

Given a list of features, and/or a set of Use Cases, CRC cards make it easy to "act out" the various functions of the software, ensuring that classes exist to perform the actions needed, and that the relationships between those classes exist to allow them to work together properly.

Answer 2

I'm using something like "reallife" CRC Cards - I just take a few pieces of paper and a pen and start sketching the classes and their methods and all their dependences. The other papers are used for a more detailed info about the functionality.

Answer 3

If you're new to programming, then start with the basics: Learning to program. Write some small "hello world" programs and expand your knowledge to websites or windows applications. Learn to write programs that meet your requirements. If you don't have any requirements, write them down before you start, otherwise your program will have no finishing line.

When you feel ready to take on bigger projects, you can take on class and object design using UML and learn test-driven development to write more solid code. Learn more about the different development methologies, like Agile and Scrum. Bigger projects require planning and good designs, so you must know your theories.

Answer 4

Sometimes a large task is daunting which can even make "just code it" without planning impossible, as you just don't know where to start. I remember years ago I used to get stuck for ages trying to work on something new, because I had been raised in position where my main job was to make enhancements - I had no experience of working with a blank canvas. It was paralysing, unable to commit to an approach because it might be a sub-optimal design choice.

But anyway, these days I tend to sit down with paper and iterate through the design.

If it's big, I'll just start sketching out how parts of it will work separately, and eventually these pieces join together. I try turning it into classes or modules and then I'll discover that there's redundancies in the design, or there's something there that just doesn't work. So I start again, write it down with a better approach... and find out more problems. I keep iterating, gaining a better understanding of the problem on every sweep. (Whiteboards can be good for getting you up and about, being physical while sorting out thorny issues.)

When I have a psuedocode/flowchart design that's fairly detailed which has no obvious problems - that's when I start coding. In a formal environment, the final design sketch is what I would turn into a specification and distribute to users/developers for review.

Often, with a complicated design, I will transform this design sketch into comments to guide me as I code, which is faster and more accurate than having to consult my notes every 2 seconds:

// open file
// read header line
// check header is right (watch for int problem)
// select right config object
// loop over lines, read each line into config object

And I convert each comment into code.

This is a lot more efficient than coding yourself into a cul-de-sac and having to write and rewrite simply because you didn't have a handle on the problem from the beginning. This doesn't mean the design won't change any more - you'll still find problems - but some major design bugs can be thrashed out before you hit the IDE.

There are many approaches to design, this is just what works for me. What's best can vary on the type of project and size of the team.

Answer 5

Don't be stuck on class diagrams etc, the main purpose for taking some time to think about what you want to do is to be able to organize your application in a robust product. When you sit down and think beforehand like doing some use cases over what your program should do you effectively looking from another angle so you may find things that are not so obvious. A matter of abstraction

If you start coding directly you often end up caught up in the details of the implementation and may forget about the goal creating a very narrow and fragile solution.

A bit like you chop your way through the jungle from A to B and exhausted throw yourself on the ground when you get there, you have then created a path from A to B but what you really wanted was a well laid highway from A to B.

Answer 6

Two points with planning and preparation are:

• To make sure that you and the customer share the same view of the problem.
• To expose potential issues with your idea on how to solve the problem.

How you do it depends on the situation, but the point is to accomplish the two points above as cheaply as possible. Draw sketches, discuss, make a low-fi prototype, create a pilot system.

Answer 7

when you are starting out to code no design planning is really going to help you. you just dont have the reference knowledge you get from experience. you only appreciate design when you start coding and getting it wrong, you need to fail forward.

thus write small bits of code and review frequently with more experienced buddies.

Answer 8

If you want to write a good program, especially one you might want to change and improve later on, then it will be worth your while doing some design before diving into writing code.

"Creating the class diagrams and all that kind of stuff" is really just a way of writing down on paper what you're already thinking about: what classes you need, what data they will store and how the classes relate to each other. You don't have to follow any formal process -- I find crude boxes and arrows work just fine for getting my thoughts organised.

As I spend more time with a program, I generally find that I spot some better ways of organising the data, or improved relationships between classes. When this happens, the crucial point is that it is much easier and quicker to scribble out and redraw a few boxes than it is to throw away a 200-line file written in carefully-debugged C++ and start again.