One of the mantras I've picked up is to figure out what changes in the program and separate it out. How you separate it out is where design patterns come in. I've discovered that design patterns help me plan much better and code much better. After all, it's all about managing change.
A few years ago I read an article about where UML was being used. It was mainly in the big companies. Smaller companies found it slowed them down when they needed to get their product to market quickly. This pretty much worked well during the internet boom since it was mainly a bunch of really good programmers trying to create a product that they would see to the end. In a corporate environment, there is always a mix of talent and there is no guarantee the whole group will be there for the product life cycle. Thus UML is practically a must for a corporate environment so that everything can be documented for the next person to pick up quickly.
If it's just you and maybe a couple of other people. The "old fashioned" way works very well. UML is great, but it will probably slow the process down for the sake of good documentation. If you can, go to your nearest paint store and pickup a can or two of chalkboard paint and make an entire wall (or two) of your apartment, house or work, a chalkboard. Wouldn't a 30ft x 8ft chalkboard be nice for diagrams?
For a really wicked thinking environment, get a few black lights, turn off the lights, crank the music and work in the dark. The chalk glows in black light, so you'll be able to see what you are doing.
On Mar 22, 2005, at 7:46 AM, Jay Blanchard wrote:
[snip] So my question has to do with planning a project (not necessarily a website in general, but a programming project specifically). I've got Visio 2003 and a pad of paper with a pencil. I'm pretty much willing to try out different methods although I prefer a visual approach. [/snip]
+1 for pencil & paper or whiteboard. And in the words of Obi Jay, "Use the flowchart Chris"
I know that there is lots of excitement about UML, especially in light
of PHP5's better implementation of OOP, but 25+ years of experience
tells me that basic flowcharting, before UML (which is not as complex as
some would like to make it), will save you several headaches down the
road.
Keep in mind that flowcharts are "living" docs....if you need to make a change to the code somewhere down the line you can (and should) change the flowchart to reflect it.
Another good thing about a flowchart is its ability to describe the big picture as well as the most intricate detail.
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
-- Brent Baisley Systems Architect Landover Associates, Inc. Search & Advisory Services for Advanced Technology Environments p: 212.759.6400/800.759.0577
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
