in reply to
Writing a web message board from scratch
The mission was to write a basic message board on the company web store where customers can login, leave public messages and answer other people's public messages.
Great, now what kind of data about the customers will you be gathering? How are you going to store it? Security?
After studying all the right O'Reilly books and learning which modules I need to use and how to use them - it occurs to me that I have no idea where to start on the actual project itself, even though I can see the final picture I want to create and how it fits together. It just feels too big to offer a starting point, if that makes sense?
What modules? You say you have a picture in your head, well the first step is to try and write it down as best you can, and when you do that, it will become even more clearly defined. You build you application around a a toolset: what is your toolset?
I could just start hacking away piece at a time, but it feels like I should be doing some kind of design first.
I don't want to fall into the trap of creating a hard-to-maintain disaster that so many others have. I want to be able to add features later easily. I want it to be reliable and the code to be "clean".
Now you're thinking. When you say HACK
it almost immediately implies lack of discipline/reliability/cleanliness. You recognize your needs (design) and that is a kickass step in the right direction, but you're wasting time, you should be writing things down already ;).
What are the first steps to planning the implementation of a largish project like this?
Setting down minimal criteria -- minimal functionality, and you've got it:
1) customers login, which means authentication and possibly state
2) they leave/answer public messages, which means you have to store/format these messages
3) there has to be a user interface, in which the users views/contributes to the forum
Now you've got the beginnings of a tree, expand each of the items into subitems and so on and so forth, and by the time you draw that picture, you've got yourself one heck of a map for a great plan.
How do you plan the code?
You set you goals, evaluate what skills you have (toolkit available ...), and you begin to scheme (like above)
Backend or frontend first?
There is no backend or frontend.
What exactly does that mean to you? First you decide what you want to do, then how it's going to work and what you need to make it work so (like what kind of database schema)
How do you decide what to factor out and what not to?
You should not have make this decision -- by the time you finish that tree, you should have a clear picture.
How do you write code in such a way that it is extensible? etc, etc.
Well modules, modules, similar functionality, modules ... modules
I guess what I'm asking is, what are the steps between seeing the design of version 1.0 of a web application like this in your mind and starting to writing the first line of perl itself. Or are there no steps in between for you guys, and you can just start coding at this point?
After the tree, which is a rough draft, you come up with a pretty good plan, which is draft 2, in which you begin to actually define your schema and your app flow, and then in draft 3 you refine both, and start making your app logic clearer. At this point you've not writtena single line of code. After draft 4, which is yet another revisement, you've got a clear picture of how to organize everything
and you go at it piece by piece, generating tests as you complete each piece, so when it's time to glue it all together, you'll have no doubts ...
So there you have it, asses, asses, asses, get a 2nd opinion, and asses, and tree, and plan, and revise, and revise and revise, and review, and get a 2nd opinion .... you get the picture. Keep your timetable in mind ... read web site design, or lack thereof for wisdom.
That's all I could muster up, enjoy (and I wouldn't even think of suggesting you adapt the everything2 engine)