One of the important things that are overlooked by developers while building applications is the folders' structure and names.
Where did it all go wrong? 😬
While learning a new framework, for example, We tend to keep using the structure that we learned during the tutorial in our production code.
How does this structure look mainly?
It describes what are the main building blocks of the framework, and not the application we were building in the tutorial.
What building blocks? 🧙🏼♂️
- Controllers
- Services
- Views
- Models
- DTO
Is it really this bad? 🤷🏽
Well, for the sake of understanding how the framework works, it's totally valid.
However, when we go on to build production systems with complex business requirements, this approach becomes impractical.
Why do it differently?
In big systems, while debugging or trying to understand how a piece of code works it would be helpful to view the folders as an open book that tells us:
- What does this system do.
- What are the components that build the system.
- What is the hierarchy the components follow.
Let's look at some examples 👴🏼
Here is one of the Standard naming conventions of a Spring Boot application.
It's like saying, I am building this thing, I will use those tools
On the other hand, we have a naming convention that describes the application
It's clear from this structure what's going on:
- Delivery has Request and Shipment components under it.
- We also have a Payment component.
it's like saying I am building a restaurant and this is the layout
Conclusion 👇🏼👇🏼
The folder structure of our application is very crucial to help us understand what is going on in the system and we should take care of making it as clear and descriptive as possible.
Top comments (4)
And there is a doc/ directory of course. Good to bring this forward. Code needs to be accessible to others. Remember, the original writer is this other after three months of not looking at the code.
Yes, a doc directory with some minimal important docs is also a good idea.
Eh, minimal? A lot is better I think.
Yeah, a lot could be placed somewhere else the codebase. You don't want your repository to get big in order to perform Git operations faster.