What have you guys found to good approaches to developing web applications?
For example, do you start with the user interface and then begin adding function? Do you focus on a single resource and code everything around it before moving on to the next? Or do you go layer by layer, starting with the model/DB layer and building up?
I'm working alone.
"user stories" > prototype > design > coding > iteration1 > iteration2 > ... > release
Here is a good example of iterations:
Scroll down to "ASP.NET MVC Contact Manager Sample Application", it looks like:
You mentioned you are alone in your work.
The answer above by Koistya is good. However, I've found that by getting the UI in a showable state I keep the customer happier and get their buy-in pretty fast.
Personally, I always start by mindmapping everything. Then I create the structure of my models, then I put in logic for adding new data (whether this be an admin control panel, or front end stuff)
Then I write tests
Then I start on display logic, editing, etc etc, and any additional functionality needed
I tend to start with the database and work back up as doing the entity modelling for me tends to highlight issues.
From there I'll then create the baseline Webapp structure (which in Java means creating my project, adding Spring, configuring data sources and security and so on).
Once I have all the plumbing I'll then creating data access, controllers and views, typically creating one of each to get a proof of concept or just as amodel for junior developers to follow.
Webapps are iterative processes (more often than not) and I find it best to create a vertical slice as soon as possible.
I start with the model -> data access -> database schema -> UI
i do the same thing for each user story (and yes do test driven development)
When developing alone, do whatever works for you. Here are some other resources for you to look at while coming up with whatever works for you. Be advised that these other approaches assume a team.
I hope this helps.
I'm assuming you have some user stories, and requirements already. I like to create a rudimentary domain model (basically a class diagram), perhaps not having ALL of the fields that everything will contain, but enough to get a general idea of how everything is connected, inheritance hierarchies, and what everything is.
As for coding, I like to start with a single resource, and get some basic functionality built up around it. I don't generally hook it up to a DB at this point, I'm using a pretty simple DAO that stuffs things into a collection of domain objects.
Next, I add a handful of minor connected resources, and start building up the various links between them. At this point, I've got a few domain objects in place, but might not have built up all the fields and stuff they need. Just a few important fields that are enough to differentiate between instances of the objects and link a handful of them together.
At this point, I try to flesh out the domain objects I have with fields and behaviors, and add the required bits to the view(s) to make those features usable. Then, I get some sort of real usable persistence working, set up validation, and make the views pretty.
Refine what you've got, then iterate to cover the remainder of your model.
If you know what you want you can attack the problem from all angles, however, good design principles dictate that you have some sort of a spec first which outlines the features you want. Not only does it help you set your feature milestones, but this is a remarkably useful exercise in planning out your application.
Again, good design principle dictate that you design domain objects or business objects first. This is all the "nouns" in your application. Say you want to develop a website that shows the baseball statistics for major league players. The domain objects here are the nouns "players", "statistics", "baseball", "league" and so on. For each of these you create a domain model and a corresponding database table. Then you start thinking about the functionality you want to add to each for example Player.CareerSpan() or Player.GamesPlayer(int year).
Interface design can also happen in parallel and here too you should use mockups either on paper or using some tools (Balsamiq mockups is my favorite).
At some point it just comes down to personal management and avoiding backtracking. If you are undoing too much code, something is off. A source control system will help you realize this too.
Start with the user if you want an application that people like to use. Then work back to the database design that works with the user stories.
If you want an application that works like many we're familiar with, where the users are just there to perform database maintenance, start from the database. You'll probably finish faster, but your users won't be as happy with the result.