Implémentation

Qualité du code

[Explication des conventions de codage, description des outils de "linting" et de tout ce qui a été mis en place pour s'assurer de la qualité du code produit.]

Convention de codage:

Bonnes pratiques au niveau frontend (react)

Structure des dossiers de composants:

Les fichiers de composant ou de page (JS) sont placés dans des dossiers représentants leurs catégories. Par exemple il y a un dossier connection qui contient:

• un fichier js qui est la page de connection/inscription (conreg.js),
• deux fichiers de type "composant" qui sont le composant connection (connexion.js) et le composant d'inscription (register.js).

On vaillera donc à respecter cette convention lors de la création d'autres pages comme dans l'exemple suivant:

Est-ce que la catégorie de la page que je vais créer est déjà représentée par un dossier ?

=> Si oui, je créer mes fichier js dans ce dernier

=> Si non, je créer un nouveau dossier représentant la catégorie de ma page et j'y place mes fichier js.

Structure des fichiers JS de composants:

Les fichiers sont construit d'une manière très précise. En effet, vu que nous utilisons React et StyledComponents, l'allure du code est un peu spécifique.

Quand nous créons un fichier, nous essayons de suivre la structure suivante:

• 1: La déclaration de toutes les dépendances utilisé par le fichier,
• 2: Les Hooks et tous autres constantes ou fonctions,
• 3: Le return de la fonction du composant contenant la structure à proprement dite de la page,
• 4: Le css de chaque balise de la strucutre du composant définit avec StyledComponents,
• 5: Éventuellement, si le composant utilise Axios pour faire des requêtes backend, nous mettons les fonctions qui permettent de faire les liaisons avec les fichiers d'action (les "connetors"),
• 6: Dernièrement, l'export de la fonction principale du composant.

Structure des fichiers JS d'actions:

Les fichiers d'action sont nommés de manière claire pour que l'on puisse directement comprendre quel est leur utilisation. Par exemple, carAction.js, orderAction.js, userAction.js, etc (définition des noms en lowerCamelCase). Ces fichiers contiennent donc des fonctions qui utilisent Axios pour faire différents types de requêtes vers le backend. carAction contiendra donc toutes les requêtes Axios concernant les voitures (ajout de voitures, récupération des voitures, etc).

Il faut également vailler à définir chaque requête dans le fichier actionTypes.js.

Bonnes pratiques lors de l'utilisation de StyledComponents:

Dans notre projet, StyledComponents est utilisé pour facilité la création et l'utilisation du CSS pour chaque composant créé. Quand une nouvelle balise StyledComponent est créée il faut la nommer en CamelCase.

StyledComponents doit être utilisé pour augmenter la compréhension du code, il n'est cependant pas recommendé de l'utiliser tous le temps. En effet, dans notre code, on peut observer des endroits avec des simples balises <p> ou des <input>, en effet, ces balises sont assez explicites et on a donc pas vraiment d'utilité à utiliser StyledComponents. Par contre, on peut remplacer les traditionnels imbrications de <div> par quelque chose de bcp plus compréhensible et lisible pour le développeur.

Exemple:

Ce code

		<div className="container">
			<Header/>
			<div className="content">
				{!connexion
						? <Register onSwap={toggle}/>
						: <Connexion onSwap={toggle}/>}
			</div>
		</div>

Deviens ceci avec StyledComponent:

		<Container>
			<Header />
			<Content>
				{!connexion
						? <Register onSwap={toggle}/>
						: <Connexion onSwap={toggle}/>}
			</Content>
		</Container>

Bonnes pratiques au niveau backend (Express JS):

Structure des fichiers controllers:

Les controllers sont des fichiers permettant d'effectuer des actions avec la base de données. Ces fichiers js suivent une convention de nommage simple mais efficace. Par exemple le fichier qui contient toutes les requêtes relatives au voitures est nommé "car.js". Chaque requête est donc placée dans le fichier qui correspond à sont utilisation (récupérer la liste des voitures => car.js, ajouter un user => user.js, etc).

Lors de la rédaction de requêtes dans un fichier controller il faut veiller à:

• Bien nommer sa requête, c'est à dire que sont nom soit cohérent avec sont utilisation,
• Utiliser les try et les catch (error) {} pour définir la réaction lorsqu'une requête ne passe pas,
• Toujours return quelque chose pour chaque fontion.

Ou placer les images ?

Des images peuvent être trouvées à deux endroits différents dans notre projet:

• Dans le dossier backend/images,
• Dans le dossier frontend/public/images.

Dans le fichier backend/images, nous viendrons mettre toutes les images des voitures, des cartes d'identitées, etc. En bref toutes les images qui sont "éphémères" et donc suceptibles d'être supprimées lors de la suppression d'une voiture par exemple. Ces images sont donc automatiquement créées par le code.

Ensuite, dans le fichier frontend/public/images, il faut placer toutes les images utilisées par le code comme les images de background ou les logos. Ces images ne doivent pas être supprimées car elle sont indispensable à l'aspect visuel du site. Contrairement aux images du bakcend, elles sont créées par le développeur lors de la création d'une page.

Assurer la qualité du code (PATSON):

Nommage des variables

Le camelCase est principalement utilisé pour les variables niveau frontend et backend car le language utilisé est le javascript.source . A certains endroit on peut retrouver du snace_case qui sont les noms des colonnes de la base de donnée.

Nous essayons pour d'attribuer à chaque variable un nom qui la décrit au mieux comme dans cette exemple où startDate représente la date de début de location d'une voiture

Documentation du code

Afin de faciliter la compréhension du code des commentaires sont aussi mis en place pour chaque bout de code qui nécessite un peu de réflexion mais aussi des commentaires qui décrivent ce que fait chaque fonction dans le code

Lisibilité du code

Nous essayons de respecter des conventions déjà établies en scindant le code dans des dossiers qui décrivent au mieux les tâches éffectuées.

Une aérationnous permet de nous retrouver facilement dans les 02 parties du projet frontend et backend et permet une meilleur lisibilité du code du code.

Un niveau d'imbrication de 4 espaces configuré grâce à l'extension prettier nous permet d'accroître énormement la lisibilité

Bilan global de la réalisation

Historique des fonctionnalités (AYMAR)

[Descriptions des fonctionnalités réalisées aux différentes étapes du projet (ex : MVP, sprint 1, ...), type "release notes"]

Historique de conception (RACHID)

[Explications de l'évolution éventuelle des choix de conception au cours du projet. Par ex : Changement d'architecture, modification de certains choix technologiques, refactoring approfondi, ... ]

Bugs résiduels / dette technique (PAYMAR et PATSON)

[Description des éventuels "éléments défecteux" identifiés, à corriger dans des versions ultérieures. Pointez éventuellement vers les "issues" de votre repo si ces dernières sont claires et bien organisées.]

Bilan des implémentations individuelles d'US

POURBAIX Michaël: US02 - Ajouter des véhicules

État actuel de la us:

À tester.

Description de l'état d'avancement de la US:

L'ajout de voiture est implémenté et fonctionnel. En effet la page add-cars permet à l'administrateur de préciser, via un formulaire, toutes les caractéristiques de la nouvelle voiture et de l'ajouter à la base de données. Il puet également ajouter le nombre d'images qu'il souhaite pour cette voiture.'

Points forts:

• La plupart des fonctionnalités demandées sont présentes
• Ajout d'un pop-up afin d'informer l'administrateur que la voiture à bien été ajoutée
• Possibilité d'ajouter plusieurs images pour la voiture et d'en retirer

Pistes d'amélioration:

• Quelques réglages CSS avec le pop-up
• Pas encore d'ajout de vidéo possible

Abderrachid BELLAALI: US01 - Afficher les voitures

État actuel de la us:

À tester.

Description de l'état d'avancement de la US:

L'affichage des voitures est implémenté et fonctionnel. La page Cars liste toutes les voitures disponibles. Celle-ci les affiches avec leur titre, caractéristique technique et les images correspondant à chacune.

Points forts:

...

Pistes d'amélioration:

• Quelques réglages CSS
• Responsive

CARDIN Patson: US05 - Choisir la plage horaire de location

État actuel de la us:

In progress.

Description de l'état d'avancement de la US:

• Une système de calendrier à déjà été mise en place au niveau de la page d'acceuil et de la barre des filtres dans la page d'affichage de voiture.
• L'utilisateur peut déjà choisir un plage horaire de location
• Cette sélection récupère bien les voitures disponibles à cet intervalle précis
• L'affichage des voitures filtrées est en cours de réalisation.

Points forts:

• Mettre en place le style et les conditions nécessaire au bon fonctionnement du calendrier effectué avec react-date
• La logique à mettre en place pour filtrer les voitures diponibles dans l'intervalle choisis par le visiteur/utilisateur
• L'adaptation du fuseau horaire selon votre localisation. Mise en place grâce à la librairie moment js

Pistes d'amélioration:

• Les conditions de validation de la plage horaire sont à implémenter au niveau du backend.