|
|
|
|
|
Concepts suspended within one's mind though are fluid and constantly within a state of flux. Being able to concentrate upon a particular part of the code whilst maintaining it's interdependence within the gestalt reality of the rest of the application's code is akin to trying to see the forest through the trees. |
Usually when programming directly from our minds we only focus upon resolving the current problem and then move on to the next algorithm without considering other factors that may make our programming difficult much further into our development.
Once code has been written, laying the foundation and future direction of our algorithms, it becomes difficult to see any other alternatives to a particular algorithm or options to replace an algorithm; we end up forcing relationships between algorithms and objects under the illusion of saving time.
Often code written directly into an IDE without a prior design means wasted time and effort when you have to re-architect it to fit a subsequent algorithm's needs or when we have epiphanies of missing contingency planning within algorithms.
The only time I would recommend writing code directly from the top of one's head into an application is if what we are doing is experimenting in uncharted waters as an exercise of investigation into object usage or problem solving.
For the latter, a trial and error approach with slapdash error handling is quite acceptable, as the resulting application will be either refactored into a more elegant solution or discarded altogether.
Flowcharts help make substantial entities of the liquescent concepts in our minds' eyes.
We can focus much more intently upon any particular area of our application's design without having to sustain the rest of the design within the back of our minds, and we can step back to see the integrated picture clearly at any one time.
You will see any missing error handling or kinks in logic whilst mulling over an algorithm's process flow. As a personal example, I use a small flowcharting application called WizFlow to design my applications. On one particular application I had designed all of the class objects, the subsystems with their interdependent contracts with a fully normalized database design.
During the process of flowcharting my functions I changed the database schema three times, discarding some tables and reducing others to fields within another table. My database design was streamlined to cooperate with my application from my better understanding of the system which flowcharting had given me.
My conclusion was:
A flowchart approach results in a fully integrated system where all components are consonant with each other and designed to work seamlessly together.
Most coding difficulty is removed before coding has even begun. It is also much more expedient to change the design of an algorithm or application when represented within a flowchart, by moving a few symbols and adding or removing others, than continuously refactoring code.
Flowcharts also provide documentation of our design decisions before building our application. It is easier to write documentation when you have an overview of an application's purpose and how it performs it's functions.
This same documentation will help us with troubleshooting and making future decisions upon upgrades. Because we have graphically documented the application already we can use our flowcharts to mark off the various stages of our application's development as we build. I often mark off the various parts of a flowchart with a highlighter as I build each algorithm.
This is a thrifty process as all the guesswork over how an algorithm will operate has been removed by the flowcharting process. Using a flowchart to mark our current position in code is also useful when we have to drop our development work on one application and start work on another as flowcharts makes it is easier to work out where you left off and easier to conclude our coding at an appropriate juncture before moving our development focus to another project.
So in conclusion we should use flowcharts to design our application and it's code because:
---
About the Author:
Duane Hennessy Senior Software Engineer and Systems Architect. Bandicoot Software Tropical Queensland, Australia (ABN: 33 682 969 957) Your own personal library of code snippets. http://www.bandicootsoftware.com.au
Moderator of http://groups.yahoo.com/group/AccessDevelopers
---
Article presented to you by Candice Pardue, freelance writer and owner of Online Success for Internet Business. Go here to learn web design from start to finish. This one's for beginners...
http://www.webmastercourse.com/learn/web/design/from/home/
This article about using flowcharts for code design on a website may be reprinted for use as content at any website or in any publication as long as the article is kept intact with included links, text, etc.. and the resource at the conclusion of the article must remain with the article. The articles may not be sold for profit or included with a consumer product without written permission from the author. Thank you, and enjoy!
Learn How to Design a Website Here >>>>>>
Disclaimer: Even though
we have made every effort to provide solid and accurate
information with web design ideas on these pages, Online
Success for Internet Business accepts no responsibility or
does not insure or imply any degree of success in a web
based business or website design career by reading the
material listed on this website. Degrees of web or Internet
success varies greatly dependent upon the attitudes,
attributes and ambition of each individual designer. Please
thoroughly check out any information you find on this site
before indulging in a web design business or presenting
yourself as a webmaster. And, remember to use flowcharts
when you design code on your website.