What do you do before you start programming? [closed]

Question

I'm not sure this question belongs here, it's not so much I problem I'm having with programming but rather a problem of what to do before I start programming.

I want a visual representation of what variables I need and what classes have what methods.I know there is UML but I'm not sure if that is the best way, so what do you guys use before you start programming, which method?

I don't want to start a flamewar about what is better just what are several approaches?

Answer 1

Whiteboard. If I can explain what I want to do (and why) to a colleague on a whiteboard, I usually end up with a cleaner solution as well, and sometimes end-up copying the key parts of the whiteboard into my notebook as an improvement to whatever was written there already.

Answer 2

I usually start with a redbull. Then I go over ideas on the drive into work. Sometimes I ignore my wife because my mind is still thinking about it later, over dinner. Maybe scribble out some design notes. Then I prototype quickly and show to some colleagues.

Answer 3

Personally, I find most graphical representations of code to be unnecessary. Whenever possible, I start with a unit test. Then I write code to make the test pass. Then I write another unit test...

It sounds like you're trying to make it right, then make it work. I would turn that around and instead of planning in terms of variables, classes, and methods, I would focus on the desired result, achieve that result, and then make sure the code is "right" by whatever standards you, your project, or your employer hold dear.

Answer 4

I usually start with a trip to the kitchen to get a drink :)

Answer 5

1. Think.
2. Write a very raw prototype.
3. Think again.
4. Write proper code.
5. Explain it to someone else.
6. If I felt stupid during step 5, rewrite it.

This is of course for smaller pieces of functionality. Bigger ones need to be broken down first, which I tend to do in my head first then write a nice document out of it.

Answer 6

I'm a minimalist and I don't use UML or anything of the like, so I'd probably just sit down with a sheet of paper for each class and write out the necessary fields and methods. If there was inheritance involved, I'd arrange the papers in a hierarchy according to their inheritance. If you're looking for something more visual, try using different colors for fields and methods or different shapes for different storage classes and levels of access (e.g. if you're using Java or C++ underline static stuff, put a circle around public stuff). You can also draw lines or arrows between fields and methods to indicate their relationships to each other.

When all that's done, you can put the inheritance diagram up on the wall and pull down each class's paper as you work on it. I'm not sure if that's a formal technique or if there's a standard way to do such things, but that's my $.02.

Answer 7

I usually start by creating interfaces and classes without implementing them yet. Depends on the language, but I find it useful if you can throw not implemented exceptions all over the place. Then, once you have the whole thing written down with valid syntax and structure that compiles, you can start implementing features one at a time. This way you get some help by the compiler about what is wrong with the code, what you should do next, etc. Beats writing things on paper most of the time, cause you get more feedback in the process.

Answer 8

I agree with hotpaw2, and often start out at the whiteboard. Specifically, I tend to draw lots of boxes, arrows and lines, interspersed with some acronyms and the occasional key word. This is not meant to make a detailed design, or even necessarily to describe my ideas to a colleague, but to get an idea of what action flows are relevant, and what pieces of information are needed at each step, at a more detailed level than the specification from the stakeholder. Many times, this involves several rounds of erasing and drawing, and sometimes going it over with a colleague, but towards the end I have an idea of what the finished code actually needs to do.

Given this, it's usually pretty clear what data structures are useful. So I need a few bits of configuration data from somewhere (anywhere)? That's a Configuration class holding those right there, and maybe a ConfigurationProvider or similar to populate it. Corresponding interfaces to aid testing, even if I don't have the time to write unit tests up front. Customer details? It's the same thing. Once I am mostly happy with how it has all turned out in theory, I might copy it to more permanent storage, usually in UML or a UML-esque notation in my notebook (if it is only for my own benefit, no need to get too elaborate - at my current job, class diagrams are rarely called for, but action and component diagrams are very useful). For a project I am working on now, one major part of the design took shape on the whiteboard long before I started implementing it, based on a rather vague statement of intent in the specification.

Only once I have the data structures and action flows down do I start thinking in terms of the concrete implementation: methods, entry points, specific data flows, and so on. Usually it's not before then that I even open up an IDE.

Answer 9

I prefer having time (a day or more) to think about a problem before I start working on a solution, creative ideas need time. I tend to just do this in thought without much externalization, although I sometimes make some lists of entities, use scenarios and data elements.

Having a conversation or brainstorm with a fellow programmer can be very valuable. Other then that I tend to design and discover while I code.

Answer 10

Before I start the implementation, I write a test. If I don't know enough to write a test, then I go talk to the customer. Usually the first test provides no input, and merely checks to ensure that no output is produced, or that the expected error is emitted. After defining the test, I then create the minimal software to pass the test, including the build and installation scripts. Then I write another test.