"PHPkemon" <so***@mon.com> wrote in message
news:bf**********@news.surfnet.nl...
Hi there,
Does anyone know any good guide in how to get my ideas on paper or give me
some pointers in how to do that?
Help is greatly appreciated!
TIA!
To start, I don't know of any guide that will help you out. But, I can give
you some pointers that work for me and you can see what you like. To give
you some perspective, the planning phase is, by far, the most important (and
should be the most time consuming) part of 99% of all your programming
projects (there are exceptions). Writing 500 lines of code only takes a
couple hours. Developing a reliable, extensible relational database
structure may take days. Also, the techniques that most programmers use to
plan their project vary and are usually a product of years of work and/or
formal education. Producing a method that works for you will take time.
I would outline a typical PHP/web project like this:
1. Initial Design/Concept/Parameters/Capabilities/Features
-A lot of this is in your head. If you're doing this professionally, the
client should be the one giving you all of this information.
2. Formal Design
-This should be mostly on paper. If there's something in this project
that you're not sure how to do, this is where you blow the dust off the
manual. Knowing your technical capabilities is an absolute must at this
phase.
3. Technical Design
-Start putting together block diagrams of how your code should work. Put
some thought into how your site will interact with the user/browser.
-Decide on your user interface (if applicable) and stick with it.
-Design your database structure (if applicable). Make sure you're not
going to need to change anything in the future (so do it right). If you
think there might be some changes needed, anticipate them and code
accordingly.
-Remember the more time you spend here, you will at least earn it back
during the next phase if not a not more. The larger the scale of the
project, the more time you will save later. On a couple occasions, I would
say that I've earned a ten-fold return on my time just by spending more time
planning and less time coding.
4. Code
-Do it. I (and most other programmers) have two methods of coding:
top-down and bottom-up. The paradigms are opposite (obviously) and one will
usually be better than the other depending on the project. In top-down
programming, you start with the overall structure of your system and work
your way "down" into the specific features and sub-systems. (For web
development, I use top-down programming far more than bottom-up.) In
bottom-up programming, you start by developing sub-systems that will
eventually work together to form the whole project. This is a good method
if you're trying to "push the envelope" of the programming environment. If
you're not sure you can accomplish something technically challenging, this
is usually a better method.
5. Test/Debug/Recode
-This is the infinite loop inside of which you will be placed after getting
an initial code base developed. If you did your work early on, you should
only need a couple iterations through this phase (fixing syntax and spelling
errors are natural). If you're reworking program or database structure
during this phase, you will want to spend more time in the planning phases
next time.
6. Deployment
-This step can sometimes be trivial (especially if you're testing your
application on the production server). Other times, you will need to create
installation scripts and configuration front-ends to help a client
incorporate your application into their current system. This is usually
were I write the technical manual for the system. If you're doing a very
extensive system, context-sensitive help is also a very nice feature that
will have your customers coming back for more.
Some other pieces of advice:
-Keep in mind that the code you write will almost alwyas have to be
rewritten or modified in the future. If your program structure is poor,
this can be the most painful process of maintaining your program. Try to
always remember the axiom: KISS (Keep It Super Simple).
-With the last point in mind, you shouldn't strive for absolute perfection
when designing the structure of a program. The most ideal programming
structure is usually one of the slowest structures. You'll need to learn to
balance organization with execution effeciency (something we all work hard
at). For instance, don't write two functions that loop through the same
array just because it keeps your code more readable. Loop through the array
once and do both tasks at the same time. Also, HTML templates can sometimes
drag a high-performance content engine to its knees. Work on developing
techniques that allow your HTML to be more "aware" of the data structures
you are using. (IMHO there is no good way to completely abstract process
from presentation without tremendous overhead.)
-Read a lot of books. The more time you spend in the heads of other
programmers, the more will rub off on you. And who knows, maybe someday
you'll be writing one of those books for all of us. (Buy, borrow, or steal
every O'Reilly book they make that has anything to do with your programming
environments.)
-Develop a system of drawing flow charts of your program algorithms. There
are standard flow-charting methods, but who cares if you need to read a text
book just to read an algorithm you designed.
-Write a lot of "pseudocode." Write out algorithms in plain English at
first if it helps you understand what you're trying to accomplish: 1. Open
File; 2. Read Data from File; 3. Close File...
-Use visual methods for optimizing complex algorithms. Some algorithms seem
easy when you think about them in your head, but get to be very complex when
you try to write the code. Use things like drawings, flash cards, building
toys, puzzle pieces, and graphs to help you decide on what algorithm will be
the quickest. Yes, it's low-tech, but it's definitely helped me out a few
times (especially with recursive algorithms).
-Don't rely on other people's abilities to solve your problems. If you post
code to a newsgroup asking people to help you fix it, you should feel a
sense of obligation to the people that help. Instead, you should try to
seek out the resources that will help _you_ fix your problem. Newsgroups
are nice places to find this information. (Along those lines, learn how to
use the Google archives if you haven't already.)
Hopefully, this has given you some ideas and some direction in learning more
efficient ways to develop programs. What works for you will only come with
time and experience. Experiment with different methods (like doing a
project without any planning, then doing a project by planning way too
much).
Good Luck,
Zac
PS: If you haven't already, read the PHP manual--talk about a time saver!
