Comment refactoriser CSS - Un guide

La refactorisation CSS doit être une partie essentielle du flux de travail de développement frontal, si nous voulons avoir une base de code gérable et optimisée. Quand on refacture CSS, on nettoyer et réorganiser notre code existant sans ajouter de nouvelles fonctionnalités ou corriger des bugs.

La refactorisation aide empêche l'explosion de CSS, améliore la lisibilité et la réutilisabilité du code, et rend CSS plus élégant et plus rapide à exécuter.

Le refactoring est généralement nécessaire après un certain temps, car même les projets qui ont démarré avec une base de code concise et organisée tôt ou tard commencent à perdre de leur clarté. la cohérence, les règles obsolètes et les parties de code dupliquées apparaissent; et nous commençons également à remplacer les styles et à utiliser de plus en plus de hacks et de solutions de contournement.

Le meilleur moyen de maintenir notre base de code CSS maintenable est de rester fidèle à la “refactor tôt, refactor souvent” règle de base. Dans cet article, nous examinerons quelques astuces pour mener à bien un processus de refactoring CSS efficace..

1. Effectuer un audit initial

Pour avoir une meilleure idée de ce dont nous avons besoin pour le refactor, il est préférable de: commencer par un audit complet pour voir ce que nous avons actuellement.

Il existe de nombreux excellents outils en ligne qui peuvent nous aider dans cette entreprise. CSSDig est une puissante extension Chrome qui analyse le CSS d'un site Web et explore ses faiblesses, telles que des sélecteurs trop spécifiques ou des propriétés répétitives..

CSS non utilisé explore les règles CSS non utilisées, tandis que des outils de lintage, tels que CSS Lint, permettent de trouver rapidement des problèmes de compatibilité, de maintenabilité et d'autres problèmes..

Il est également important de contrôler manuellement le code lors de l'audit initial, car de nombreux problèmes d'architecture ne peuvent être résolus que de cette façon..

2. Mettre en place un plan gérable

Le refactoring du code de travail est toujours une tâche ardue, mais nous pouvons alléger le problème en créant un plan indiquant ce que nous devons faire, en découpant le processus de refactoring en morceaux gérables et en établissant un calendrier réaliste..

Dans le refactoring CSS, il y a une chose cruciale dont nous devons toujours tenir compte: certaines choses que nous refactorons, par exemple. changer les noms des sélecteurs, le rendra nécessaire d'ajuster le code des fichiers HTML et JavaScript pertinents ainsi que.

C'est donc une bonne idée de retracer en avant ces modifications supplémentaires que nous devrons effectuer, et les intégrer à notre calendrier de refactoring avec les tâches principales liées à CSS.

3. Suivre les progrès

Avant d’entreprendre la refactorisation, c’est une étape essentielle pour sauvegarder nos fichiers initiaux. L'introduction d'un système de contrôle de version, tel que Git ou Subversion, dans notre flux de travail peut également améliorer considérablement le processus de refactoring, car nous aurons un registre des étapes séquentielles que nous avons prises. sera en mesure de revenir à une étape précédente si nous voulons refaire les choses.

4. S'en tenir à un guide de style de codage

Un guide de style de codage cohérent peut améliorer considérablement la lisibilité et la maintenabilité du code. Il est donc essentiel, avant de commencer à refactoriser, mettre en place un guide de style de codage CSS.

Les points importants à prendre en compte sont:

• conventions de nommage
• règles de formatage
• ordre de déclaration
• unités et valeurs que nous voulons utiliser
• règles de commentaire

Si nous ne voulons pas créer notre propre guide de style de codage, nous pouvons également utiliser celui de quelqu'un d'autre, tel que ThinkUp qui peut être trouvé sur Github..

Il ne suffit pas cependant de présenter un guide de style de codage, nous devons également respectez-le quand nous réécrirons le code pendant la refactorisation, et attendre la même chose de tout le monde qui travaille sur notre projet.

5. Configurer une structure de fichier cohérente

Une fois que nous sommes prêts pour les préparatifs, la première chose à faire est de configurer une structure de fichier CSS appropriée qui prêtera attention à la nature en cascade de CSS..

La meilleure façon d’organiser nos fichiers dépend du projet. Toutefois, il existe certaines règles universelles, telles que l’utilisation d’un logiciel distinct. normaliser.css fichier pour les styles de réinitialisation CSS, un global.css pour les styles globaux utilisés dans l'ensemble du projet et pour stocker les bibliothèques tierces dans un dossier séparé.

Si nous voulons jouer en toute sécurité avec notre structure de fichiers CSS, il existe également des architectures toutes faites, telles que SMACSS ou ITCSS, qui offrent des techniques efficaces pour: comment organiser les fichiers CSS de manière évolutive.

6. Débarrassez-vous des règles inutilisées et en double

Après un certain temps, les fichiers CSS commencent généralement à être remplis de règles inutilisées que nous devons identifier et nettoyer lors du refactoring. Il existe de nombreux outils en ligne qui nous permettent de enquêter sur ces règles obsolètes, et parfois nous permettent également de les abandonner rapidement.

L’outil le plus connu à cet effet est probablement UnCSS, un module de Node.js qui permet de se débarrasser rapidement des règles CSS inutilisées. Il nous fournit également des options de configuration sophistiquées qui facilitent l’ajustement du processus de nettoyage..

Il est important de prendre en compte que nous ne veulent pas nécessairement supprimer les règles inutilisées de tout les fichiers CSS que nous avons, par exemple à partir de feuilles de style globales, de réinitialisation ou tierces, nous devons donc les exclure en effectuant le nettoyage.

En plus des règles obsolètes, les règles en double entraînent également une surcharge de code superflue et une perte de performance. Nous pouvons les supprimer en utilisant le module CSS Purge Node.js, mais nous pouvons aussi travailler avec CSS linters afin de rechercher des règles en double dans nos fichiers CSS.

7. Réduire la spécificité

La spécificité d'un sélecteur CSS est calculée à partir du nombre et des types de sélecteurs internes qu'il contient. La spécificité CSS est exprimée par un nombre à 4 chiffres qui est le plus facile à comprendre si nous consultons ce calculateur visuel de spécificités CSS:

La plus faible spécificité (0001) appartient à des sélecteurs qui ne ciblent qu'un seul élément HTML général, tel que

ou

. Plus un sélecteur composé contient de sélecteurs internes, plus sa spécificité est élevée..

Certains sélecteurs, tels que identifiant ou les sélecteurs issus de styles en ligne, ont des priorités plus élevées car ils remplacent les styles appartenant à des sélecteurs plus génériques. Par exemple, la spécificité du # id1 le sélecteur est 0100.

En refactorisation, l’objectif est de réduire autant que possible la spécificité des sélecteurs (gardez-les courts), les sélecteurs avec une spécificité plus élevée réduisent considérablement la réutilisation des sélecteurs, et conduire à une base de code gonflée.

Les 3 principaux types de sélecteurs de haute spécificité sont:

1. Sélecteurs qualifiés, tel que p.class1 (définissant le p balise est inutile ici, car il est impossible d'utiliser la même classe avec d'autres éléments HTML)
2. Sélecteurs profondément imbriqués, tel que .class1 .class2 .class3 .class4…
3. Identifiants, tel que # id1

Des outils en ligne, tels que CSSDig mentionné à l'étape 1, peuvent être utilisés pour trouver rapidement ces sélecteurs de haute spécificité. Il peut également être utile de définir une règle dans le guide de style de codage sur des éléments tels que le niveau maximum d’imbrication ou une limite d’utilisation identifiant sélecteurs.

8. désherber !important Règles

Règles CSS suivies par le !important déclaration remplace les règles de style habituelles. En utilisant !important règles tôt ou tard conduire à un code incohérent. Ce n'est pas une coïncidence si la plupart des outils lintillants les marquent comme des erreurs.

Lorsque nous devons écrire rapidement des CSS, nous pouvons commencer à les utiliser, mais à cause de leur simplicité..

Le problème principal avec !important déclarations est que si nous voulons les remplacer à l'avenir, nous devons mettre encore plus !important déclarations en cours d'utilisation, il est donc préférable de les supprimer chaque fois que cela est possible pendant le processus de refactoring.

9. Nettoyer les nombres magiques et les valeurs codées en dur

Au cours de notre flux de travail CSS quotidien, nous rencontrons parfois des problèmes que nous ne pouvons pas résoudre et nous commençons à utiliser ce que nous appelons nombres magiques, Des valeurs qui fonctionnent pour certaines raisons, mais nous ne comprenons pas pourquoi. Par exemple, prenons l'exemple suivant:

 .class1 position: absolute; en haut: 28px; à gauche: 15,5%; 

Le principal problème avec les nombres magiques est qu'ils sont circonstancié, et ils incarnent le “programmation par permutation” anti-modèle. Au cours du processus de refactoring, nous devons supprimer ces règles arbitraires de notre code et les remplacer par des solutions plus raisonnables chaque fois que cela est possible..

La même règle générale s'applique pour valeurs codées en dur ainsi que. L'occurrence la plus fréquente de valeurs codées en dur se trouve probablement dans les règles de hauteur de ligne:

 / * bad, nous devrons ajouter des règles de hauteur de ligne fixes supplémentaires aux éléments enfants de .class1 * / .class1 font-size: 20px; hauteur de ligne: 24px;  / * Bien, la règle de hauteur de ligne flexible peut également être utilisée en toute sécurité par les éléments enfants * / .class1 font-size: 20px; hauteur de ligne: 1,2; 

Les valeurs codées en dur rendent notre code moins évolutif et plus rigide. Par conséquent, dans le cadre de la refactorisation, nous devons les récupérer, et les remplacer par des valeurs flexibles.

10. Unités et valeurs de refactor

Pour faciliter la maintenance et le débogage à l'avenir, et éviter les défaillances pouvant résulter de l'utilisation de différentes unités, telles que em et px, simultanément, nous devons s'en tenir à des règles cohérentes sur la façon dont nous utilisons les valeurs relatives et absolues.

Si nous les avons utilisées de manière incohérente dans le passé, nous devons les convertir afin qu’elles puissent constituer un système concis.

Si nous utilisons trop de couleurs similaires sur notre site, il peut également être judicieux de rationaliser les couleurs en réduisant le nombre de couleurs que nous employons. (Voici un article sur la manière pratique de choisir un jeu de couleurs de site Web.)