What is your way to design a program?

Question

I want to write a big program, and I need to split it into small functions, so I can start coding.

Is there are any good method to do this job?

for example:

I want to write a Get Things Done tool, use qt as GUI, work flow is like that:

• input the things need to be done(name and description)
• filter the things by tags(work,study,office,home)
• list things by priority
• do the thing on the top

I interested in the detail how you change the requirement and specification into a detailed design documentation. I found it is hard to found such example on web.(and there are plenty of code..)

I know there is a method:

• collect all noun in the requirement. make them into classes.
• collect all verb in the requiremtn. make them into methods.
• write the method implement description.
• check it, then code it.

Answer 1

Divide and conquer.

Answer 2

Here's how I do it for non-corporate work (I have to follow the corporate rules for their stuff, not my own).

It all has to do with levels. The top level is the requirements level. As you go down through the levels (e.g., logical architecture, physical architecture, high-level design, low-level design, module design, module development), the specification becomes more and more detailed.

In addition, the requirements from each level need to be clearly met by the deliverables of the next level down. An example: the requirement that you can get at your data from anywhere on the planet would translate to a net connection in the logical arcitecture, then into routers and such in the physical architecture, web services in the designs, a daemon program at module level and so on.

Traceability matrices allow you to ensure that all upper-level requirements are met by the lower levels.

Now there's a good chance you won't need the full range of levels for your tool but the principal still applies.

It's the same as with successful project managers - break tasks down into sub tasks until they're doable in a decent timeframe.

Answer 3

There's a book dedicated to this topic. Granted, it uses Scheme, but the concepts are broadly applicable.

Answer 4

In general, I believe in keeping things simple, and it's rare (although it does occur) that you need anything more than a good functional specification. I think you should have some of the following elements

• Some use cases of the problems the software is trying to solve. No less important, you should call out the problems the software is not trying to solve.

• A very basic ui oriented flow chart is sometimes useful. By ui oriented, I mean it should take the perspective of the user, not the program's internals.

• Some description of each of the screens, including the types of input accepted, and what is done with the input.

Functional specs are sufficient to begin coding from, in 9/10 cases. Joel wrote a multi-part article about this topic some time ago which you can read @ http://www.joelonsoftware.com/articles/fog0000000036.html

Answer 5

By being an instrument of evolution.

Answer 6

Quickly and for money.

But seriously...I take a very pragmatic approach:

1. Identify the goals for the program
2. Plan an initial data structure/layout
3. Think about how the user will interact with the program and what their goals will be
4. Begin to define the UI based on #3 above.
5. To the side, unit test any individual complex parts and being their encapsulation
6. User review the UI and design and begin code integration.

Answer 7

I once heard a saying something like "If your class is getting too big and too complex, then refactor it into a couple or a few smaller classes."

I would strongly suggest you take something along this approach until you are more experienced. This will allow you to really get a feel for when functionality needs to be broken up. If you try to over-engineer your project without any experience to guide you, then you are sure to make lots of missteps. I found that some people get so caught up in the principles and practices they start implementing designs that are very speculative. By speculative I mean that they might think "well later on we might want to add robust authentication", so they design everything to support that. The "additional anticipated future" features list quickly grows huge, and you will find yourself designing for all kinds of scenarios. You will run into problems like "how do I get this particular class to both be compatible with my future authentication service and my future monitoring service." You will bang your head against the wall trying to solve problems which are not even relevant to your first release.

If you take my advice though, it is important that after you get a prototype up in running, that you then take a serious look at your design. Now is the time that you can look at larger classes, and ask yourself if they make sense. One test is to imagine how easy it would be to explain the usage of the class to someone else. If it is complex or quirky, then a redesign may be in order. If they are too big and serving more than one purpose, then breaking it apart is probably appropriate.

The important thing to remember about design practices is that certain techniques should only be applied where appropriate. Don't try to force your application into a certain architecture or design if it doesn't fit well. You will learn these things with experience and time. The best thing you can do is practice. Don't spend too much time over thinking things, if you dice right in, you will find plenty of opportunities to reflect on your techniques. You obviously have the right mindset already of trying to do things the "right" way, which is good. Just don't over do it.

There are lots of "patterns and practices" out there.