How to document a system flow before coding it? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

We don’t all开发者_高级运维ow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.

Closed 5 years ago.

Improve this question

Can anybody help me with this?

Here's the problem...

When I have to code let's say, a registration form, I add the new form and start coding it. But sometimes the form is a bit complex and I find myself duplicating code and making the same verifications over and over again making the code messy.

I was wondering is there is some sort of tool that allows me to create a flow of this form before coding it, like a flow chart... where I can find such places where I'm duplicating code and then avoid that.

thanks!

---

Well real tool/language designed for this is UML. You can read up on it.

But its very strict. Altough you don't have to follow all specs and conventions. There are several types of diagram that cover pretty much everything. But AFAIK only 4 are practically in use.

Most people I know tend to draw Control flow diagrams

Google Docs drawing is perfectly fine for that.

But it depends on the type of application. I pesonally think more in data and like data flow diagrams.

I also like to design top-down. Other people do it differently. I mostly start with a sheet of paper and a pen and draw some stuff i could not tell what it means half an hour later. But I start very basic with application/database/user or something and when a picture arises i go into specifics using modeling tools.

I cannot design anything without knowing the greater picture, altough i know it is a software developers quality to just that.

ps: designing a form sounds very trivial at first, altough it might be not. but a great help

I think a great help is sticking to some programming patterns and paradigms you like. A good base is the MVC concept. I like to extend it with a "resource model" that does all the database stuff.

---

1) The best place to start is the white board. If your company doesn't have white boards, tell them to order some. Seriously. You will wonder how you lived without it.

2) Build a paper prototype with the stakeholders, or have them build one. They take maybe 30 minutes to make and solve a ton of UI arguments that otherwise would be "defects"

3) Code. That's the easy part.

4) Refactor as you fix defects. You'll notice better things you could have done, shortcuts, duplicate code. Take time to fix the defect correctly and code quality will improve. It's an iterative process.

5) Visio if you hand the process off (to support or whatever). This could be step 4 as kind of a state machine, but the paper prototypes should be enough of a process to get you started with enabling, disabling, etc.

If you're on the computer designing and writing code before you have a prototype and have white boarded everything out, you will have to invest a lot more time in the Refactor step. Visio and other state design applications will show you what happens, but the white board marker is the excalibur of the development world.

I know this doesn't answer the question you asked, verbatim; however, solid processes are infinitely more valuable than tools.