Hi just getting my teeth into cakephp and I am enjoying how easy it is to use. Problem being I can't help thinking that I am not planning out my apps properly, could some one explain to me the whole process and software they use before they even start building with cakephp.
There are entire volumes, and an industry behind software design, development. I doubt anyone will fill you in with their entire process.
Google SDLC, UML, etc. Read books on design patterns, Code Complete, etc.
It's equal part an art as it is science, so everyone has a differrent opinion how the best way to build software is. Trial and error, learn from experience and osmosis. Visit forums often, ask lots of questions and perhaps most important, try and remain opened minded to being wrong.
I usually start with a high level, highly abstract design phase just to start to get my head around the scope of my requirements.
Another thing I like to do really early is home in on my I/O since these are the only parts of the application that are settled down. I will design out the database tables so that they can provide me with all the functionality I'm going to need. I believe that form follows function, so putting these pieces together helps to give some more "reality" to the design. Designing the database tables also gives you a stepping stone into the DAL code. This is also where you'll be planning any info you need to grab from XML files or web services and those designs will help formalize the mechanical code that handles communicating with those resources. Then take a look at the files / web pages / etc. that you're outputing. Those are very real, very tangible things that give you a great feel for what the rest of the application is going to need to accomplish in order to complete those outputs.
A few other notes: I try to follow the guidelines in Code Complete 2 by Steve McConnell who recommends starting at the top, identify components that make up the current level of abstraction and then repeat the process burrowing down into each of those components. Keep going until you reach the point where it's easier to code the next step than to design it. That said, I find it suicidal to design too much up front. In all ways that don't affect the rest of the team, I prefer to design a little, code a little, make sure everything is going as planned, then design a little, code a little, etc.
Thanks for pushing me in the right direction