This is meant to cover projects that tend to be larger in size.
I'm just trying to refine my coding without losing the instant satisfaction of hacking something together at the start and seeing it work.
In fact, the word "refactoring" feels a bit strange, because I was doing it for so long before there was a word for it. It's one of those terms (DSL, agile, etc) invented by mainstream programmers as they gradually reinvented Lisp hacking.
"Refactoring" is a particularly strange word. It's as if people were talking about "exhaling" as a distinct and even controversial practice. How can anyone breathe without exhaling? Yet articles and books would be written about it: "Should Breathers Exhale?" "When Is An Appropriate Time To Exhale?" "Exhaling: For And Against". People would ask their managers for approval to exhale and the managers would say no we can't afford it, and eventually they'd either just do it anyway on the sly or else turn blue and keel over.
As per the actual coding, I agree with pg on this. I divide the problem into "sub problems," often sketched out in pencil with flows for certain things (and maybe corresponding UI's, if it demands). I choose to start work on either the most important (central) process, or often the most interesting one (to get me warmed up and enthused about the problem). Once this is done, it's a matter of branching outwards from that process, and optionally filling in UI's corresponding to that process.
Along the way, refactors are inevitable, but most of the time I find I wouldn't have been able to predict them even if I'd initially spent a large amount of time doing conceptual models. I find the things that take the most time are the unexpected things, which I won't find out about until I'm coding it.
The one thing I enjoy most about having the process sketched out is the options it provides. For me, it's not so much the issue of coding that is the challenge, but giving every aspect of the project the attention it deserves, without getting too bogged down on devoting too much time to making one part really awesome. When I see all the work that needs to be done, and what's related to what, I realize the scale of the sub problem I'm working on may not be as profound as I'd like it to be.
C-x C-f :tabeUsually by creating an individual program that does each task. Then the job becomes considerably more tedious: putting everything together and making it work.
I solve new problems for the same project the same way. I create a solution as an individual program and then incorporate it into the larger system.
If I already have requirements, I rephrase them in my own writing.
Then I start sketching out some possible solutions in notes, as brief phrases. I may start writing code at this point, but I continue making notes occasionally.
if the app has a GUI then mockup the GUI first in some graphics program to see which kinds of things are useful to users, and then see what the minimum number of primitives is needed from the layers bellow to service that
Usually I can start with any step or point... I don't have to start from a specific point, so usually I start with the smallest one - the easier to code.
I keep a paper with me to write down any enhancements I want to add.