Formation entreprise Node.js chez HexSchool
Quelques reflexions et pensees apres avoir termine la formation entreprise Node.js de HexSchool.
Pourquoi avoir choisi cette formation ? Quel probleme resoudre ?
C'est une formation qui coute assez cher. En parallele, HexSchool (un bootcamp de programmation a Taiwan) ne peut pas, pour des raisons commerciales, refuser les inscriptions, ce qui force le contenu a rester plutot simple.
Vu ces conditions, s'inscrire ne semble pas tres rentable. Mais en pratique, il y a quand meme quelques aspects interessants a considerer :
Travail d'equipe
Des le debut, on doit travailler en groupe. Comme la plupart des participants viennent du frontend et n'ont quasiment aucune experience backend, c'est l'occasion de s'exercer a la communication et a l'avancement en developpement backend.
D'un autre cote, les partenaires avec qui on collabore peuvent aussi s'entraider a l'avenir. C'est une facon de se construire un reseau.
Couts irrecuperables
Comme je disais, la formation est plutot chere. Meme si on est aussi paresseux que moi, si on ne veut pas perdre cet argent, on est oblige d'investir du temps et de l'energie apres le travail pour suivre l'avancement du projet et respecter la deadline. Ca aide aussi, d'une certaine maniere, a atteindre un objectif d'autodiscipline.
Nouvelles perspectives
Puisque le projet est mene de A a Z — du design a la mise en production —, meme si objectivement c'est assez superficiel, tous les membres peuvent traverser une fois le processus complet : PM, UI/UX, frontend, backend. Ca peut apporter de nouvelles perspectives pour le travail futur.
Contenu de la formation
Cote contenu : en dehors des operations de base sur MongoDB et de l'implementation d'API en Node.js, la partie qui a le plus de valeur a mes yeux, c'est l'integration de services tiers — comme l'authentification tierce et les systemes de paiement. C'est un sujet assez aride qui demande du temps pour lire la documentation de chaque service. Quand c'est enseigne dans le cours, ca fait gagner du temps sur la recherche.
Par ailleurs, certains exemples du cours utilisent encore le pattern MVC. Il faut que l'equipe fasse elle-meme la separation frontend/backend lors de la mise en oeuvre du projet, ce qui demande aussi de la reflexion.
Certains contenus sont en fait des cours en direct externalises, ce qui peut creer quelques decalages. Par exemple, les exemples de tests unitaires fournis etaient destines au frontend. Donc si on veut pratiquer les tests unitaires backend, l'equipe doit se debrouiller seule.
Realisation du projet (avis extremement subjectif)
La realisation du projet est, a mon avis, la partie la plus precieuse de cette formation. Et le point le plus crucial, c'est la collaboration et la planification au sein de l'equipe.
Soyez honnetes avant la formation des groupes
Avant la repartition en groupes, il y a une auto-evaluation des competences. Si vous ne maitrisez pas un domaine, soyez honnetes. Si l'ecart de niveau dans l'equipe est trop grand, ca peut vite mener a des divergences serieuses et empecher le projet d'avancer.
Prevoyez du temps tampon pour le developpement
La plupart des participants passent du frontend au backend, et il y a plein de pieges qu'on n'a jamais rencontres en frontend et qui ralentissent le developpement. Par exemple : apres l'integration du paiement, il faut forcement gerer les commandes, et les commandes impliquent des questions de timing des transactions.
En tant que developpeur frontend, on ne se souciait pas de ca avant — on branchait des API et on affichait des listes. Mais en backend, il faut prendre tout ca en compte.
Visez la mise en ligne du projet
Gardez bien en tete les points suivants :
- La plupart des membres ont un travail a temps plein et ne peuvent investir qu'un temps limite (on ne peut pas prevoir si quelqu'un sera sous pression ou en heures sup' au boulot)
- La deadline est tres serree, le temps de developpement reel est limite
- La plupart des membres n'ont pas d'experience backend et vont forcement rencontrer des obstacles
L'objectif de la premiere phase doit etre de produire quelque chose d'utilisable — pas quelque chose de parfait. Ne pensez pas trop a l'architecture, l'optimisation, les tests, etc. a ce stade. Tout ca viendra apres.
Si on cherche trop la perfection, non seulement ca bloque le developpement, mais pire encore, ca peut provoquer une fracture dans l'equipe (conflits potentiels en tout genre, surtout si on ne sait pas si les membres sont sous pression au travail en journee). Une fois l'equipe divisee, le projet a 94,87 % de chances d'echouer. Un feature moche mais fonctionnel peut enormement booster la confiance de tout le monde.
Evitez absolument d'etendre indefiniment les technologies utilisees. Cote frontend, il ne devrait pas y avoir une situation ou on utilise a la fois React et Vue. Meme si quelqu'un dans l'equipe maitrise parfaitement un framework, ca ne veut pas dire que les autres pourront l'apprendre rapidement et l'utiliser en production.
Extension et optimisation
Une fois que le projet a atteint sa premiere fonctionnalite complete, on peut considerer que la premiere phase est terminee. On peut souffler un peu et commencer a reflechir a d'autres fonctionnalites — y compris des technologies qu'on veut essayer ou des ameliorations de l'experience utilisateur.
Pour notre projet par exemple, on a progressivement ajoute le messaging websocket, PWA, des animations, un systeme de check-in, et d'autres choses pour enrichir l'ensemble du site.
Conclusion
Pour finir, voici les liens de deploiement et les repos de notre projet (frontend et admin). N'hesitez pas a y jeter un oeil.
Frontend (Client)
Back-office (Admin)
<!-- test account & password -->
account : admin
password : 12345678
Liens connexes
A propos du fait que je suis devenu coach pour la session entreprise Node.js 2023 de HexSchool