Se faire à l'environnement, mes premières tâches

Pour mener à bien mon sujet de stage, il était nécessaire de bien comprendre l'environnement dans lequel je travaille. Étant donné que le projet est assez avancé, il est assez complexe à prendre en main et à maîtriser, surtout pour quelqu'un comme moi qui n'avait jamais travaillé sur des aussi gros projets et encore moins en entreprise.
Pour cela, les membres de l'équipe m'ont proposé quelques sujets pour me faire la main sur les technologies utilisées et l'architecture du projet.

Compétences à acquérir

Pour travailler sur mon sujet de stage, il a fallu que je me fasse aux technologies utilisées par l'équipe sur la partie front-end.

Redux

Une des principales technologies qu'il fallait apprendre afin d'être opérationnel sur la stack (ensemble de technologies) utilisée par l'équipe est Redux.

Logo Redux

Redux est une librairie de state management (gestion d'état), elle va gérer le "store" de notre application, celui-ci contient l'état global, le contexte, de l'application.
Pour donner un petit exemple assez simple, on peut imaginer un site d'e-commerce, quand nous ajoutons un article à notre panier, il faut que notre panier soit au courant que tel article a été ajouté, c'est ici qu'intervient la notion de state :

Le composant "Article" va interagir avec le store en lui disant d'ajouter tel article dans l'état du panier
Le composant "Panier" va récupérer les valeurs de l'état du panier dans le store, et afficher les données récupérées

Cet exemple est assez facile à comprendre car il y a peu de données et d'états à manipuler, mais il faut prendre en compte que plus l'application grossit, plus il peut y avoir de données et d'états à gérer.
Redux est donc une technologie beaucoup utilisée dans le monde du développement Web, cependant c'est une technologie pas toujours simple à apprendre et maîtriser, et demande généralement assez de temps d'adaptation.

Afin de me faire la main assez facilement sur Redux, je me suis donc entraîné en faisant un petit projet d'un petit site de vente très simple.

Initiation à Redux

Dans ce cas-là, nous avons un composant "ListeProduits" qui contient des composants "Produit", ce composant "ListeProduits" va aller chercher les produits dans le store Redux et afficher les composants "Produit" selon les données récupérées.

Pour ajouter un produit au panier, nous interagissons avec un composant "Produit", en cliquant sur le bouton "Add to cart", cette action va en déclencher une autre du coté de Redux, c'est ce qu'on appelle un "reducer", c'est une fonction qui va interagir avec l'état du panier, elle va modifier le contenu du panier et mettre à jour le store avec ce nouvel état.

Et enfin, le composant "Panier" va récupérer le contenu de l'état "Panier" dans le store Redux, et afficher les données.

Voici comment est défini le store :

store.ts

export const store = configureStore({
    reducer: {
        cart: CartSlice.reducer,
        products: ProductsSlice.reducer
    }
})

Et voici un exemple d'un reducer, celui-ci permet de récupérer une liste de produits via une API et de mettre ces données dans le store :

productsSlice.ts

export const fetchProducts = createAsyncThunk("products/fetch", async (thunkAPI) => {
    const response = await fetch("https://647f415fc246f166da906fb8.mockapi.io/products", {
        method: "GET"
    });
    const data = response.json();
    return data
})

Voici un petit schéma pour résumer le fonctionnement de Redux :

Fonctionnement de Redux

L'utilisateur interagit avec l'UI (l'application Web), ce qui déclenche une action, qui va appeler un reducer afin de modifier le store. Une fois que le store est modifié, l'UI se met à jour pour afficher les nouvelles valeurs.

Mise en pratique

Une fois que j'ai commencé à comprendre comment fonctionnait Redux (qui représente une grosse partie de l'application de gestion de flotte chez EasyMile), j'ai donc pu pratiquer directement sur l'application de gestion de flotte.
Pour commencer assez facilement, les membres de l'équipe m'ont proposé de rajouter une nouvelle métrique sur la vue globale des véhicules, cette mise en pratique était simplement un exercice, et non une vraie tâche.

Vue globale des véhicules

Le but était de rajouter la métrique du kilométrage sur cette vue. Pour cela il a fallu que je regarde dans le code déjà existant comment les métriques déjà affichées récupèrent leurs valeurs.
Grâce à ca, j'ai pu comprendre le fonctionnement du store Redux de l'application et cela m'a permis de rajouter cette nouvelle métrique assez facilement.

Vue globale des véhicules avec kilométrage

Première vraie tâche: un outil de debug

Après avoir fini mon petit exercice sur l'application de gestion de flotte, j'ai pu commencer ma première tâche !
Celle-ci avait pour but de pouvoir ajouter des petits marqueurs à partir de coordonnées GPS sur une carte de debug afin d'aider les personnes qui font des investigations sur celle-ci.
Par exemple, pour savoir s'il y a eu un problème avec un véhicule, il suffit de rentrer les coordonnées GPS du véhicule lors de l'incident sur la carte de debug afin de visualiser sa position exacte sur le circuit, permettant d'avoir plus d'informations sur le problème survenu (par exemple si le véhicule a été dévié de sa trajectoire et n'est plus sur le circuit).

Carte de debug

Cette tâche a été très instructive, elle m'a permis de voir comment l'équipe travaillait réellement sur le front-end.
Après avoir terminé ma tâche, j'ai pu mettre ma branche de travail en Pull Request sur la branche de développement.

Les Pull Request

Une PR (Pull Request), est le fait de demander à fusionner une branche dans une autre.
Pour notre cas, nous utilisons Git comme gestionnaire de version.
Quand nous commençons un nouveau ticket (une nouvelle tâche), nous créons une nouvelle branche à partir de la branche de développement (la branche principale), cela va créer une copie du code actuellement utilisé afin de pouvoir travailler dessus et faire des modifications sans modifier le code utilisé par les autres personnes.
Une fois que nous avons terminé de travailler sur notre branche, nous faisons une PR pour ajouter nos changements dans la branche principale. Une fois que la PR est créée son status passe en review, c'est-à-dire que les autres membres de l'équipe peuvent regarder nos changements et notre nouveau code, l'approuver, demander des modifications, demander pourquoi avoir fait de cette façon et pas d'une autre s'il y en a une, etc.
Une fois que nos modifications sont approuvées, nous pouvons donc fusionner notre branche avec la branche principale, ainsi les changements seront effectifs pour tout le monde. Cela permet d'être sûr que le nouveau code est fonctionnel, respecte les bonnes pratiques et ne cause pas de régression.

Pull Request

Les PR sont très utiles pour se former sur le terrain, en effet les commentaires que les développeurs plus expérimentés font sur notre code permettent de voir ce que nous n'avons pas forcément fait de la bonne façon, d'apprendre de nos erreurs et comprendre les mauvaises pratiques à éviter.
En mettant des commentaires comme "Pourquoi as-tu fait de cette manière ? Est-ce qu'il est possible de le faire de telle façon ?" , cela nous permet de nous remettre en question et de chercher à comprendre pourquoi cette façon de faire n'est pas la meilleure.
Bien sur, les autres membres de l'équipe sont restés disponibles si j'avais besoin de précision sur leurs commentaires, ce qui m'a permis de monter en compétences, d'apprendre sur le tas les bonnes et mauvaises pratiques.
Personnellement, cette façon de travailler m'a beaucoup appris, mais il faut être prêt à se remettre en question (ce que j'estime nécessaire pour le métier de développeur !).

Commentaire sur une Pull Request

Par exemple, sur la PR de ma première tâche, les autres développeurs m'ont fait des remarques par rapport à ma façon de développer certains composants en React.js, ces commentaires m'ont permis de découvrir des bonnes pratiques et des façons de développer que je ne connaissais pas.
Maintenant que je suis au courant de la bonne façon de faire, je fais plus attention à respecter ces bonnes pratiques pour avoir un code performant et simple à comprendre pour les autres membres.

Je suis assez fier de cette première tâche, le résultat paraît peut-être assez simple, mais cela m'a permis de m'améliorer sur ma façon de travailler.
De plus, le fait que celle-ci réponde à un vrai besoin des utilisateurs de l'application est un point très satisfaisant, j'ai d'ailleurs déjà reçu des remarques des membres de l'équipe pour me dire que cette nouvelle fonctionnalité était très pratique, ce qui est une vraie satisfaction personnelle surtout pour une première tâche !

Après ma première tâche sur la carte de debug, j'ai eu l'occasion de développer entièrement un nouveau widget.
Celui-ci est un indicateur d'avancée de mission, l'ancien n'avait pas le meilleur des designs et n'était pas cohérent avec l'UI/UX de l'application. Quand un véhicule est en train d'effectuer une mission, on peut voir son trajet sur la carte sous la forme d'un trait d'une certaine couleur qui relie le véhicule à sa destination, ce trait se raccourcit au fur et à mesure que le véhicule se rapproche de sa destination, donc plus le véhicule avance, plus le trait de couleur se raccourci.
Le problème de l'ancien widget était que ces couleurs sont inversées ! Le trait de couleur représentait le parcours effectué et non pas celui restant.

Ancien widget de mission

Un ticket Jira a donc été créé, expliquant pourquoi il fallait faire ce changement, et proposant un nouveau design à implémenter.

Ticket Jira

Difficultés

Cette tâche, malgré son aspect simple, avait quelques difficultés à prendre en compte :

Un véhicule peut avoir plusieurs états (pas de mission, à l'arrêt, en train de rouler, arrêt demandé si le véhicule est en mode bus (EZ10))
Penser à l'UX, comment doit se positionner la fleche au départ ? à l'arrivée ? etc
Prendre en compte que les noms des destinations peuvent être longs, il faut donc faire en sorte que cela n'impacte pas l’expérience utilisateur s'il y a un long nom de destination
Ce widget étant utilisé sur plusieurs pages avec des tailles différentes, il faut faire attention à ce qu'il s'adapte bien selon sa taille et les écrans

Pour le fonctionnement du widget, j'ai pu m'inspirer de celui déjà existant pour récupérer les valeurs nécessaires (pourcentage du trajet effectué, destination, heure de départ, heure d'arrivée estimée).
Pour ce qui est de la barre de progression, celle de l'ancienne version avait été entièrement développée par les membres de l'équipe, mais pour la nouvelle version, j'ai utilisé une barre de progression déjà développée et disponible dans une librairie d'UI appelée Material UI.
Cette librairie était déjà utilisée dans l'application pour des boutons ou bien des champs de texte, il n'y a donc pas eu besoin de l'installer uniquement pour cette fonctionnalité, de plus cela rend le code beaucoup plus simple à comprendre et plus lisible.
Cependant, je me suis inspiré du fonctionnement de l'ancienne barre pour rajouter l'icône en forme de flèche et la faire avancer de façon à ce qu'elle soit synchronisée avec la barre de progression.

Une fois que j'étais satisfait de mon résultat, je n'ai pas hésité à demander des avis aux membres de l'équipe, que ce soit spontanément, ou bien le matin lors des réunions de daily, ceci m'a permis d'obtenir les avis de tous les membres et j'ai pu prendre en compte tous ces retours pour améliorer de plus en plus le résultat visuel de ce widget.
Après plusieurs retours, voici la version finale du nouveau widget que j'ai pu développer.

Nouveau widget de mission

Prise en main de l'environnement de développement pendant mon stage