Now, we are at a stage where we need to decide how our project structure will look. The project structure has a lot of importance, since it decides how the different components in our code will interact with each other and what point will mark the entry point of our application.

A well-structured project will not only help in providing a better navigation for the project, but will also help in providing increased coherency between different parts of the code.

So, let's take a look at how our code structure will look and understand the significance of what a particular directory or file stands for:

$ tree --dirsfirst
├── bugzot
│   ├── helpers
│   │   └── __init__.py
│   ├── models
│   │   └── __init__.py
│   ├── static
│   ├── templates
│   ├── views
│   │   └── __init__.py
│   ├── application.py
│   └── __init__.py
├── instance
├── tests
├── config.py
└── run.py

Now, we have an idea about how our code structure looks. Let's spend some time to understand the various parts of this structure and why are they even present.

Our project starts with the BugZot directory as entry point, which encapsulates our complete bug tracking project. Now, let's take a look at the directories and files that comprise the BugZot project directory:

• Helpers: The directory acts as a module for the project and provides classes and methods that act as a helper inside the project. For example, methods such as those which provide password salt generation, password hashing, and so on, can be grouped under the helpers directory.
• Models: The models directory contains the database models for a component to component basis. For example, the models for storing information related to the users, bugs, comments, and so on, are grouped under the models directory.
• Views: The views directory contains the code that is responsible for rendering a response to the user on a component to component basis. For example, the code responsible for rendering the home page of the BugZot application, a new bug file page, and so on, are the views that go under the views directory.
• Templates: The templates directory consists of the templates that are rendered by the views. For example, the template that is responsible for rendering the home page of the application, the template which is responsible for rendering the new bug page, and so on, are the ones that go under the templates directory.
• Static: There are a few files inside the application that don't change over the time. Their content, once defined, is served again and again without any kind of on-the-fly change by the server or the backend. For example, files such as CSS style sheets or JavaScript files are some examples that are defined once, and are served again and again. The static directory encapsulates these files.
• application.py: The file defines the point where we mark the initialization logic for the application and the application global objects that are shared across the application.

These are a few directories and files that are encapsulated under the BugZot project directory. But beyond these, we also have a few files and directories that lie at the same level as our bugzot project directory. Let's take a look at these directories and files:

• Instance: The instance directory contains the files and configuration that are local to a particular deployment of the application. This helps in keeping a global configuration of the application separate from the deployment-specific configuration, as well as allowing for keeping security sensitive content present under permission controlled directories.
• Tests: No matter what kind of application is involved, tests form an integral part of the application development process and allows for testing the individual parts of the code in the form of unit tests and the interaction between the different components of the code, through the use of integration tests. These tests come under the tests directory.
• config.py: The file defines the global configuration for the application that is required for the application to work and provides expected outputs. Any of the configuration that needs to deviate from the global configuration can be overridden in the instance-specific configuration files under the instance directory.
• run.py: The file defines the run point of the application and is responsible for encapsulating the code that is responsible for starting the application server.

With this, we now have a fair enough idea about how our project will be structured and what the role is of the individual directories and files that are present inside the project structure. Now, let's jump into the real fun and start developing the project.