Une des grosses différences entre l’intégration et le développement est la réusabilité d’un code. Là ou un développeur pourra faire appel à une bibliothèque pour résoudre son problème, un intégrateur devra souvent refaire le travail. Pourquoi ? Y a t’il une solution ?

Introduction

Prenons un exemple :

Nous avons un développeur et un intégrateur, pour un projet. Une fois le projet fini, ils en ont retiré argent, expérience, et dans le cas du développeur, un script de protection des uploads et un script de nettoyage des URL. Le web designer, lui, a décidé de garder le design de ses boutons, et un effet de survol en CSS3.

Projet suivant. Le développeur à de nouveau besoin du script de protection. Pas de problème, il suffit de l’appeler avec une ligne, et il en profite directement ! Bénéfice net : 4h.

Le web designer, lui va tout refaire dans le pire des cas ou va, dans le meilleur des cas, rouvrir son ancien projet, chercher laborieusement dans son CSS de 4200 lignes, pour finalement trouver son bouton. Il va pouvoir le copier et le coller dans son nouveau projet, enfin ! Mais le résultat obtenu ne sera pas tout à fait celui attendu : son css avait prévu que le bouton soit dans un <p> et pas dans une <div>. En plus, la classe utilisée pour son bouton (‘.left’), il l’avait réutilisé quelque part. S’en suit donc une grosse heure de modification laborieuse sur une portion de CSS pour que tout s’emboîte parfaitement.

Y a t’il une raison à ça ?

Vous allez me dire que c’est ici une caricature, que les choses ne sont jamais aussi graves. Cet exemple est effectivement un peu exagéré, mais pas de beaucoup. Une grande partie des webdesigners-intégrateurs ne s’inquiètent pas du tout de la réusabilité de leur code. Vous est-il souvent arrivé de vous dire ‘Je vais faire mes classes de tel façon, comme ça, je pourrais réutiliser ma portion de css’ ?

Alors qu’en développement, c’est une habitude. Il faut créer des codes avec la dépendance la plus faible possible, pour pouvoir les utiliser sans leur contexte, et éviter de se répéter la prochaine fois que l’on en aura besoin.

Ce n’est pas la faute des intégrateurs, ils ont été conditionnés comme ça par le CSS, qui n’aide vraiment pas à ne pas se répéter.

* Il n’est pas bon, d’un point de vue performances, de charger plusieurs CSS, on va donc essayer d’en faire un seul, 2 ou 3 maximum.

* @import, on en parle même pas, vu l’impact sur le chargement d’un site

* Même si on extrait dans un coin notre bouton, commentant bien au dessus et au dessous pour pouvoir le découper simplement, il faudra toujours remplacer les couleurs/marges qui doivent changer.

* De par la syntaxe même du CSS, si on doit modifier un élément conteneur (passer d’une div à un p), il faudra modifier toutes les lignes qui en dépendent.

Une solution en vue

Heureusement, Sass (ce qui est vrai aussi pour less et consorts) règlent une bonne part de ces problèmes.

La règle @import est grandement améliorée et nous pouvons utiliser des variables. Il serait donc possible, maintenant, de bien découper son bouton dans un fichier « lib/buttons/_my_top_button.sass », de prévoir des variables pour les choses personnalisables, et donc, au lieu du parcours du combattant présenté plus haut, de simplement faire @import « lib/buttons/my_top_button ».

Le gain de temps est énorme ! Mais peu le font, encore. Pourquoi ? Car les anciennes habitudes sont tenaces.

Gagner du temps en arrêtant les copiés collés.

Voilà quelques conseils qui pourront changer bien des choses :

Passer à Sass/less/…

Sass fait peur. Sass est nouveau, et beaucoup pensent que c’est un langage à apprendre. C’est juste du css avec des contraintes différentes et plein d’outils supplémentaires, c’est tout ! Et dans le pire des cas, passez à Scss. La même syntaxe/structure que le css standard, juste des outils en plus.

Apprenez à découper

Vous avez un bouton à faire ? Et bien créez un fichier _button.sass, et faites le dedans. Ensuite, importez le. Oui, il faut créer un fichier, c’est moins pratique sur le moment, on perd un tout petit peu de temps. Mais quand vous en aurez besoin de nouveau, ça sera un bonheur.  

Utilisez une nomenclature logique pour vos noms

L’important de tout ça est de gagner du temps, pas d’en perdre à devoir consulter la liste des fichiers que vous avez déjà créés. Donc choisissez une nomenclature qui vous plaise, qui soit logique pour vous et les gens avec qui vous travaillez, et tenez vous y. Comme ça, quand vous aurez besoins d’importer le format de header ‘large’, vous aurez pas besoin d’aller voir s’il s’appelle « header_large », « largeHeader », « LH », …

Utilisez des variables, et choisissez bien leur noms.

Si vous faite un bouton bleu, mettez une variable pour son background, comme ça, vous pourrez avoir un bouton rouge très simplement. Cette variable doit avoir un nom générique (comme $backgroundColor), qui colle avec votre nomenclature. Ne l’appelez pas $blue ! Sinon, pour votre logo rouge, vous aurez un $blue = #A00, et tout de suite, ça porte à confusion.

Utilisez plus de classes.

Les classes, c’est bien. Un élément HTML peut en avoir plein, et si chacune vient avec son petit lot de CSS, c’est plus simple à faire évoluer/modifier/réutiliser qu’une ID.

Utiliser le nesting(imbrication) avec discernement

L’imbrication permet de ne pas impacter le reste de son design, mais a tendance à lier un peu trop les différents éléments entre eux. Il faut donc l’utiliser, mais avec prudence.

Pensez DRY

DRY est l’acronyme de ‘dont repeat yourself’, ce qui veut dire ‘ne vous répétez pas’. Si vous gardez cela en tête quand vous prévoyez votre CSS/HTML, tout se passera pour le mieux.