One of the important things that are overlooked by developers while building applications is the folders' structure and names.
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? 🧙🏼♂️
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.
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.
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.
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.