OK, this one’s a random thought. It’s about project structure. Or order of operations. Or something like that.
Anyway – how do you approach a new project? I always tend to work the same way: start with the data.
What kind of data will you need to use? How do you need to handle it?
That tends to drive my development in a specific direction:
- Set up a place to store the data.
- Build the structures to store the data.
- Build the methods you need to access / update / handle the data.
- Make sure the data can move the way you want. You know, teach it how to Dougie.
- Last, package it up in some kind of interface. Bonus points for good UX.
Is it effective? Heck yeah. Does it mean that you might go a long time without much to visually demonstrate on a project? Also yes.
Like, you can show off backend unit tests, or test your API routes in Postman or whatever, but it’s not exciting. “Ooh, look, I got back some text data in curly braces!”
So this Jam Session capstone project is interesting, because my team works the other way around. Put together the UI first so there’s something to show off, and worry about the data later.
I get it, and it’s a valid way to work. There’s just a part of me that hates touching code more than once. Like, get it done and send it off into the world. So if you start with the backend, you can have that DONE and just… never touch it again while you iron out the front end, secure in the knowledge that the backend server is just humming along.
But if you start with the frontend, it will never be done. You’ll have to keep going back to it and revising it as you add layers to the data handling and routes, pulling out all your mocked-up components and replacing them with the real thing. So you wind up working on the frontend, but then you keep working on the frontend while you also need to work on the backend logic.
Anyway, just some ramblings for today.