Télécharger pour lire hors ligne
![Packaging et livraison
Nature du projet ?
Management du projet ?
Historique et communication ?
Intégration continue ?
[ ]](https://image.slidesharecdn.com/industrialiserledev-151020053717-lva1-app6892/75/Industrialiser-le-dev-front-end-Boris-Schapira-Bdx-io-11-2048.jpg)
![[ ]
Installation
Développement
Intégration
Maintenance
[ ]](https://image.slidesharecdn.com/industrialiserledev-151020053717-lva1-app6892/75/Industrialiser-le-dev-front-end-Boris-Schapira-Bdx-io-14-2048.jpg)
Téléchargé parBoris SCHAPIRA
Industrialiser le dev. front end · Boris Schapira · Bdx.io
Le document traite de l'industrialisation du développement front-end en abordant des aspects variés tels que l'accessibilité, le sémantique, les composants web, et les technologies modernes comme le CSS et JavaScript. Il souligne l'importance de la gestion des dépendances, de l'automatisation des tâches, et des tests de performance pour améliorer l'efficacité du développement web. Enfin, il mentionne la nécessité d'assurer la maintenance et le débogage au fil du temps tout en favorisant une bonne communication et une gestion de projet efficace.
Industrialiser le dev. front end · Boris Schapira · Bdx.io
- 1. Industrialiser le dév. Front-End BorisSchapira - Bdx.io 2015
- 3. Accessibilité, sémantique, mark-upapplicatifs, micro-datas et attributs ARIA, Web Components avec des Custom Elements et des HTML imports utilisant des HTML Templates et du Shadow DOM, Images en RWD utilisant picture ou figure avec figcaption, Canvas, SVG, balises médias Audio/Video, Speech Input, Templating Jade/HAML ou à balisage léger, Sélecteurs CSS, Polices et WebFonts, Grilles Float ou flexbox ?, Couleurs et opacités, HSLA, gradients, bords arrondis, ombres, background, Animations, Transition, Support des navigateurs, préprocesseurs, postprocesseurs, normalisateurs et reset, autoprefixer, Closures, Hoisting, localStorage, openDatabase, indexedDb, AppCache, Service Workers, Notifications, Drag’nDrop, Filesystem API’s, Géoloc, Orientation, Précompilateurs JS, linters... Le Web aujourd’hui : HTML + JS + CSS ?
- 4. 10 % ? 30% ? 60 % ? Valeur ajoutée ✘
- 6. Gains - de temps -de confort - de confiance✓
- 7. Gestion des dépendances Dépendancesà plat ou en arbres ? Versionning sémantique ? Pérénité des dépôts de dépendances ? Existant Back ?
- 8. Tâches orchestrées Pré /Post / Compilateurs ? Génération de variantes d’images ? Optimisations de ressources ? Formateurs / Linters à la volée ?
- 9. Observateur de modification Quelsfichiers observer ? Quelle action en fonction de quelle modification ? Mise à jour synchronisée du navigateur sur plusieurs devices ?
- 10. Contrôles Validation statique HTML+ JS + CSS ? Tests de performance ? Navigateurs cibles Usages cibles (navigateur + contexte) ?
- 11. Packaging et livraison Naturedu projet ? Management du projet ? Historique et communication ? Intégration continue ? [ ]
- 12. Moteur d’automatisation Qui doitle programmer, avec quelles compétences ? Quelles sont les briques disponibles sur les machines ? Quelle communauté pour les ajouts ?
- 13. Maintenance et débogage Reprisedu processus plusieurs semaines / mois / année plus tard ? Capacité à diriger le trafic vers des fichiers locaux ?
- 14.
- 15. Accessibilité, sémantique, mark-upapplicatifs, micro-datas et attributs ARIA, Web Components avec des Custom Elements et des HTML imports utilisant des HTML Templates et du Shadow DOM, Images en RWD utilisant picture ou figure avec figcaption, Canvas, SVG, balises médias Audio/Video, Speech Input, Templating Jade/HAML ou à balisage léger, Sélecteurs CSS, Polices et WebFonts, Grilles Float ou flexbox ?, Couleurs et opacités, HSLA, gradients, bords arrondis, ombres, background, Animations, Transition, Support des navigateurs, préprocesseurs, postprocesseurs, normalisateurs et reset, autoprefixer, Closures, Hoisting, localStorage, openDatabase, indexedDb, AppCache, Service Workers, Notifications, Drag’nDrop, Filesystem API’s, Géoloc, Orientation, Précompilateurs JS, linters... Solutions ?
- 19.
- 20. The Noun Project CreativeCommons BY 3.0 - US : documents par John Slater Gear par Dmitry Baranovskiy Building blocks par Olivier Rooker Process par Rflor Baranovskiy Box par Nicolas Vicent Crosshair par Chris, NZ Observation par Arthur Shlain Licences d’utilisation Accept File par mantisshrimpdesign Browser Upload par Tahsin Tahil, BD Browser par Zlatko Najdenovski, MK Cloud par Viktor Fedyuk User icons par Wilson Joseph Discussion par Milky - Digital innovation Flickr : pitiful par latteda - CC BY 2.0
- 21. Des liens qu’ilssont biens : “Mes projets Web se passent toujours bien”, Jérémie Patonnier “Readme Driven Development”, Thomas Parisot “Développeurs front : vous n’utilisez pas de proxy ?”, Stéphane Tessier “Intégrateur Web vs. Développeur Front-End”, Marie Guillaumet “Yeoman”, Florian Lonqueu-Brochard “Pourquoi je préfère Brunch”, Christophe Porteneuve
Notes de l'éditeur
- #3 Après le lycée, j’ai fait Maths Sup / Maths Spé. Dès le premier cours, notre professeur de Mathématiques nous a expliqué qu’il allait nous faire apprendre des démonstrations. Soit. Nous avons commencé par les corps et les anneaux, puis la formule du binôme de Newton. Quelques jours plus tard, c’était les polynômes de Lagrange et de Tchebychev... Quand nous allions en khôlles (pour ceux qui ne connaissant pas, les khôlles sont les oraux hebdomadaires en classes préparatoires) avec ce professeur, il sortait son chapeau des démonstrations magiques, on tirait un petit papier, et on savait ce qu’il fallait coucher sur le tableau. Au début, il fallait réussir deux démonstrations en une heure pour avoir 20. A la moitié de l'année, nous avions déjà une bonne trentaine de démonstrations à connaître par coeur. A la fin de l’année, nous en avions plus de 70, et il fallait en sortir 4 en moins d’une heure. Son explication était très simple : "Votre cerveau, c'est le plus merveilleux des outils. Bien entraîné, il vous donnera les réponses que vous attendez... à condition de ne pas le faire réfléchir à des trucs inutiles. Ces démonstrations sont faciles. Elles ne doivent pas vous fatiguer. Vous devez pouvoir les dérouler sans fatigue, en commençant à penser aux questions d’après. Votre valeur ajoutée est dans votre capacité à résoudre de nouveaux problèmes, pas des problèmes dont on connaît déjà la solution. Il faut tout faire pour que la routine devienne juste ça : de la routine, des vacances pour votre cerveau.”
- #4 S’il y a bien un domaine dans lequel l’innovation galope en ce moment, c’est le Web. Et le Front ne fait pas exception, avec des navigateurs toujours plus puissants et riches de fonctionnalités. A tel point que les standards sont désormais qualifiés de “vivants” ! Etre intégrateur en 2015, c’est ainsi maîtriser un nombre très important de concepts théoriques et pratiques, les faire concilier avec des jeux de contraintes parfois assez flous, notamment sur la qualité que tout le monde prône mais que peu savent justifier quand le projet prend du retard, ajouter à cela le support des navigateurs anciens mais aussi de l’enrichissement avec les fonctionnalités des nouveaux. Le tout en prenant en compte les API du futur pour ne pas être complètement à la rue quand les Web Components viendront tout écraser sur leur passage (quoi, on peut rêver non ?).
- #5 Et pour autant, chaque jour, le développeur Front-End et/ou l’intégrateur passe énormément de temps à gérer des choses assez inutiles qui sont périphériques à ses besoins et le pénalisent dans sa capacité de production.
- #6 D’autres questions doivent également se poser : “Quelle est la réversibilité de ma solution, est-elle maintenable ?” “S’il m’arrive quelque chose demain ? Et si quelqu’un reprend mon code ? Et si, pris par mes autres projets… j’oublie ?” Si, à code source égal, vous êtes le seul détenteur de la méthode permettant de produire la solution, alors vous êtes une partie du problème.
- #7 Ce dont on parle quand on parle d’industrialisation du développement Front-End, ce n’est pas un ou plusieurs outils. C’est avant tout un processus destiné à vous faire gagner du temps, du confort et de la confiance. Comment ce processus se décrit-il ?
- #8 Le premier des besoins est celui de de la **gestion des dépendances**. La version de jQuery que vous utilisez sera-t-elle toujours la même jusqu'à la mise en Production ? Sera-t-elle compatible avec le plugin que vous souhaitiez utiliser ? Où trouvez-vous ces scripts ? Sont-ils enregistrés dans le gestionnaire de code source et sinon, les dépôts à partir desquels vous les téléchargez sont-ils pérennes ?
- #9 Une fois vos dépendances gérées et votre propre contenu produit, comment orchestrez-vous les **tâches récurrentes** comme l'application des (pré·post)compilateurs, la génération de vos images RWD à partir des <em lang="en">master</em>, les optimisations des ressources de tous types, l'auto-formatage du code source ou à l'inverse, le jeu de test de certains validateurs de mise en forme du code ?
- #10 Une fois ces tâches accomplies, disposez-vous d'un **observateur de modifications** capable de recharger les contenus ? Il peut s'agir d'un rechargement complet du navigateur ou d'un rechargement de la feuille de style uniquement. Le rechargement peut être local à la machine de développement ou être provoqué à distance sur tous les périphériques testés...
- #11 Cet observateur est-il capable de déclencher, en parallèle du rechargement de votre navigateur, une série de **contrôle** comme la conformité W3C du code HTML, la pertinence du JavaScript, la détection de règles inutiles en CSS. Etes-vous capables de mesurer la performance relative de votre modification par rapport à l'existant ? Des scénarios de tests fonctionnels peuvent-ils être joués ?
- #12 Reste enfin la question de la **finalité** du travail de l'intégrateur ou du développeur Front-End et des moyens à employer pour y arriver. Ici, tout dépend de la nature du projet et des équipes qui en ont la charge. Mais on peut imaginer la génération automatique d'une documentation à l'usage des futurs mainteneurs (y compris soi-même), le packaging d'une version complète de l'intégration et son envoi vers une destination identifiée, via un tag dans un gestionnaire de code source ou le déploiement d'une archive sur un serveur d'intégration.
- #13 Toutes ces tâches ne se produiront pas seules. Un **chef d'orchestre logiciel** sera nécessaire et bien sûr, il faudra le paramétrer et le maintenir. Il faut donc qu'il soit techniquement proche des compétences des collaborateurs, mais aussi peu éloigner de leurs installations techniques pour éviter d'ajouter une couche de dépendance à vos projets. Enfin, il faudrait choisir un orchestrateur capable de gérer vos besoins d'ajouts : autant donc en choisir un qui dispose d'une bonne communauté d'utilisateurs.
- #15 4 grandes phases de l’intégration Front End : démarrage du projet, développement du projet, intégration dans une solution plus globale, maintenance. Premier réflexe : la documentation ! Si vous avez des procédés en interne, vous devez les documenter. Une fois que le processus est bien défini, il est souvent pratique de l’automatiser, c’est à dire d’un gérer les dépendances, puis de générer, à l’aide d’une succession d’opération logiques, les fichiers à déployer. Une fois ces fichiers générés, un processus observateur se chargera de mettre les navigateurs connectés à jour pour un retour visuel immédiat. A chaque itération ou lors de moment bien définis, le développeur doit pouvoir lancer un cycle de validation : validation du code HTML/CSS/JS par des linters ou le validator du W3C, validation sur la taille des ressources statiques, validation par le jeu d’un test de performance ou d’un scénario de tests unitaires… Si tout est bon, alors il est envisageable de packager et de livrer sur un environnement cible (par exemple un serveur d’intégration ou le travail pourra être vu de tous). Enfin, dans une perspective de maintenance, il est bon que le processus d’intégration
- #16 Mais alors, quel outil pour l'industrialisation ?
- #17 Il existe une très importante variété d'outils sur le marché, ayant tous leur communauté d'utilisateurs et des milliers de raisons d'être vos favoris.
- #19 En effet, il y a du bon partout. J'ai utilisé pendant des années [un framework PHP](https://github.com/htmlzengarden/outline) qui répondait à plusieurs de ces besoins. A l'usage, ses limites m'ont donné envie de tester des pistes différentes et j'ai testé des chaines de productions Front End en Ruby ou dernièrement en node, dont la [version 4.2.0](https://nodejs.org/en/blog/release/v4.2.0/ "Node v4.2.0 (LTS)"), sortie il y a 4 jours est enfin la première version disposant d'un support à long terme. Mon conseil est donc le suivant : réunissez votre équipe de production Front End. Analyser les compétences en interne. Vous avez probablement déjà des sensibilités sur le sujet, des personnes qui ont déjà essayé certaines solutions. Si ce n'est pas le cas, le passage de node en <acronym lang="en" title="Long Time Support">LTS</acronym> est une bonne occasion de partir dans cette direction avec par exemple [Yeoman](http://yeoman.io/) ou [Brunch](http://brunch.io/) (respectivement pour les intégrateurs et les développeurs Front End). Utilisez, critiquez, itérez et construisez votre propre industrialisation, celle qui correspond à vos pratiques et valorisent vos savoir-faire. Si vous me montrez la vôtre, je vous montre la mienne.