Agreements

The agreements we made regarding code structure and the decisions on what tech to use

JavaScript

We agreed to the following terms:

• JavaScript ES6 This means we use import on the server-side and client-side. We do not use var only const and let, we use arrow functions, and we do not use .then.

• Work in modules client-side and server-side Joeri re-wrote the code to use modules and import/export, every feature gets its own JavaScript file. Server-side code has routes and controllers, and all code is written in the src folder.

• Work in feature branches Every feature has its own branch. If you want to test something or experiment with a new feature, you open a new branch. If your branch is merged with development, you close it.

• Project management in GitHub projects All features and tasks are labelled using MoSCoW and labelled by what sort of code the feature entails. The project board is divided by: to-do, doing, done and continuous development. You add your issue to the board and are responsible for your own cards. MoSCoW labels can be continuously updated when we get later into the project. Some things change in the course of the project and get a different level of importance.

• Add bugs and features in GitHub issues and add them to the project board If you finish a task, you pick a new issue from the board and assign it to yourself. This way you alert the other teammates on your work.

• Manage tasks using MoSCoW method All tasks are split by importance to the project. MoSCoW stands for: Must have, Should have, Could have and Would have. Must have is vital for the application to work, Should have is important to make the application usable, Could have is for everything you do when there's time left, Would have is for things you cannot finish this time around but will get to in further development.

• Merge all features from branches onto development branch before deploying If you finish a feature or bug, you merge your branch with development and test if the feature works in the application with no bugs.

• Everyone reviews pull requests If you want to merge onto development, other people review the code for problems or bugs before you deploy.

• Explain the code and CSS in comments Code is neatly commented for yourself and others to understand.