Voici plus d’un mois (déjà) que je travaille de nouvelle manière pour mon code. Durant l’été dernier, suite à pas mal d’échange avec mes collègues développeurs, je suis passé à l’action pour mon nouveau workflow, pour le mettre à jour. Il était grand temps ! Aussi vais-je vous partager mon petit bilan de ces changements effectués dans mes outils et autres installations, afin de vous faire profiter de mon expérience.
1 – Etablir son périmètre
D’abord, j’ai établi un état des lieux de mon processus de travail, listé mes outils et envisagé les améliorations à pousser. Pas trop compliqué : du Sass installé via Ruby et compilé par Koala, mon éditeur de code Sublime Text version 3 avec quelques packages jamais vraiment actualisés. Le site est hébergé en local sur ma machine… Puis en filet, un backup fait régulièrement à la volée, histoire de sécuriser un minimum…
Voici la map de mon processus de travail depuis 2 ans maintenant (Sass étant ma dernière évolution de travail en code). Somme toute assez archaïque avec un risque relatif conséquent à chaque avancement de code. Et oui pour chaque projet, je reprends un noyau commun avec HTML5 Boilerplate, quelques lignes de code factorisées en base avec mes mixins personnalisées ajoutées à celles de Compass et dernièrement le framework Bourbon. bien sûr, j’ajoute quelques bibliothèques JQuery. Et je constate alors que l’ajout d’outils sans limites m’oblige à régler (en mode archéologique) quelques conflits, doublons ou encore incompatibilités. Petit à petit j’élimine d’un côté, mais rajoute de l’autre côté, dans le flot de nouveautés web, c’est trop tentant ! Et c’est là que le problème se pose : dans cette profusion de frameworks, bibliothèques et applications web, lesquels choisir ?? Il peut être difficile de faire le bon choix d’outils, en terme de perspicacité et de pérennité.
2 – Découvrir le feu
Heureusement, j’ai à mes côtés des développeurs sans melon qui ont pu me conseiller et m’aider à y voir plus clair. Après une prospection sur les réseaux et Github, j’ai pris mon courage à deux mains, et ai ouvert mon terminal sur mac.
J’ai installé Node.js. Alors j’ai tenté de comprendre de quoi il en retournait…. Je passais du côté back…. Et finalement, j’ai relativisé : Node n’est ni un serveur ni un framework. Il est plus juste de le définir comme une plateforme Javascript qui permet finalement d’installer et gérer des packages d’applications, des bibliothèques pour automatiser les futures actions dont j’aurai besoin pour mon travailler sur mon site web : comme à un self, je prends un plateau (Node) et j’y mets les plats que je choisis pour les manger (mes paquets choisis via npm). En fait, on peut dire que le npm est un exécuteur de commandes qui permet via notre terminal d’aller chercher le paquet et l’installer.
A partir de ce moment, je peux faire du « npm install … » pour lancer mes paquets via npm (Node Package Manager).
3 -Passer de l’âge de pierre à l’âge de bronze
Première chose capitale pour moi, faire du versionning. Stop au développement front sans filet, aux sueurs froides et autres galères de développement… J’ai installé Git ! Et bonjour au travail sous contrôle de version. Enfin, mon travail s’enrichit d’une sécurité avec un historique spécifié sur mes enregistrements successifs.
4 – Lancer la chasse
Mais alors, quels paquets ? Tout dépendra de votre projet web, bien sûr. C’est pourquoi, il faut avoir une lucidité pragmatique sur son projet web, sa structure et son montage front-end. Notamment, sur les tâches répétitives afin de les éviter par les bons outils. Voici ma sélection :
Grunt : outil qui permet de générer ou créer des tâches automatisées en Javascript (compiler, concaténer, minifier…)
Bower : gestionnaire des dépendances (entre paquets et frameworks) et des mises à jour, évitant les conflits de plusieurs versions ou les incompatibilités, et permettant donc des les garder à jour sans intervenir manuellement,
Yeoman : le chef d’orchestre, il intègre les outils de gestion de projet et scaffolding, mais aussi, Grunt et Bower, comme une suite de workflow,
PostCSS : l’extra compatibilité de notre code CSS, l’après Auto-prefixer, l’incorporation des polyfills, et autres nettoyages extrêmement utiles pour notre cher CSS, comme les content ‘ ‘.
Voici donc…
… les choix pour la mise en place de mon workflow pour mes développements front-end. L’idée qui m’a guidée, a été principalement d’ordonner et structurer mes développements, gagner du temps et en efficacité, mais aussi faire du bon code sécurisé, viable et (relativement) pérenne.
Peu à peu, je poursuis la métamorphose, car une chose est sûre aujourd’hui, c’est que le back-end s’infiltre de plus en plus dans le front. Ce n’est vraiment pas évident, car cela complexifie fortement le métier de front, mais c’est la mutation du métier. Encore faut-il que cette complexité demeure au niveau de la performance des outils, sans toucher à la complexité gratuite par émulation qui n’apporte rien à l’optimisation du projet web.
n’hésitez pas à commenter mon article et partager vos expériences, merci !
Quelques précisions :
> installer un paquet en global
> un très bon tuto pour Node Js et les npm