# ProjectTemplates

[This repository](https://projects.aniondev.de/PublicProjects/Common/ProjectTemplates) contains proposals for structuring sourcecode-repositories managed using [git](https://git-scm.com/).

## Background

Software-development is a big subject with many aspects and many things to consider.
There are also many things grown historically in a very unstructured way.
In the technical implementation of projects we software-developer do many things because of at least one of the following reasons:

- Coding-style- and project-guidelines defined by the company
- Things are grown historically
- One does not know a good project-structure for the specific project
- One does generally not care about a good project-structure
- Competing approaches for that issues will be used parallelly

So nearly every project has a different structure.
So every build-pipeline looks very different and has its own properties.

And this is probably not a good situation.

When you look into a project's source-code the first time you do not want to search for everything.
It is much better when you look into the project and think:
"When I want to compile the project, I know how I can do this.
And when I want to run the unit-tests, I also know how I can do this."
The _non-functional_ things of a project can/should be consistent which helps when new developer familiarize themselves with the project.

Example:

It is like start to work for a new company and you go to the office-building the first time and you know:
Here is the reception, there are the office-rooms and over there is the canteen, because that is how it is in nearly every building.
If you can orientate yourself on one building, you can also do so on all the others that are constructed in exactly the same way.
It does not mean that the people do all the same work in all these buildings, but it is much easier to find your way around.

In reality, there are rarely 2 exactly the same office buildings.
But applying this principle in source-code-repositories is absolutely possible and useful!

IT-related examples:

When managing applications for example there is something like a de-facto-standard today:
Docker/Kubernetes.
You do not really care about the internal structure of the application-container.
This internals do not matter (at least for everyday-usage/-issues) because you can manage the containers using the same program with the same interface.
When you want to run an application on your server there is a _requirement_ that the application is runnable in a container to be able to use this interface.
This seems like this is not the best idea for an individual "freedom" of developer or administrators concerning the deployment of their application but this is a good restriction nevertheless because it makes many things much easier.
And this is very useful.

When using a strongly typed programming language (like C# or Java) the first time, you may wonder:
"Why do I have do declare a variable explicitly?
Why do I have to define a type for the variable?
Why can I not just write `myVariable = 42` without any overhead like I can do in python?"
The simple answer is:
Because a clearly visible frame really helps you to not leave the frame-area by accident.
Explicit variable-declarations help to define whether `myVariable` may contain double-numbers or just integers and it also help to have a explicit variable-declaration with the result of a clearly defined scope where the variable can be used.
Adapt this principle.
Maybe it takes some getting used to.
But remember:
No developer of a strongly typed programming language would complain about a missing variable-declaration, he/she would just be advised to the important question:
Where exactly should the variable be defined and which data are allowed to be assigned to it?
And then you just write the variable-declaration.

Your build-pipeline failed?
It just shows you that you have missed something and it must be fixed.

**It is important to understand that the purpose of a seatbelt is to protect you and not to restrict your capabilities.
Do whatever you want:
You can be sure that the seatbelt will hold you in place as long you have fastened it.
The framework ensures that all functions you need are accessible from within your protected and well defined scope of action.**

So let us use this principles also for source-code repositories!
It is reasonable to add a some requirements also for structuring git-repositories to implement the next step to make software-development better, easier and more especially reliable:

**Use a standardized file-structure inside a git-repository.**

This helps everyone to use nearly consistent build-pipelines and -scripts, differing only in a few things.
Management of a repository will be easier because there is less "uneven-stuff" but more well-known structure instead.

For this proposals are templates and specifications defined in this repository.
**To use it, there is no need to restructure existing projects.**
The overhead of existing projects can simply be adapted to the standardized repository-structures defined in this repository.
The source-code of existent projects can be simply inserted to a predefined folder-structure with a clearly defined place for the sourcecode-files.
The purpose of this templates-repository is to add additional standards which make standard-tasks (merging, building, etc.) available in a unique standardized-way, applicable for nearly all projects.

## Repository-Conventions

### Structure

This repository implements the structure-requirements defined by [MinimalRequirements](./Templates/Conventions/RepositoryStructure/MinimalRequirements/MinimalRequirements.md).

### Development

#### Branching-system

This repository applies the [MainLine](./Templates/Conventions/BranchingSystem/MainLine.md)-branching-system.