JS

Comment les web components évitent d’accumuler de la dette technique ?

  • 20 décembre 2019

Beaucoup de projets prennent du retard car des anomalies s’accumulent. Pour optimiser le travail et les relations entre les designers et les intégrateurs, il est possible de réduire la dette technique d’un projet en utilisant les web components.

Dans cet article, Rudy, UX designer chez NeoLynk, propose des pistes de solutions pour répondre à cette problématique.

Le manque de communication, l’origine du retard dans un projet

Généralement dans un projet il y a plusieurs attentes. On se dit qu’on va faire des brainstorming tous ensemble, qu’on va communiquer. Mais dans la réalité c’est tout à fait différent. Il arrive que les équipes ne se parlent pas. Les graphistes et les intégrateurs sont chacun dans leur coin et personne ne communique. Du coup les informations ne circulent pas et on se retrouve avec un projet mal ficelé.

“ Les problèmes doivent se résoudrent en amont pour éviter l’effet d’entonnoir ”

Quand on rentre dans un projet déjà bien avancé, on peut parfois se retrouver comme dans une jungle. C’est-à-dire qu’on a des éléments de partout et on ne sait pas vraiment ce qu’on doit toucher. “Si je touche ça, est-ce que je ne vais pas casser quelque chose ailleurs ?”

Plus les anomalies s’accumulent, plus le projet va s’enraciner dans la dette technique et accumuler du retard. Les anomalies que l’on retrouve dans un projet peuvent être nombreuses.

Les couleurs en sont un très bonne exemple en CSS. S’il n’y a pas de référentiel de déterminé, on peut avoir des surprises. Par exemple une couleur ayant plusieurs dizaines de teintes différentes. Ça c’est pour les couleurs, mais imaginez que ce problème soit pour des polices, pour des marges, etc.

Concevoir en ayant une vision produit !

Si rien n’est établi, on peut avoir un produit simple au départ que l’on va tellement complexifier qu’il subira des régressions à chaque modification.

Si la vision d’ensemble du produit ou si certaines spécifications ne sont pas claires, alors le produit pourra très bien marcher au début. Cependant cela sera une illusion. Au fil du temps, il gagnera en complexité et il sera pratiquement impossible de maintenir le projet sans à chaque fois mettre des pansements.

Idéalement, dans toutes les organisations on va miser sur un produit qui va pouvoir grandir sur le long terme sans accumuler de la dette ni du retard. Cela s’opère sur tous les niveaux, mais prenons un exemple, et particulièrement en CSS.

Attention à la spécificité des éléments !

exemple d'un projets avec des éléments trop spécifiques

Sur le graphique ci-dessus, qui est un aperçu (100 lignes de codes), on voit une complexité qui commence à se dessiner avec les courbes en hauteur.

Si la courbe monte trop, c’est parce qu’un élément du site est trop spécifique. Il ne pourra plus être modifié sans que l’on créer d’autres composants de plus en plus complexe pour surcharger l’élément.

Le mot “Cascade” en CSS est très important, c’est ce qui va créer la spécificité. Si le web component est spécifique à un élément ou à une page, on ne pourra plus revenir en arrière. On ne pourra plus le déspécifier. On ne pourra alors que le complexifier davantage.

Exemple ci-dessous : Un produit qui a mal vieilli (l’échelle est d’environ 5000 lignes de codes).

Exemple d'un produit qui a mal vieilli

On observe toute la complexité du CSS globale du site avec les différents pics. On a des web components qui sont sur-spécifiés. Dès qu’on voudra modifier un des composants sur le site, on va fatalement toucher à des composants qui existent dans d’autres pages, ou alors on va devoir en créer de nouveaux.

Comment éviter de complexifier inutilement un projet ?

Avant de tout refactorer, déjà d’un point de vue graphique, on peut essayer en amont de prototyper les maquettes. On a des maquettes qui sont belles à première vue. Il faut ensuite les éprouver (en mettant différentes longueurs de phrases sous un bloc par exemple). On peut même faire un semblant de prototype sur InVision. C’est-à-dire montrer ce qu’il va se passer quand on clique sur tel lien, comment va réagir la page, qu’est ce qu’il se passe si je passe mon bouton sur un hover.

Ce sont les outils comme InVision, Adobe XD ou même Sketch qui permettent d’avoir une vision fonctionnelle sur ces éléments graphiques.

D’un point de vue technique, on va pouvoir créer nos différents web components avec l’aide des différents prototypages. On ne va plus penser en terme global mais on va scinder nos différents éléments en éléments beaucoup plus petits qu’on va pouvoir agréger ensemble pour éviter d’avoir un élément trop complexe à la base.

 web components et prototypages
 web components et prototypages

Par exemple, lorsqu’on voit une page comme celle ci-dessus, on peut se dire qu’elle est complexe à coder. On va alors fonctionner du plus petit vers le plus grand. Si on essaie de repérer les différents web components, on se rend compte qu’au final la page n’est pas si complexe. On a un composant texte, qui est ici le titre, un autre composant qui est le bouton et un autre qui est l’image. Ces trois web components associés ensemble forment un web component plus grand que l’on va pouvoir dupliquer.

En rouge ce sont les web components basiques et en bleu le web component agrégé. Le CSS n’a pas été créé spécifiquement dans la page en elle-même. Il a été créé indépendamment de n’importe quel environnement. On va donc pouvoir utiliser ces composants ici, mais aussi sur plusieurs autres pages. Le but est de pouvoir assembler ces différents web components comme si on jouait au Lego.

projet avec web components assemblés

Si on reprend ce système de web components non spécifiques et qu’on refait une génération de notre CSS, on arrive à ce genre de résultats. En bas de la courbe on a les web components très simples : les atomes. Et lorsque la courbe remonte on a les organismes.

On remarque qu’à chaque fois la courbe monte puis redescend. Les pics que l’on remarque à la fin correspondent à de la surcharge. Cette surcharge est expliquée par le fait qu’on utilise des plugin (pour des carrousels par exemple) qui viennent d’autres librairies.

Gagner du temps avec des web components non spécifiques

En utilisant des web components non spécifiques, les développeurs auront moins de tâches rébarbatives et complexes. Ainsi avec une meilleure vision d’ensemble, ils pourront mieux estimer le temps qu’ils vont passer sur chaque page. Ce qui va aider les chefs de projet.

D’autre part, les développeurs seront à-même de détecter rapidement les anomalies, en allant toujours du plus grand vers le plus petit. L’idéal est que le côté intégration et le côté graphique puissent travailler en harmonie.

Les graphistes vont créer une librairie avec chaque élément qui composent le site. Si les graphistes font ces efforts, les développeurs gagneront du temps pour récupérer et intégrer ces web components dans le CSS.

Pas de dette technique avec un Design System automatisé !

L’idéal serait d’utiliser un Design System automatisé que l’on puisse réutiliser. Il existe des outils qui vont générer automatiquement un style guide comme ci-dessous.

Style guide

KSS ou Hologram sont des outils qui vont générer automatiquement ce genre de style guide. Celui-ci est utile pour les graphistes car ils voient que leurs maquettes concordent et c’est utile pour les développeurs back et front car ils voient chaque élément, et sur chaque élément on peut avoir le détail du code HTML utilisé.

À retenir pour ne pas accumuler de la dette technique :

  • Favoriser la communication entre designers et développeurs
  • Ne pas avoir de web components trop spécifiques
  • Créer des web components indépendants
  • Concevoir avec une vision produit
  • Créer un Design System automatisé
  • Toujours se mettre à la place de quelqu’un de nouveau qui doit intervenir pour la première fois sur la conception du produit