Retour d’expérience de mon premier projet NodeJS en stage

Je vous raconte comment s’est déroulé mon premier projet de stage en startup. The good, the bad and the ugly (mais surtout le bon).

(ceci n’est pas une pub pour les biscuits petit déjeuner) Photo by Azzeddine

Ça y est, j’ai fini mon premier projet de stage ! Pour l’occasion, je me suis dit que ça serait intéressant de documenter mon retour d’expérience. C’est exactement le type de contenu que j’aurais aimé lire pendant ma recherche de stage. Surtout que mon chemin jusqu’ici n’a pas été de tout repos.

🎓 ️Mon parcours avant la tech

J’ai d’abord commencé à toucher au code (ou plutôt no-code) pendant mes études d’architecture, avant de rentrer dans le monde professionnel en agence. Mais après 1 an d’exercice, je me suis retrouvée face à la frustration de ne pas avoir d’impact, ni en interne, ni en externe. J’ai décidé de me réorienter vers le monde de la programmation, et de tenter ma chance du côté de l’école 42. Après trois années intenses passées à étudier, me voilà enfin à la recherche d’un stage de fin d’études.

Logiciel 3D de no-code que j’utilisais (Rhinoceros + Grasshopper). Image par Rodrigo Ruiz

✍ Mes critères : monter en compétences tout en ayant des sujets intéressants, dans un environnement paisible, agile, où je serais intégrée à l’équipe technique. Je pensais que ce serait impossible de cocher toutes ces cases …

Pourtant, j’ai trouvé ce que je cherchais. Je suis maintenant stagiaire développeuse FullStack chez Teamstarter. L’objectif qu’on s’est fixé, est que je monte en compétences en backend, dont NodeJS, sur des sujets utiles à l’entreprise.

🔍 Etat des lieux chez Teamstarter

L’idée de ce premier projet, est née d’un process qui pouvait être amélioré : on est dans une startup, qui travaille en méthode agile. On fait du CI/CD en ayant des montées en prod plusieurs fois par semaine (quand tout roule). Le PM supervise ces dernières.

Maintenant, imaginez vous à la place du release manager, qui veut faire une montée en prod. Il doit vérifier chaque commit, un par un, pour s’assurer que le code en pré-prod est testé, et que le statut des tâches associées est à jour. Ça devient vite fastidieux, surtout quand l’équipe s’agrandit et code vite. 😰

C’est là que j’interviens. Pour premier projet, Vincent le CTO, me propose de créer un script en NodeJS TypeScript.

Ce script va vérifier si les tâches attribuées aux développeurs ont bien été effectuées et testées. Dans le cas contraire, rendre clair les actions à effectuer. Le but est de faire gagner du temps à tout le monde.

Et voilà à quoi cela ressemble :

Output de la librairie check-release avec différents statuts pour chaque US et cas de warnings.

• Les tâches qui sont prêtes à être mises en prod renvoient vers le lien de la tâche sur Jira.
• Le statut des tâches et leur ID sur Jira sont affichés, accompagnés d’un emoji pour avoir une lecture rapide et un code couleur qui permet visuellement d’avoir les informations.
• Les tâches qui n’ont pas pu être identifiées renvoient vers le lien du commit sur GitHub

Output quand toutes les US sont prêtes à être montées en prod

👩🏻‍💻 Retour d’expérience de mon équipe

Il y a deux utilisations concrètes de cette lib. La première, la plus logique, est pour les dev de pouvoir vérifier rapidement le statut de la release via le terminal avec la commande release-check. La deuxième, moins évidente, est la manière dont cette information est communiquée au release manager. Et en l’occurence, via slack. Le retour d’expérience se fait donc sur ces deux utilisations.

Et ce dernier est positif ! Les informations sont clairement visibles. Les liens utiles dans la vérification et le changement de statut des tâches. Le script permet aussi de tagger les personnes assignées aux tâches et ça fonctionne bien sur Slack. Donc j’ai rempli ma mission de rendre l’output lisible et actionnable. ✅

On a aussi remarqué quelques améliorations qui pourraient être implémentées dans le futur. Par exemple, un ticket qui a été ré-ouvert apparaît deux fois à la sortie. Et l’output sous forme de tableau ne rend finalement pas bien, ni sur le terminal, ni sur Slack.

Je vous invite à aller tester la lib, me faire vous aussi vos retours, et agrandir cette liste d’améliorations.

🧠 Ce que j’ai appris

Le plus important pour moi, à travers cet exercice, c’est d’avoir pu monter en compétences. Je vais donc vous partager plusieurs concepts que j’ai retenus :

• Chez Teamstarter, on m’a recommandé d’utiliser le pattern d’early return. Le principe est : écrire les comportements d’erreurs en premier, puis le comportement attendu en dernier. Je trouve que ce style de code fluidifie la lecture puisqu’on peut immédiatement identifier les cas d’erreurs. Dans tous les cas, les conventions qui unifient l’écriture du code entre les développeurs vont me permettre de lire plus facilement la codebase.

// Before
function xxx(a, b) {
 if (a < b) {
    return a + b
  } else {
    throw Error('Bad usage!')
  }
}
// Better
function xxx(a, b) {
 if (a >= b) {
    throw Error('Bad usage!')
  }
  return a + b
}

• Certaines fonctions ne sont utilisées que pendant le développement (pour tester par exemple), et inutiles au package NPM. Une manière intéressante de switcher entre le déploiement du package et le développement est d’utiliser une variable d’environnement, qu’on définit ensuite à l’execution du script.

if (process.env.CHECK_RELEASE_ENV && process.env.CHECK_RELEASE_ENV === "dev")
  // Call dev function
else
  // Call package function

• Le debugger de CHROME 😍
  (S’il n’y a qu’une chose à retenir, ne retenez que ça.)
  Après des années à utiliser printf()ou console.log()pour débugger, je suis enfin passée à un vrai débugger. Oui oui, vous avez bien lu. Vincent en a carrément fait un pré-requis pour ce projet. J’avais peur que l’utilisation soit fastidieuse, et me fasse perdre du temps. Mais en réalité, ça peut-être c’est un gain de temps. Alors, je ne dis pas que je vais arrêter d’utiliser console.log (désolée Vincent 🫢), mais il sera réservé pour certains usages. Si j’ai besoin de vérifier une variable rapidement par exemple. Avec NodeJS on peut utiliser l’inspector de Chrome grâce à ces paramètres : node --inspect ou node --inspect-brk.

🤔 Ce qui m’a challengé

Il y a aussi des points qui ont moins bien fonctionnés pour moi, et sur lesquels j’ai beaucoup appris. Notamment, mieux planifier la structure de mon code.

Quand j’ai commencé à coder sur ce projet, j’avais une liste de features établies à l’avance. Comme à mon habitude, j’ai regardé rapidement les notions que je ne connaissais pas, pour estimer leur complexité. Puis j’ai fait ma petite liste interne, de l’ordre dans lequel j’allais coder ces features.

Une des features demandées consiste à imprimer l’output sous forme de tableau avec console.table(), que je ne connais pas. J’ai regardé rapidement la doc et noté que la fonction prend un array en paramètre. Pas de soucis à priori, donc j’ai remis la feature a la fin, et oublié ce détail. Je n’ai pas assimilé à ce moment là que la logique de console.table(), de prendre un array en paramètre, n’est pas la façon dont j’ai structuré mon code avec console.log(), qui lui prend une string. 😓

Arrivée à cette étape, j’ai donc dû refactor une bonne partie de mon code. J’en ai profité pour mieux structurer mon code en général (par ex. implémenter des interfaces Typescript), mais c’est quand même du temps perdu. En conclusion, il faut que je sois plus attentive dès l’étape de réflexion du code, pour optimiser mon temps, et ne plus tomber dans ce genre de piège.

Photo by Headway on Unsplash

D’ailleurs, chez Teamstarter, on a ce qu’on appelle un challenge architectural. C’est un point quotidien auquel les devs participent si besoin. Le but est de challenger une solution auprès des autres, afin de trouver la meilleure manière de coder. Et éventuellement se prémunir d’une mauvaise structure de code avant de se lancer dans la production !

💭 Mon avis sur ce premier projet

Je pense que ce projet a été une bonne introduction au stage. Je connaissais déjà le langage et je n’ai pas eu de difficultés à comprendre le sujet. J’ai pu apprendre pleins de choses, discuter avec les devs, et créer un outil utile. C’est la première fois que j’ai un impact dans la boîte aussi rapidement. C’est aussi la première fois que je publie un package NPM, et un article 💪.

Pour les curieux, je vous link le repo Github. N’hésitez pas à contribuer au projet via des PRs si ça vous intéresse. Et à poser vos questions ici.

Accessoirement il reste d’autres places de stages ouvertes dans notre équipe.