markdown READ MEEDuit的README.md

Posted 2021-05-05

# Trivial-Pursuit

This project was bootstrapped with [Create React App](https://github.com/facebook/create-react-app).

## In the project directory, run `npm start`
Open [http://localhost:3000](http://localhost:3000) to view it in the browser.

##### This app uses JService API => http://jservice.io/

__________________________________________________________


# A l'attention de tous les collaborateurs:


## Architecture typique du projet : chaque composant dans un dossier, dans le dossier Components

On ne fait que du .jsx et du .css. Le JavaScript 'vanille' peut être inséré dans un composant en tant que méthode.

On peut donc utiliser le UpperCamelCase sans réfléchir, et se fixer une simple règle: 
## Chaque composant est dans un dossier à son nom, et chaque fichier porte ce même nom (.jsx et .css), en anglais.

### "Composant Fonction ou Composant de Classe ?"
TOUJOURS Fonction par défaut (plus optimisé). On ne transforme en Classe qu'au moment où on a besoin du 'state'.

#### «Où mettre mon image/ mon icône/ ma police ?»
Toujours dans le Cloud plutôt que dans le dossier de l’app si c’est possible.

### Commentaires: encouragé pour résumer ce que fait un bout de code. Si le besoin de commentaire devient trop grand, penser à diviser le Composant pour le rendre plus facile à maintenir.
## /!\ Pensez à enlever les commentaires avant de merge votre feature dans Dev !

### CSS : 
Quand on utilise une règle de CSS sur exactement un élément : on utilise un #ID. Sur plus d’un élément on utilise une .Classe
Pour les couleurs... Le must quand on peut : économiser des lignes de CSS ‘custom’ en écrasant les classes Reactstrap via un fichier .scss (cf Tuto)

### App.js.
Garder App.js la plus épurée possible devrait être une priorité. Pensez aux générations futures !

App.js reste un Composant de Classe : comme tout composant il doit avoir une fonction bien définie, avec un code clair et pas trop long. Le fait qu’il s’agisse d’une Classe incite à profiter des ‘states’ et à en faire un composant complexe. De plus il s’agit du centre de l’App, ce qui sera injecté dans l’ID ‘root’. Néanmoins il faut s’efforcer de limiter sa taille pour faciliter sa maintenance. De même pour App.css

### Scrum en gros
- Trois ‘rôles’ : Scrum Master, Product Owner, Equipe de Devs
- Un ‘sprint’ dure 1 semaine. On fait un Daily Meeting au début de CHAQUE JOUR du ‘sprint’.
- Chaque ‘sprint’ : le 1er jour on fait une grosse réunion a propos du Backlog. Le dernier jour, on doit pouvoir présenter l’avancement du projet au client afin d’intégrer ses remarques.

### Git en gros
- Nom de branche typique: feature/NomDeFeature
- PULL souvent (1x/jour min) pour ne pas être déçu...
- Message de COMMIT: toujours commencer par un verbe
- Ne JAMAIS toucher le composant d'un autre sans en avoir parlé à l'équipe avant !
- Git permet de ‘remonter le temps’ jusqu’à un Commit déterminé, alors commitez le plus souvent possible !

### Les ressources pour le projet sont centralisées sur deux Trellos :
- Un Trello où l’on centralise nos ressources et éventuellement la ToDo list officieuse
- Un Trello uniquement pour le Backlog

### Crédits
- Djamel
- Isaure 
- Sarah 
- Sébastien