I gotta admit, when it came to structuring a frontend project, I didn't really know why people considered it that important. I've mostly been working on smaller projects either alone or with 2-3 people. The projects' structure didn't matter all that much because they were abandoned as soon as we were finished with the project. With this kind of experience you might get lulled into the feeling that the default setup is all that you need.
I realized there's a lot more than meets the eye when I started working on an existing project that was a couple of years old. Just imagine being plopped in a foreign structure where you have to think about every little detail and question yourself constantly!
I started thinking a lot more about where I'd place a function, partial or a simple object. By just spending some time thinking about what would be the most logical solution, I've (hopefully) improved mine and everyone else's developer experience.
The catch is that I still have a lot to learn. I'm sure there's some things I haven't even considered because they're manageable at the time. But I don't see that as a bad thing, since that's something that could probably be improved. That's why I think it's important that you review how you structure your projects once in a while.
In this article, I'll explain why we've had the idea for a standard project structure within our team. My experience is related to frontend, but you might find something interesting even if you work in something else! But if you're in need of an actual structure, I'll be showing that in some other post.
How can you condense complex project structures into a single template?
Our projects' structure can vary a lot depending on the length of the project, the complexity, the features, and a number of other factors. However, I think we can make a generic structure which would work great in most cases. Now you're probably thinking, what about existing projects? It might be really complex (and inefficient) to change the whole structure in an existing project, but who says that you have to change absolutely everything? If you're going to work on a project for some time, why not make it easier for yourself if it's possible? After all, you've probably gathered a lot of knowledge throughout the years and could surely improve on the parts you designed at the beginning of the project.
Tackling this problem might not even be as complicated as you might think. Just writing down and explaining each folder/file will give you insight about your current situation.
From there you can easily see whether the decisions you made make sense! When I did this, it really felt like a game of Sudoku. When it seems like there's nothing else that can be done, you stumble upon a couple of smaller things here and there and, suddenly, a huge playing field opens up. That's my method for handling larger and older projects that are in time for a tune up.
Many projects, even more factors, but not enough resources
I work in an agency, but we work on projects of varying lengths. Some are done in a month's time and some are worked on for years. We're not limited to one technology, so that's also another factor. That's just a couple of things, but our structures can be wildly different. This means that each time you switch projects you have to get used to a different structure, as well. By not having a defined standard within the team, it meant that new projects would succumb to the same fate. That's more cognitive load that you don't want to have.
To counter that, we've researched which structure would fit us the best. Most of our focus was on scalability, readability, and extendibility. That's a lot of -bilitys, but in simpler terms we wanted to make sure that the project structure we made is easy to understand, use and improve. Sounds really simple, but to find something concrete on the Internet proved to be somewhat of a tough task. We were defining this structure for our frontend projects where the technologies are relatively young. Therefore, there's a lot of resources that show their ideas on really small examples with little experience in larger projects. It also doesn't help that only some use actual architectural patterns that are commonly used in software development.
We did manage to find some resources that really helped us out:
- Contemporary Front-end Architectures by Harshal Patil
- Infinum Frontend Handbook
- How to structure frontend application by Michal Zalecki
- Folders-by-feature structure
- Container component
There's a lot to learn from each resource, but we didn't use every single thing from them. Each part was discussed and made sure that it really worked for us. It helped that we could decide as a team because each of us had some experience in something the others didn't, so it's important not to dismiss anyone's opinion.
After defining a structure, there's two last steps that were incredibly important and made everything click:
- Explain each segment so that someone with less experience can understand it with relative ease
- Just by using your explanation from the last step, create a smaller app to test out your structure
These steps were vital to adding most of the finishing touches. If we hadn't done them, we would have shot our own leg when we started a new project. It makes sense testing out what you did, but it is tempting to skip this part since you've already done the majority of the work. It will also help you to objectively look at the work you've done. Don't forget that everything can be improved!
Final words
Following this plan we came up with a concise CRA template (and Vue template) with a detailed README. Now we're able to preserve the same project structure throughout multiple projects and relieve ourselves of the cognitive load when switching to other projects.
This does not mean that our work is over, but it should be less of a hassle to have a great foundation and improve everything from here.
And if that doesn't sound great, I don't know what does!
Top comments (1)
good stuff!