L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2024 !
Introduction (Partie 1) —
La refactorisation CSS n'est pas une tâche facile – elle doit être effectuée de manière à ne pas créer de problèmes. Nous devons d'abord analyser la base de code existante, auditer la santé de la base de code CSS, découvrir les faiblesses, convenir de l'approche et convaincre la direction d'investir du temps et des ressources dans le processus.
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 à la dette technique – code gonflé, enfer de spécificité, blocs de code dupliqués avec très peu ou pas de différence, sélecteurs inutilisés restants, hacks inutiles et solutions de contournement, pour ne citer quelques-uns.
Ce type de dette technique, s'il n'est pas payé à temps, peut s'accumuler et entraîner de graves problèmes à long terme. 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 réfléchi à la façon dont vous aviez écrit le code différemment, étant donné la possibilité de tout refactoriser ou de tout réécrire à partir de zéro.
Refactoring de grandes parties de CSS. code n'est pas une tâche facile par toute mesure. 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, il existe de nombreux autres facteurs à prendre en compte, comme la difficulté de refactoriser une base de code en direct, la durée et l'utilisation attendues de l'équipe, l'établissement d'objectifs de refactoring, le suivi de l'efficacité et de la progression du refactoring, etc. investir du temps et des ressources dans le processus de refactoring.
Dans cette série en trois partiesnous allons parcourir le processus de refactoring CSS du début à la fin, en commençant par les connaissances sur la façon d'aborder lui et quelques avantages et inconvénients généraux de la refactorisation, puis passer aux stratégies de refactorisation elles-mêmes et terminer par quelques bonnes pratiques générales sur la taille et les performances des fichiers CSS.
Effets secondaires de la mauvaise qualité CSS
Pour toute sa flexibilité et simplicité, CSS lui-même a quelques 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, opérant dans une portée globale, la dépendance de 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 différents niveaux de compétence et connaissances CSS, préférences et styles de code différents, manque de compréhension de la structure du projet et du code et des composants existants, absence de normes et de directives au niveau du projet ou de l'équipe, etc.
En conséquence, une mauvaise qualité. CSS peut causer des problèmes qui vont au-delà des simples bogues visuels et peuvent produire divers effets secondaires graves qui peuvent affecter le projet dans son ensemble. Voici quelques exemples de ce type :
- Diminution de la qualité du code à mesure que davantage de fonctionnalités sont ajoutées en raison des différents niveaux de compétences CSS au sein d'une équipe de développement et du manque de règles internes, de conventions et de meilleures pratiques.
- Ajout de nouvelles fonctionnalités ou extension d'existants. les sélecteurs provoquent des bogues et des effets secondaires inattendus dans d'autres parties du code (également connu sous le nom de régression).
- Plusieurs sélecteurs CSS différents avec blocs de code dupliqués ou des morceaux de code CSS peuvent être séparés dans un nouveau sélecteur et étendus par variation.
- Des morceaux de code 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 du fichier, nommage des classes CSS, 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.
- Annuler 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 importantemême avec la minification CSS appliquée. Ce CSS bloque généralement le rendude sorte que le navigateur n'affichera 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 mauvaise expérience utilisateur et des performances médiocres sur des réseaux plus lents ou peu fiables.[19659003] 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, longs 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 la diminution de la qualité du code et la maintenabilité à mesure que le projet devenait de plus en plus complexe avec de plus en plus de composants d'interface utilisateur. ajoutée. Ils ont également remarqué que le manque de normes CSS internes et de documentation a conduit à la diminution de la qualité du code car de plus en plus de personnes travaillaient sur la base de code CSS.
"(…) ce qui a commencé avec PostCSS organisé est progressivement devenu un complexe et une architecture CSS globale enchevêtrée avec de nombreuses spécificités et surcharges. Comme vous pouvez vous y attendre, il y a un moment où la dette technologique supplémentaire qu'il introduit rend difficile de continuer à expédier rapidement sans ajouter de régressions. De plus, comme le nombre de développeurs front-end contribuant à la base de code augmente également, ce type d'architecture CSS devient encore plus difficile à utiliser. Continuez à lire ci-dessous ↓
Refactor Or Rewrite ?
Refactoring permet aux développeurs d'progressivement et stratégiquement améliorer la base de code existante, sans modifier sa présentation ou son noyau Fonctionnalité. Ces améliorations sont généralement de petite portée et limitées, et n'introduisent pas de changements architecturaux de grande envergure et n'ajoutent pas 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 – le premier a été mis en œuvre au début du développement du projet par un développeur expérimenté et le second a été ajouté peu de temps après le lancement du projet par un développeur moins expérimenté dans un délai court, il comporte donc un code dupliqué et des sélecteurs de grande envergure avec une spécificité élevée.
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 bugs, 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 de faire changements substantiels à la base de code et suppose que la plupart sinon tout le code de la base de code actuelle sera modifié ou remplacé. La réécriture permet aux développeurs de créer la nouvelle base de code à partir de zéro, de résoudre les problèmes fondamentaux de la base de code actuelle qui étaient impossibles ou coûteux à résoudre, d'améliorer la pile technique et l'architecture et d'établir de nouvelles règles internes et 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 à l'échelle du site prêt à l'emploi, les développeurs décident de repartir de zéro, de réécrire le projet et de saisir cette occasion pour résoudre les problèmes fondamentaux de la base de code CSS actuelle mais ne peuvent pas être résolus avec le refactor de code , mettez à jour la pile technique 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.
| Refactor | Rewrite | |
|---|---|---|
| Avantages |
|
|
| Inconvénients |
|
|
Quand refactoriser CSS ?
La refactorisation est une approche recommandée pour améliorer progressivement la base de code CSS tout en conservant l'apparence et les frais actuels l (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 de priorité plus élevée. En améliorant progressivement l'expérience utilisateur de la base de code actuelle ne sera pas affectée directement dans la plupart des cas, cependant, une base de code plus propre et plus facile à gérer se traduira par une mise en œuvre plus facile des fonctionnalités et moins de bogues et d'effets secondaires inattendus.
Les parties prenantes du projet accepteront probablement d'investir. temps et de ressources limités dans la refactorisation, 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'aucun des changements de conception ou de contenu de grande envergure ne sont pas prévus 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'il n'y a pas de tâches de priorité plus élevée disponibles.
Le développeur front-end principal ou le développeur ayant le plus d'expérience avec CSS doit soulever des problèmes et créer un refactoring. tâches 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 ce que 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 CSS complète est lorsqu'un changement substantiel est prévu pour le site Web — rebranding , une refonte ou tout autre changement important affectant 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 CSS Codebase Health
Lorsque l'équipe de développement s'est mise d'accord sur le fait que CSS le code doit être refactorisé pour rationaliser le flux de travail de développement de fonctionnalités ou éliminer les effets secondaires et les 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 aux côtés des 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 lorsqu'elle travaillera 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 CSS refactor, 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 de prédilection personnel est CSS Statssa gratuit outil qui fournit un aperçu utile de la qualité de la base de code CSS avec de nombreuses métriques utiles qui peuvent aider les développeurs à détecter certains problèmes difficiles à repérer.
En 2016, trivago a effectué un refactoring à grande échelle pour sa base de code CSS et a utilisé les métriques de CSS Stats pour définir des objectifs concrets et mesurables comme 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 à comprendre 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 l'apparence d'un ton gris, 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 un CSS quelque peu basique, mais utile statistiques et aperçu pouvant être utilisés pour identifier les problèmes liés à la taille du fichier, au nombre de règles et de sélecteurs, aux types et à la complexité des sélecteurs, etc.
Wallace propose également un outil d'analyse gratuit sur le site Web du projet Wallace qui utilise une version apparemment plus avancée de Wallace dans le backend pour fournir des visualisations de données utiles et quelques métriques supplémentaires qui ne sont pas disponibles dans Wallace CLI.
Project Wallace propose également une solution payante complète pour CSS codebase analytics. Il propose des fonctionnalités et des métriques 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 engagement. Bien que le forfait payant comprenne plus de fonctionnalités, le forfait 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.
Écriture 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 avec la qualité du code, les performances et les bugs visuels. Il n'y a pas d'outil automatique miracle qui garantira que nous écrivons CSS de la meilleure façon possible et évitera 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 discipline, souci du détail et 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 image plus large.
Par exemple, en surspécifiant les sélecteurs, un seul développeur peut considérablement limiter 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 ne tirent pas parti des 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 développeurs CSS.
Les outils automatisés ne sont pas conscients de la vue d'ensemble ou comment le sélecteur est utilisé, afin qu'ils ne puissent pas prendre ces décisions architecturales cruciales, en plus d'appliquer des règles de base, prévisibles et rigides.
Parlant d'une expérience personnelle, j'ai trouvé ce qui suit m'a aidé à améliorer considérablement la façon dont je travaillé avec CSS :
- Apprendre les 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. - Pratiquer 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é.[19659011]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 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 robuste et plus facile à comprendre
- Intégration de projet rationalisée
- Revues de code standardisées qui peut être fait par n'importe quel membre de l'équipe, pas seulement le développeur front-end principal ou les développeurs plus expérimentés
Kirby Yardley a travaillé sur la refactorisation du système de conception et CSS du Sundance Institute et a souligné l'importance d'établir règles internes et meilleures pratiques.
« Sans règles ni stratégie appropriées, CSS est un langage qui se prête à une mauvaise utilisation. Souvent, les développeurs écrivent des styles spécifiques à un composant sans réfléchir de manière critique à la façon dont ce code pourrait être réutilisé dans d'autres éléments (…) Après de nombreuses recherches et délibérations sur la façon 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 trivagol'établissement de règles et de directives internes s'est avéré être une étape importante pour leur processus de refactorisation.
« Nous avons introduit une bibliothèque de modèles. a commencé à utiliser atomic design dans notre flux de travail, a 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 comme Stylelint fournissent des règles utiles qui vous aideront à vérifier les erreurs et à appliquer les normes internes et les meilleures pratiques CSS courantes comme interdire les blocs de code CSS vides et les commentaires, interdire les sélecteurs en double, limiter les unités, définir la spécificité maximale du sélecteur et la profondeur d'imbrication, établir le modèle de nom du sélecteur, etc.
Conclusion
Avant de décider de proposer un refactoring granulaire de la base de code ou une réécriture CSS complète, nous devons comprendre les problèmes avec le base de code actuelle afin que nous puissions 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 la progression du refactoring.
Après avoir déterminé les objectifs et la portée du refactoring, il est important de définir des paramètres internes directives et meilleures pratiques pour la base de code CSS – convention de nommage, 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ée pour l'intégration et CSS revue de code. L'utilisation d'outils de linting comme Stylelint peut aider à appliquer certaines meilleures 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 garantit une transition transparente entre la base de code actuelle et la base de code refactorisée.
Références
(vf, il)Source link