Nettoyer une base de code CSS

Vous venez d'être intégré à un projet existant pour remplacer un développeur sorti. Ou peut-être que vous venez d'ouvrir votre ancien projet d'il y a quelques années. Vous êtes confronté à l'effroi et à l'horreur lorsque vous regardez le code. Vous ne pouvez faire qu'une seule chose: nettoyez ce gâchis! Cela vous semble-t-il familier? Bien sûr, nous le rencontrons tous à un moment ou à l'autre.

Vous savez que le nettoyage d'une base de code CSS sera une tâche formidable. Il y a tellement de choses à faire, mais si peu de temps - surtout lorsque le client / patron / collègue préconise le bon vieux "" Ne corrigez pas ce qui n'est pas cassé ". Vous ne savez pas vraiment par où commencer!

Eh bien, vous avez de la chance parce que j'ai fait ma part de nettoyages CSS et je suis ici pour vous donner quelques conseils pour commencer avec cela. Il s'agit de saisir les fruits suspendus.

Les plats clés

• Ligner une base de code CSS est la première étape vers la nettoyage, car elle identifie les erreurs potentielles et les mauvaises pratiques. Des outils comme SCSS-lint peuvent être utilisés pour vérifier les erreurs du dossier SASS.
• La correction des erreurs de liaison peut être effectuée en parcourant les fichiers un par un et en mettant à jour ce qui semble mal, ou en utilisant des fonctions de recherche et de remplacement pour corriger les problèmes courants.
• La révision de la structure de la base de code est cruciale. Peu importe quelle méthodologie est choisie, tant qu'elle est respectée. Cela pourrait impliquer la restructuration du code pour se conformer à une méthodologie choisie, ou identifier des morceaux d'interface réutilisables et extraire leurs styles dans leurs propres partiels.
• La suppression du code excédentaire est la clé d'un bon CSS. Les déclarations inutilisées peuvent accumuler des dettes techniques, il est donc important de vérifier régulièrement si chaque déclaration CSS a un impact et, sinon, les supprimer.
• commettre régulièrement du travail et regrouper logiquement les changements dans les petits validations facilitent le retour de l'histoire en cas de problème. Ceci est particulièrement important lors de la refactorisation d'une base de code CSS, car il est probable que certaines choses se casseront en cours de route.

peluchez l'enfer

Dans cette section, je suppose que votre base de code utilise SASS. Non seulement parce que c'est une hypothèse raisonnable de nos jours, mais aussi parce que j'ai remarqué que la mauvaise utilisation du SASS est souvent partiellement responsable d'une base de code désordonnée. Pourtant, cet article peut être pertinent pour vous même si vous n'utilisez pas de préprocesseur, alors restez avec moi s'il vous plaît.

La première chose que j'aime faire quand j'ai besoin de reprendre une base de code est la peluche. La liaison est le processus d'exécution d'un programme qui recherche des erreurs potentielles et des mauvaises pratiques. Je crois que rendre le code propre est la première étape vers la bonne bonne étape. Voici un fil de débordement de pile perspicace sur l'étymologie du mot «peluche».

Sass a un linter basé sur Ruby appelé SCSS-lint. Vous pouvez le configurer vous-même ou saisir le fichier de configuration recommandé à partir de Sass-Guidelines pour commencer immédiatement. Il existe également une version Node.js appelée Sass-lint, bien qu'elles ne soient pas 100% interopérables, donc votre kilométrage peut varier.

Essayez d'exécuter SCSS-lint sur votre dossier SASS pour vérifier les erreurs. Les chances sont élevées que vous soyez submergé par un mur d'erreurs. C'est généralement le moment où vous serez tenté d'abandonner. Mais gardez avec moi! À ce stade, vous pouvez soit essayer de rendre votre fichier de liaison un peu moins strict en ce qui concerne les règles qui ne vous soucient pas vraiment (comme le format de couleur), soit vous attaquer à la bête à l'avant et à fouiller!

Fixation des erreurs de liaison trouvées

Il est temps de corriger ce qui doit être corrigé. Il y a deux façons de faire cela. La première consiste à passer par les fichiers un par un et à mettre à jour ce qui semble mal et / ou étrange, tel que des conventions de dénomination mauvaises, des sélecteurs trop profonds, un code mal formaté, etc. Le second (et mon préféré) est de commencer avec un peu de recherche et de remplacement. Je ne sais pas pour vous mais j'aime les expressions régulières, donc c'est toujours assez amusant quand je dois le faire.

Par exemple, disons que vous souhaitez ajouter le zéro de tête manquant devant tous les nombres à virgule flottante (c'est-à-dire une valeur numérique comprise entre 0 et 1) - la règle Leadzero de SCSS-lint. Vous pouvez rechercher les s. (D) (tous les nombres suivant un espace et un point) et le remplacer par 0. 1 $ (un espace, un zéro, un point et le numéro trouvé). Ou si vous voulez honorer la règle Borderzero pour SCSS-lint, vous pouvez remplacer la bordure: Aucune par Border: 0 dans votre IDE. Simple comme tarte!

J'ai récemment commencé le référentiel SCSS-lint-regex sur GitHub pour rassembler ces expressions régulières en un seul endroit. Assurez-vous de jeter un coup d'œil si vous avez du mal à lier un grand projet. Méfiez-vous également de la recherche et remplacez car il a parfois des effets secondaires inattendus. Après chaque remplacement, assurez-vous d'effectuer un diff git pour vérifier ce qui a été mis à jour afin que vous puissiez vous assurer que vous n'avez pas introduit de bug.

Une fois que vous avez terminé avec l'édition transversale, vous n'échapperez pas au fichier manuel rampant pour nettoyer tout ce qui doit être nettoyé (mauvaise indentation, lignes manquantes ou supplémentaires, espaces manquants, etc.). Cela prend beaucoup de temps, mais cela aidera beaucoup pour la prochaine étape, il est donc important de commencer par ça.

réviser la structure

Ce que je trouve souvent dérangeant lorsque je suis à bord d'un projet existant, c'est l'absence d'architecture de projet appropriée. Il y en avait probablement un au tout début, mais les choses deviennent généralement incontrôlables et cette brève idée de la méthodologie s'est perdue quelque part le long de la ligne. Pourtant, c'est incroyablement important.

peu importe la méthodologie que vous choisissez tant que vous vous sentez à l'aise avec elle et que vous vous y tenez. Ce pourrait être SMACSS, il pourrait être 7-1, il pourrait être ITCSS - faites votre choix! Essayez ensuite de restructurer les choses pour rendre le code conforme à la méthodologie choisie. J'utilise principalement le modèle 7-1 introduit dans les directives SASS, donc je vais vous donner quelques conseils pour améliorer les choses si vous décidez d'aller de cette façon.

Commencez par le dossier vendeur car c'est celui qui ne posait aucune question. Déplacez toute bibliothèque tierce non emballée dedans (c'est-à-dire toute bibliothèque non traitée comme une dépendance régulière via NPM ou Bundler).

Ensuite, passez au dossier Abstracts . Assurez-vous que toutes les variables, mélanges, fonctions et espaces réservées du projet y sont définies. N'hésitez pas à l'organiser comme vous le souhaitez ici tant que vous ne vous retrouvez pas avec des variables et des mixins dans tous les fichiers de la base de code. J'ai également tendance à rechercher des variables (et des mélanges) inutiles à ce moment-là. En effet, je trouve souvent d'innombrables variables qui sont utilisées une ou deux fois seulement (en d'autres termes, cela ne vaut pas la peine).

Une fois que vous en avez terminé, c'est votre appel. Vous pouvez soit essayer de vous assurer que tout dans le dossier base est en fait des trucs de base et non liés aux composants, ou vous pourriez jeter un œil au dossier Layout pour vérifier si tout concernant le La mise en page globale y vit et est correctement documentée.

Enfin, vous devrez vous attaquer aux composants qui est probablement une tâche colossale. Mon conseil ici serait d'essayer de rendre les composants aussi petits et réutilisables que possible. Peu importe que vous doublez le nombre, tant que vous pouvez les rendre au contexte agnostique et facile à lire, à comprendre et à mettre à jour.

Par exemple, ce n'est pas une mauvaise chose d'avoir un composant aussi petit que ceci:

<span><span>.quote</span> {
</span>  <span>padding: 10px;
</span><span>}
</span>
<span><span>.quote__attribution</span> {
</span>  <span>font-size: 80%;
</span><span>}
</span>
<span><span>.quote > :first-child</span> {
</span>  <span>margin-top: 0;
</span><span>}
</span>
<span><span>.quote > :last-child</span> {
</span>  <span>margin-bottom: 0;
</span><span>}</span>

Pensez modulaire. Petit. Simple. Indépendant.

Retirez l'excès

Je crois que la plus grande différence entre le bon et le mauvais CSS est la quantité de code nécessaire pour le faire fonctionner ™. CSS en tant que langue est assez facile à saisir. Tout le monde pourrait faire à peu près toutes les dispositions avec un peu d'essais et d'erreurs. Cependant, être capable de construire quelque chose avec le strict minimum de CSS nécessaires pour le faire fonctionner, et pour le garder ainsi, est un vrai défi.

Cela fait plus de 3 ans, mais ce tweet de Nicolas Gallagher reste ma citation préférée sur CSS:

Dans le «mauvais» CSS, il est très difficile d'écrire le «bon» CSS. Dans le «bon» CSS, il est très facile de boulonner le «mauvais» CSS et de lancer le code pour rot.

- Nicolas (@necolas) 26 septembre 2012

L'obsolescence est la vraie peste du CSS. Lorsque nous construisons quelque chose avec CSS, nous allons souvent et essayons et essayons quelques choses - au point où nous nous retrouvons habituellement avec quelques déclarations inutiles. Par exemple, un débordement: caché qui est devenu inutile, ou une taille de police qui ne fait aucune différence. En les laissant, nous accumulons la dette technique. C'est mauvais ™.

Lorsque Écriture CSS, ce que j'aime faire juste avant de commettre un travail CSS, c'est d'ouvrir les outils du développeur, et de basculer chaque déclaration CSS que j'ai écrite pour voir si elles ont chacune un impact. S'ils ne le font pas, je me demande pourquoi ils sont là en premier lieu. S'ils se révèlent inutiles, je les retire. En faisant quelque chose d'aussi simple que ceci, je m'assure que seul le code sans indésirable utile est poussé vers le référentiel.

Le nettoyage Une base de code CSS n'est pas différente. Localisez un composant que vous souhaitez nettoyer, ouvrez les Devtools et essayez de trouver des déclarations inutiles. Parfois, pour éliminer certains CSS, nous devons déplacer certains styles supérieurs dans l'arbre pour bénéficier de la cascade. Considérez l'exemple suivant réduit à son strict minimum:

<span><span>.quote</span> {
</span>  <span>padding: 10px;
</span><span>}
</span>
<span><span>.quote__attribution</span> {
</span>  <span>font-size: 80%;
</span><span>}
</span>
<span><span>.quote > :first-child</span> {
</span>  <span>margin-top: 0;
</span><span>}
</span>
<span><span>.quote > :last-child</span> {
</span>  <span>margin-bottom: 0;
</span><span>}</span>

Une manière propre d'optimiser cela serait de déplacer la déclaration de couleur: rouge vers le parent et de laisser la cascade faire le reste. Bien sûr, les exemples de la vie réelle sont généralement plus complexes, mais cela montre comment nous oublions parfois de profiter du c dans * c * ss.

CSS est intelligent, vous devriez être trop

Une chose que je rencontre souvent est le manque de compréhension des valeurs héritées, initiales et actuelles. Dites que vous voulez que vos liens soient de la même couleur que le texte de base (car le soulignement est suffisant). Ce qui suit est un Bad façon de faire:

<span><span>.parent</span> {
</span>  <span>/* ...stuff here... */
</span><span>}
</span>
<span><span>.child-A</span> {
</span>  <span>color: red;
</span><span>}
</span>
<span><span>.child-B</span> {
</span>  <span>color: red;
</span><span>}</span>

La raison pour laquelle il s'agit d'une mauvaise solution devrait être évidente: si vous modifiez la couleur de la copie corporelle, la couleur du lien sera dés-synchronisée. Si vous songez à utiliser une variable, vous rendez les choses inutilement complexes. En plus de cela, si un lien se retrouve dans un paragraphe gris (à l'intérieur d'un blockquote par exemple), il ne correspondra pas à la couleur!

CSS a une façon intégrée de gérer cela, avec la valeur héritée.

<span>a {
</span>  <span>color: black; /* Nope */
</span><span>}</span>

C'est aussi simple que cela. Grâce à cela, les liens hériteront toujours de la couleur de leur parent. Qui pourrait également hériter de la couleur de ses ancêtres, etc.

Dans le même sens, lors de la réinitialisation d'une propriété à sa valeur par défaut, c'est une mauvaise idée de ladite valeur du code dur. CSS a la valeur magique initiale précisément pour un tel scénario. Bien que cela ne fasse généralement pas de différence, il y a des cas où cela compte vraiment, comme avec des propriétés basées sur la direction telles que le texte-alignement. Lors de la réinitialisation du texte-alignement, le réglage à gauche pourrait être dommageable pour les langues RTL; Initial serait la voie à suivre (ou même mieux, mais cette valeur n'a pas de support dans IE9).

Enfin, le nombre de développeurs CSS ne connaissant pas CurrentColor est trop élevé. Si vous ne le savez pas, ne vous sentez pas mal, mais demandez-vous ceci: comment est-ce que lorsque vous ne spécifiez pas de couleur de bordure, il correspond automatiquement à la couleur de l'élément? Eh bien, cela se produit parce que la valeur par défaut pour Border-Color est CurrentColor (vérifiez la spécification). Un nom tout à fait évident, vous concéderez.

Mon point est que si vous voulez quelque chose pour partager la couleur avec la police d'un élément, utilisez CurrentColor plutôt qu'une valeur codée dure ou une variable SASS.

<span><span>.quote</span> {
</span>  <span>padding: 10px;
</span><span>}
</span>
<span><span>.quote__attribution</span> {
</span>  <span>font-size: 80%;
</span><span>}
</span>
<span><span>.quote > :first-child</span> {
</span>  <span>margin-top: 0;
</span><span>}
</span>
<span><span>.quote > :last-child</span> {
</span>  <span>margin-bottom: 0;
</span><span>}</span>

Toutes ces choses sont des fonctionnalités CSS de base. C'est ce qui fait de CSS ce que c'est. Pourtant, ils sont incroyablement sous-utilisés. Donc, si vous devez améliorer le code d'un composant, ce sont les types d'améliorations que vous voudrez apporter.

Obtenez votre git bon

Refactorisation Une base de code CSS est beaucoup de travail. Vous êtes susceptible de mettre à jour des dizaines et des dizaines de fichiers. Vous êtes également susceptible de casser les choses en cours de route. Soyons honnêtes, nous faisons tous des erreurs, et lorsque vous traitons de ces changements aussi énormes, ce serait très impressionnant si vous réussissiez à tout nettoyer sans même un minuscule faux pas.

Pour cette raison, je vous recommande fortement de devenir très assidu avec votre contrôle de version (je pense qu'il est juste de supposer Git ici). Cela signifie que je vais faire une chose et une seule chose pour qu'il soit possible de revenir à une étape contenant un bug sans lutter comme un enfer avec des conflits.

Je sais que pour beaucoup de gens, Git est dur et obscur, et creuser dans la façon de le rendre simple est en dehors de la portée de cet article. Vous devez cependant me faire confiance: Faites de votre histoire Git un poème si vous ne voulez pas vous mettre en colère.

l'enveloppement

Assumons-nous et ayons un peu TL; DR pour les lecteurs paresseux:

Le nettoyage d'un projet CSS / SASS est difficile car il est difficile d'évaluer l'impact de la mise à jour ou de la suppression d'une ligne de CSS. C'est principalement parce que CSS est à peine testable. À cause de cela, vous devez être prudent.

Commencez par lier votre code pour qu'il devienne joli. Commencez par cela pour vous faciliter la vie plus tard. C'est également un bon moyen d'obtenir un précieux aperçu de l'état de la base de code sans risquer beaucoup (la réparation de la saleté syntaxique est peu susceptible de causer des problèmes).

Ensuite, assurez-vous que votre projet embrasse une méthodologie de structure. Peu importe lequel, tant que c'est bien fait. Si votre projet n'est pas vraiment orchestré en composants, ce serait une bonne occasion de commencer sur cette voie. Trouvez des morceaux d'interface réutilisables et extrayez leurs styles dans leurs propres partiels. N'hésitez pas à les documenter un peu pour que cela devienne plus facile et vous avez une sensation de progression.

Une fois que vous avez nettoyé le projet et mis tout au bon endroit, il est temps d'améliorer le CSS lui-même. Vérifiez si vous pouvez d'abord supprimer les choses; Nous écrivons souvent beaucoup trop de code. Essayez ensuite d'optimiser le code afin qu'il soit moins répétitif. Méfiez-vous de ne pas sur-ingénieur! Vous êtes censé supprimer la complexité, pas l'ajouter. N'hésitez pas à commenter tout ce que vous faites qui pourrait ne pas sembler évident au premier coup d'œil.

Enfin, engagez votre travail régulièrement et logiquement. Regroupez vos changements dans les petits engins en faisant une seule chose, il est donc simple de revenir dans l'histoire si quelque chose ne va pas.

En dernier, mais non le moindre, n'oubliez pas de célébrer lorsque vous avez terminé. Bonne chance!

Les questions fréquemment posées (FAQ) sur le nettoyage d'une base de code CSS

Quelle est l'importance de nettoyer une base de code CSS?

Le nettoyage d'une base de code CSS est crucial pour plusieurs raisons. Premièrement, il améliore la lisibilité du code, ce qui facilite la compréhension et le travail pour les autres développeurs. Deuxièmement, il améliore les performances du site Web ou de l'application à mesure que le code inutile ou redondant est supprimé. Cela peut entraîner des temps de chargement plus rapides et une meilleure expérience utilisateur. Enfin, une base de code propre est plus facile à maintenir et à déboguer, en gardant le temps et les ressources à long terme.

Comment puis-je identifier le code CSS redondant ou inutile?

Il existe plusieurs outils disponibles qui peuvent Aidez à identifier le code CSS inutilisé ou redondant. Il s'agit notamment des outils de développeur de navigateur, des outils de couverture CSS et divers services en ligne. De plus, l'examen du code manuel peut également être bénéfique, en particulier pour l'identification des redondances ou des incohérences dans le code.

Quelles sont les meilleures pratiques pour nettoyer une base de code CSS?

Quelques meilleures pratiques pour nettoyer le nettoyage Une base de code CSS comprend la suppression du code inutilisé ou redondant, l'organisation du code de manière logique et cohérente, en utilisant des commentaires pour expliquer les sections de code complexes et adhérer à un Convention de dénomination cohérente. De plus, l'utilisation d'un préprocesseur CSS peut vous aider pratiques. Cela comprend l'écriture de code modulaire et réutilisable, l'adhésion à une convention de dénomination cohérente et l'utilisation de commentaires pour expliquer des sections de code complexes. De plus, les avis réguliers de code peuvent aider à prendre des problèmes tôt avant de devenir plus importants.

Quel est le rôle d'un préprocesseur CSS dans le nettoyage d'une base de code CSS?

Un préprocesseur CSS peut grandement aider à Nettoyage d'une base de code CSS. Il permet l'utilisation de variables, de nidification, de mixins et d'autres fonctionnalités qui peuvent rendre le code plus lisible et maintenable. De plus, il peut aider à automatiser les tâches telles que la minification et l'autopréfixation, améliorant davantage la propreté et l'efficacité de la base de code.

Comment le nettoyage d'une base de code CSS améliore-t-il les performances du site Web?

Le nettoyage d'une base de code CSS peut améliorer les performances du site Web en réduisant la quantité de code qui doit être téléchargée et analysée par le navigateur. Cela peut conduire à des temps de chargement plus rapides et à une expérience utilisateur plus fluide. De plus, la suppression du code inutile ou redondant peut réduire la probabilité de conflits ou de bogues qui pourraient avoir un impact Impact SEO. Des temps de chargement plus rapides, qui peuvent être obtenus en réduisant la quantité de code inutile ou redondant, sont un facteur dans le classement des moteurs de recherche. De plus, une base de code propre et bien structurée peut faciliter les robots de moteur de recherche pour ramper et indexer le site.

Quels outils puis-je utiliser pour automatiser le processus de nettoyage d'une base de code CSS?

Il existe plusieurs outils disponibles qui peuvent automatiser le processus de nettoyage d'une base de code CSS. Il s'agit notamment des préprocesseurs CSS, des liners et des minifiants. De plus, il existe des services en ligne qui peuvent analyser votre base de code et identifier les domaines d'amélioration.

À quelle fréquence dois-je nettoyer ma base de code CSS?

La fréquence des nettoyages de base de code CSS peut dépendre de plusieurs facteurs , y compris la taille de la base de code, le nombre de développeurs qui y travaillent et la complexité du projet. Cependant, en règle générale, les revues et nettoyages de code réguliers devraient faire partie du processus de développement pour garantir que la base de code reste propre et maintenable.

Quels sont les défis dans le nettoyage d'une base de code CSS?

Le nettoyage d'une base de code CSS peut être une tâche complexe, en particulier pour les grandes bases de code héritées. Les défis peuvent inclure l'identification du code inutilisé ou redondant, le maintien de la compatibilité avec les navigateurs plus âgés et la garantie que les changements ne rompent pas les fonctionnalités existantes. De plus, cela peut prendre du temps, en particulier sans l'utilisation d'outils pour automatiser le processus.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!