Refactoring CSS : Introduction (Partie 1)

CSS est un langage de feuille de style simple pour définir la présentation d'un site Web ou d'un document. Cependant, cette simplicité laisse la porte ouverte à de nombreux problèmes potentiels et dettes techniques - code gonflé, enfer de spécificité, blocs de code dupliqués avec très peu ou pas de différence, restes de sélecteurs inutilisés, hacks inutiles et solutions de contournement, pour n'en nommer que quelques-uns.

Ce type de dette technique, si elle n'est pas payée à temps, peut s'accumuler et entraîner de graves problèmes sur toute la ligne. Le plus souvent, cela peut entraîner des effets secondaires inattendus lors de l'ajout de nouveaux composants d'interface utilisateur et rendre la base de code difficile à maintenir. Vous avez probablement déjà travaillé sur un projet avec une mauvaise base de code CSS et pensé à la façon dont vous aviez écrit le code différemment, en ayant la possibilité de tout refactoriser ou de tout réécrire à partir de zéro.

Refactoriser de grandes parties de code CSS n'est pas une tâche facile à tous points de vue. Parfois, il peut sembler qu'il s'agit simplement de "supprimer le code de mauvaise qualité, d'écrire un meilleur CSS et de déployer le code amélioré brillant". Cependant, de nombreux autres facteurs doivent être pris en compte, tels que la difficulté de refactoriser une base de code en direct, la durée prévue et l'utilisation de l'équipe, l'établissement d'objectifs de refactorisation, le suivi de l'efficacité et des progrès de la refactorisation, etc. Il y a aussi la question de convaincre la direction ou les parties prenantes du projet de investir du temps et des ressources dans le processus de refactorisation.

Dans cette série en trois parties , nous allons parcourir le processus de refactorisation CSS du début à la fin, en commençant par savoir comment l'aborder et quelques avantages et inconvénients généraux de la refactorisation, puis en passant aux stratégies de refactorisation elles-mêmes et en terminant avec quelques bonnes pratiques générales sur la taille et les performances des fichiers CSS.

Effets secondaires d'un CSS de mauvaise qualité

Malgré toute sa flexibilité et sa simplicité, CSS lui-même présente des problèmes fondamentaux qui permettent aux développeurs d'écrire du code de mauvaise qualité en premier lieu. Ces problèmes proviennent de sa spécificité et de ses mécanismes d'héritage, fonctionnant dans une portée globale, de la dépendance à l'ordre des sources, etc.

Au niveau de l'équipe, la plupart des problèmes de base de code CSS proviennent généralement des niveaux de compétence et des connaissances CSS variables, des préférences et des styles de code différents, du manque de compréhension de la structure du projet et du code et des composants existants, de l'absence de projet ou d'équipe normes et lignes directrices au niveau de l'établissement, etc.

Par conséquent, un CSS de mauvaise qualité peut causer des problèmes qui vont au-delà des simples bogues visuels et peut produire divers effets secondaires graves qui peuvent affecter le projet dans son ensemble. Certains de ces exemples incluent:

• Diminution de la qualité du code à mesure que de nouvelles fonctionnalités sont ajoutées en raison des différents niveaux de compétence CSS au sein d'une équipe de développement et du manque de règles internes, de conventions et de meilleures pratiques.
• L'ajout de nouvelles fonctionnalités ou l'extension de sélecteurs existants provoque des bogues et des effets secondaires inattendus dans d'autres parties du code (également appelé regression ).
• Plusieurs sélecteurs CSS différents avec des blocs de code dupliqués ou des morceaux de code CSS peuvent être séparés en un nouveau sélecteur et étendus par variation.
• Morceaux de code restants et inutilisés provenant de fonctionnalités supprimées . L'équipe de développement a perdu la trace du code CSS utilisé et de celui qui peut être supprimé en toute sécurité.
• Incohérence dans la structure des fichiers, la dénomination des classes CSS, la qualité globale du CSS, etc.
• "L'enfer de la spécificité" où de nouvelles fonctionnalités sont ajoutées en remplaçant au lieu d'exister la base de code CSS.
• Annulation du CSS où les sélecteurs de spécificité supérieure "réinitialisent" le style de sélecteur de spécificité inférieure. Les développeurs écrivent plus de code pour avoir moins de style. Cela entraîne une redondance et beaucoup de gaspillage dans le code.

Dans le pire des cas, tous les problèmes susmentionnés combinés peuvent entraîner une taille de fichier CSS importante , même avec la minification CSS appliquée. Ce CSS bloque généralement le rendu, de sorte que le navigateur ne rendra même pas le contenu du site Web tant qu'il n'aura pas fini de télécharger et d'analyser le fichier CSS, ce qui entraînera une UX et des performances médiocres sur des réseaux plus lents ou peu fiables.

Ces problèmes affectent non seulement l'utilisateur final, mais également l'équipe de développement et les parties prenantes du projet en rendant la maintenance et le développement de fonctionnalités difficiles, chronophages et coûteux. C'est l'un des arguments les plus utiles à évoquer lorsque l'on plaide pour une refactorisation ou une réécriture CSS.

L'équipe de Netlify a noté que la raison de leur projet de refactorisation CSS à grande échelle était la diminution de la qualité et de la maintenabilité du code à mesure que le projet gagnait en complexité avec de plus en plus de composants d'interface utilisateur ajoutés. Ils ont également remarqué que le manque de normes et de documentation CSS internes entraînait une baisse de la qualité du code, car de plus en plus de personnes travaillaient sur la base de code CSS.

« (…) ce qui a commencé avec le PostCSS organisé s'est progressivement transformé en une architecture CSS globale complexe et enchevêtrée avec beaucoup de spécificités et de dérogations. Comme vous vous en doutez, il y a un point où la dette technologique supplémentaire qu'elle introduit rend difficile de continuer à expédier rapidement sans ajouter de régressions. En outre, à mesure que le nombre de développeurs frontaux contribuant à la base de code augmente également, ce type d'architecture CSS devient encore plus difficile à utiliser. »

Refactoriser ou réécrire ?

La refactorisation permet aux développeurs d' améliorer progressivement et stratégiquement la base de code existante, sans modifier sa présentation ou ses fonctionnalités de base. Ces améliorations sont généralement de petite portée et limitées, et n'introduisent pas de changements architecturaux de grande envergure, ni n'ajoutent de nouveaux comportements, fonctionnalités ou fonctionnalités à la base de code existante.

Par exemple, la base de code actuelle comporte deux variantes d'un composant de carte - la première a été implémentée au début du développement du projet par un développeur expérimenté et la seconde a été ajoutée quelque temps après le lancement du projet par un développeur moins expérimenté dans un court délai, donc il comporte un code dupliqué et des sélecteurs étendus avec une grande spécificité.

Une troisième variante de carte doit être ajoutée, qui partage certains styles des deux autres variantes de carte. Ainsi, afin d'éviter les bogues, le code dupliqué et les classes CSS complexes, ainsi que le balisage HTML sur toute la ligne, l'équipe décide de refactoriser le composant CSS de la carte avant d'implémenter une nouvelle variante.

La réécriture permet aux développeurs d'apporter des modifications substantielles à la base de code et suppose que la plupart sinon la totalité du code de la base de code actuelle sera modifiée ou remplacée. La réécriture permet aux développeurs de créer la nouvelle base de code à partir de zéro, de résoudre les principaux problèmes de la base de code actuelle qui étaient impossibles ou coûteux à résoudre, d'améliorer la pile technologique et l'architecture et d'établir de nouvelles règles internes et les meilleures pratiques pour la nouvelle base de code.

Par exemple, le client est en train de changer de marque et le site Web doit être mis à jour avec un nouveau design et un contenu remanié. Puisqu'il s'agit d'un changement prêt à l'emploi à l'échelle du site , les développeurs décident de repartir de zéro, réécrivent le projet et profitent de cette occasion pour résoudre les problèmes principaux que la base de code CSS actuelle a mais ne peut pas être résolus avec la refactorisation du code, mettre à jour la pile technologique CSS , utilisez les outils et fonctionnalités les plus récents, établissez de nouvelles règles internes et les meilleures pratiques pour le style, etc.

Résumons les avantages et les inconvénients de chaque approche.

Quand refactoriser le CSS ?

La refactorisation est une approche recommandée pour améliorer progressivement la base de code CSS tout en conservant l'apparence actuelle (conception). Les membres de l'équipe peuvent travailler sur la résolution de ces problèmes de base de code lorsqu'il n'y a pas de tâches prioritaires. En améliorant progressivement l'expérience utilisateur de la base de code actuelle, cela ne sera pas directement affecté dans la plupart des cas, cependant, une base de code plus propre et plus maintenable se traduira par une implémentation plus facile des fonctionnalités et moins de bogues et d'effets secondaires inattendus.

Les parties prenantes du projet accepteront probablement d'investir un temps et des ressources limités dans le refactoring, mais ils s'attendront à ce que ces tâches soient effectuées rapidement et s'attendront à ce que l'équipe soit disponible pour les tâches principales.

La refactorisation CSS doit être effectuée à intervalles réguliers lorsqu'aucune modification de conception ou de contenu de grande envergure n'est prévue dans un avenir proche. Les équipes doivent rechercher de manière proactive les points faibles mentionnés précédemment dans la base de code CSS actuelle et s'efforcer de les résoudre chaque fois qu'aucune tâche prioritaire n'est disponible.

Le développeur frontend principal ou le développeur ayant le plus d'expérience avec CSS doit soulever des problèmes et créer des tâches de refactorisation pour appliquer les normes de qualité du code CSS dans la base de code.

Quand réécrire le CSS ?

La réécriture de la base de code CSS complète doit être effectuée lorsque la base de code CSS présente des problèmes fondamentaux qui ne peuvent pas être résolus par la refactorisation ou lorsque la refactorisation est une option plus coûteuse. Parlant d'expérience personnelle, lorsque j'ai commencé à travailler pour des clients qui ont quitté une autre entreprise et les problèmes CSS susmentionnés et qu'il était évident que ce serait un travail difficile à refactoriser, je commencerais par recommander une réécriture complète et voir quoi pense le client. Dans la plupart des cas, ces clients n'étaient pas satisfaits de l'état de la base de code et étaient heureux de procéder à la réécriture.

Une autre raison de la réécriture complète du CSS est lorsqu'un changement substantiel est prévu pour le site Web - changement de marque, refonte ou tout autre changement important qui affecte la majeure partie du site Web. Il est prudent de supposer que les parties prenantes du projet sont conscientes qu'il s'agit d'un investissement important et qu'il faudra un certain temps pour que la réécriture soit terminée.

Audit de la santé de la base de code CSS

Lorsque l'équipe de développement a convenu du fait que le code CSS doit être refactorisé pour rationaliser le flux de travail de développement des fonctionnalités ou éliminer les effets secondaires et bogues CSS inattendus, l'équipe doit faire part de cette suggestion aux parties prenantes du projet ou à un chef de projet.

C'est une bonne idée de fournir des données concrètes parallèlement aux réflexions subjectives sur la base de code et la révision générale du code. Cela donnera également à l'équipe un objectif mesurable dont elle pourra être consciente tout en travaillant sur le refactor - taille du fichier cible, spécificité du sélecteur, complexité du code CSS, nombre de requêtes multimédias...

Lors d'un audit CSS ou de la préparation d'un refactoring CSS, je m'appuie sur plusieurs des nombreux outils utiles pour obtenir un aperçu général et des statistiques utiles sur la base de code CSS.

Mon outil personnel de prédilection est CSS Stats, un outil gratuit qui fournit un aperçu utile de la qualité de la base de code CSS avec de nombreuses mesures utiles qui peuvent aider les développeurs à détecter certains problèmes difficiles à repérer.

En 2016, trivago a procédé à une refactorisation à grande échelle de sa base de code CSS et a utilisé les métriques de CSS Stats pour définir des objectifs concrets et mesurables, tels que la réduction de la spécificité et la réduction du nombre de variations de couleur. En seulement trois semaines, ils ont réussi à améliorer la santé globale de la base de code CSS, à réduire la taille du fichier CSS, à améliorer les performances de rendu sur mobile, etc.

"Un outil comme CSS Stats peut facilement vous aider à résoudre les problèmes de cohérence au sein de votre base de code. En indiquant ce qui peut arriver lorsque tout le monde a des opinions différentes sur la façon dont un ton gris devrait ressembler, vous vous retrouverez avec 50 nuances de gris. De plus, Specificity Graph vous donne une bonne indication globale de la santé de votre base CSS.

En ce qui concerne les outils CLI, Wallace est un outil pratique qui fournit des statistiques et une vue d'ensemble quelque peu basiques mais utiles qui peuvent être utilisées pour identifier les problèmes liés à la taille du fichier, au nombre de règles et de sélecteurs, aux types de sélecteurs et à la complexité, etc.

Wallace propose également un outil d'analyse gratuit sur le site Web de Project Wallace qui utilise une version apparemment plus avancée de Wallace dans le backend pour fournir des visualisations de données utiles et quelques mesures supplémentaires qui ne sont pas disponibles dans la CLI de Wallace.

Project Wallace propose également une solution payante complète pour l' analyse de la base de code CSS . Il propose des fonctionnalités et des mesures encore plus utiles qui peuvent aider les développeurs à détecter certains problèmes difficiles à repérer et à suivre les modifications des statistiques CSS par validation. Bien que le plan payant inclue plus de fonctionnalités, le plan gratuit et l'outil d'analyse CSS de base sont plus que suffisants pour auditer la qualité de la base de code CSS et obtenir un aperçu général pour planifier la refactorisation.

Rédaction de CSS de haute qualité

Nous avons vu comment la simplicité et la flexibilité de la base de code CSS peuvent causer de nombreux problèmes de qualité du code, de performances et de bogues visuels. Il n'y a pas d'outil automatique miracle qui garantira que nous écrivons le CSS de la meilleure façon possible et évitons tous les pièges architecturaux possibles en cours de route.

Les meilleurs outils qui garantiront que nous écrivons du code CSS de haute qualité sont la discipline, le souci du détail et les connaissances et compétences générales en CSS . Le développeur doit être constamment conscient de la situation dans son ensemble et comprendre le rôle que joue son CSS dans cette situation.

Par exemple, en surspécifiant les sélecteurs, un seul développeur peut limiter considérablement la convivialité, ce qui oblige d'autres développeurs à dupliquer le code afin de l'utiliser pour d'autres composants similaires avec un balisage différent. Ces problèmes surviennent souvent lorsque les développeurs manquent de compréhension et n'exploitent pas les mécanismes sous-jacents derrière CSS (cascade, héritage, performances du navigateur et spécificité du sélecteur). Ces premières décisions peuvent avoir des répercussions majeures à l'avenir , de sorte que la santé et la maintenabilité de la base de code CSS reposent sur les connaissances, les compétences et la compréhension des principes fondamentaux du CSS par le développeur.

Les outils automatisés ne sont pas conscients de la situation dans son ensemble ou de la manière dont le sélecteur est utilisé, ils ne peuvent donc pas prendre ces décisions architecturales cruciales, en plus d'appliquer certaines règles de base, prévisibles et rigides.

Parlant d'expérience personnelle, j'ai trouvé ce qui suit m'a aidé à améliorer considérablement la façon dont j'ai travaillé avec CSS :

• Apprentissage des modèles architecturaux.
  Les directives CSS fournissent une excellente base de connaissances et les meilleures pratiques pour écrire du CSS de haute qualité basé sur des modèles de programmation généraux et des principes architecturaux.
• Entraînez-vous et améliorez-vous.
  Travaillez sur des projets personnels ou relevez un défi de Frontend Mentor pour améliorer vos compétences. Commencez par des projets simples (un seul composant ou une section) et concentrez-vous sur l'écriture du meilleur CSS possible, essayez différentes approches, appliquez divers modèles architecturaux, améliorez progressivement le code et apprenez à écrire efficacement du CSS de haute qualité.
• Apprendre des erreurs.
  Croyez-moi, vous écrirez des CSS de très mauvaise qualité lorsque vous débuterez. Il vous faudra quelques essais pour bien faire les choses. Prenez un moment et réfléchissez à ce qui n'a pas fonctionné, analysez les points faibles, réfléchissez à ce que vous auriez pu faire différemment et comment, et essayez d'éviter les mêmes erreurs à l'avenir.

Il est également important d' établir des règles et des normes CSS internes au sein d'une équipe ou même pour l'ensemble de l'entreprise. Des normes, un style de code et des principes clairement définis à l'échelle de l'entreprise peuvent apporter de nombreux avantages, tels que :

• Style et qualité de code unifiés et cohérents
• Base de code plus facile à comprendre et robuste
• Intégration de projet simplifiée
• Des revues de code standardisées qui peuvent être effectuées par n'importe quel membre de l'équipe, pas seulement le développeur frontend principal ou les développeurs plus expérimentés

Kirby Yardley a travaillé sur la refonte du système de conception et du CSS du Sundance Institute et a souligné l'importance d'établir des règles internes et des meilleures pratiques.

"Sans règles et stratégie appropriées, CSS est un langage qui se prête à des abus. Souvent, les développeurs écriront des styles spécifiques à un composant sans réfléchir de manière critique à la manière dont ce code pourrait être réutilisé dans d'autres éléments (…) Après de nombreuses recherches et délibérations sur la manière dont nous voulions aborder l'architecture de notre CSS, nous avons décidé d'utiliser une méthodologie appelée ITCSS. "

Pour en revenir à l'exemple précédent de l'équipe de trivago, l'établissement de règles et de directives internes s'est avéré être une étape importante pour leur processus de refactoring.

"Nous avons introduit une bibliothèque de modèles, commencé à utiliser la conception atomique dans notre flux de travail, créé de nouvelles directives de codage et adapté plusieurs méthodologies telles que BEM et ITCSS afin de nous aider à maintenir et à développer notre CSS/UI à grande échelle."

Toutes les règles et normes n'ont pas besoin d'être vérifiées et appliquées manuellement. Les outils de linting CSS tels que Stylelint fournissent des règles utiles qui vous aideront à vérifier les erreurs et à appliquer les normes internes et les meilleures pratiques CSS courantes, telles que l'interdiction des blocs et des commentaires de code CSS vides, l'interdiction des sélecteurs en double, la limitation des unités, la définition de la spécificité maximale du sélecteur et de la profondeur d'imbrication, l'établissement modèle de nom de sélecteur, etc.

Conclusion

Avant de décider de proposer une refactorisation granulaire de la base de code ou une réécriture complète du CSS, nous devons comprendre les problèmes avec la base de code actuelle afin de pouvoir les éviter à l'avenir et disposer de données mesurables pour le processus. La base de code CSS peut contenir de nombreux sélecteurs complexes à haute spécificité qui provoquent des effets secondaires et des bogues inattendus lors de l'ajout de nouvelles fonctionnalités, peut-être que la base de code souffre de nombreux morceaux de code répétés qui peuvent être déplacés dans une classe utilitaire distincte, ou peut-être le mélange de diverses requêtes multimédias provoquent des conflits inattendus.

Des outils utiles tels que CSS Stats et Wallace peuvent fournir un aperçu général de haut niveau de la base de code CSS et donner un aperçu détaillé de l'état et de la santé de la base de code. Ces outils fournissent également des statistiques mesurables qui peuvent être utilisées pour définir les objectifs du processus de refactoring et suivre l'avancement du refactoring.

Après avoir déterminé les objectifs et la portée de la refactorisation, il est important de définir des directives internes et des meilleures pratiques pour la base de code CSS - convention de dénomination, principes architecturaux, structure de fichiers et de dossiers, etc. Cela garantit la cohérence du code, établit une base de base au sein du projet qui peut être documentée et qui peut être utilisé pour l'intégration et la révision du code CSS. L'utilisation d'outils de filtrage comme Stylelint peut aider à appliquer certaines bonnes pratiques CSS courantes pour automatiser partiellement le processus de révision du code.

Dans le prochain article de cette série en trois parties, nous allons plonger dans une stratégie de refactorisation CSS à toute épreuve qui assure une transition transparente entre la base de code actuelle et la base de code refactorisée.

Les références

• "Gérer des projets CSS avec ITCSS", Harry Roberts
• "Refactorisation CSS à grande échelle chez Trivago", Christoph Reinartz
• "Système de conception Sundance.org et refactorisation CSS", Kirby Yardley
• "Du CSS sémantique à Tailwind : refactorisation de la base de code de l'interface utilisateur Netlify", Charlie Gerard et Leslie Cohn-Wein
• "Outils d'audit CSS", Iris Lješnjanin