Les développeurs devraient utiliser un concept appelé shame.css pour silo tout "hack" CSS dans les projets, selon Harry Roberts, développeur UI senior chez BSkyB.
Roberts a expliqué dans un article de blog que cela empêcherait potentiellement les développeurs de voir des hacks disséminés dans CSS et de penser ainsi que de telles choses sont acceptables par défaut.
De plus, l'article notait qu'une telle approche, si elle était correctement documentée et accompagnée des moyens d'itérer, pourrait permettre une progression plus rapide vers un CSS plus propre dans les projets où des hacks étaient utilisés (pour une raison quelconque).
.net a parlé à Roberts (HB) du piratage de CSS et des avantages potentiels que shame.css pourrait apporter s'il était correctement utilisé.
.net: Pensez-vous que certaines personnes de l'industrie ont tendance à être irréalistes quant à la nécessité (espérons-le) de piratages à court terme pour faire fonctionner un site?
HEURE: Temps fort. Si vous travaillez sur un site ou un produit qui rapporte des millions de livres par an, tout bogue, casse ou bizarrerie doit être corrigé dès que possible. Votre propriétaire de produit ne se soucie pas de savoir si votre CSS est parfait - il se soucie que le site soit opérationnel et qu'il tienne compte de ces revenus. Bon code est important, et les hacks sont loin d'être idéaux, mais penser que vous pouvez toujours empêcher les hacks et les solutions à court terme / rapides n'est pas un problème.
.net: Alors vous diriez qu'ils sont juste un mal nécessaire dans les affaires?
HEURE: Lorsqu'un client respire dans votre cou - ou qu'une fonctionnalité est interrompue sur un site en direct - vous devez vous assurer de garder les bonnes parties prenantes heureuses. Si vous passez une heure à écrire la solution parfaite pour quelque chose que vous auriez pu réparer superficiellement en deux minutes, je dirais que vous gardez la mauvaise personne heureuse - c'est-à-dire vous-même!
Dans mon propre travail, j'ai trouvé que le «besoin» de hacks augmente assez proportionnellement avec la taille du projet, mais la bonne chose à ce sujet est que vous aurez probablement plus de temps plus tard consacré au projet pour corriger ces hacks.
.net: C'est là que shame.css entre en jeu. Avec ce concept, que considérez-vous spécifiquement comme un hack CSS?
HEURE: Quelque chose qui aurait pu être mieux fait avec plus de temps. Il est difficile de penser à des exemples hors de leur contexte, mais je pense que vous saurez souvent quand quelque chose est un hack. Vous avez écrit quelque chose que vous auriez honte d'expliquer à un collègue? C'est probablement un hack!
Par conséquent, shame.css consiste à créer un fichier de choses que vous auriez pu faire mieux, et que vous pouvez faire mieux lorsque vous avez le temps de les revoir. C'est une liste de choses à faire que vous vous écrivez, en fait - un fichier de hacks que vous mettez de côté pour réfléchir lorsque vous avez plus de temps.
.net: Dans votre article, vous mentionnez la documentation des hacks, mais n'y a-t-il pas un argument que les développeurs devraient généralement documenter davantage CSS de toute façon, plutôt que juste pour les hacks?
HEURE: Oui! S'il y a une chose que tous les développeurs devraient faire plus, c'est d'écrire des commentaires. Vous devriez commenter tout ce qui n'est pas immédiatement évident à partir du code seul. Documentez votre code afin que, si vous êtes heurté par un bus sur le chemin du retour, votre collègue puisse prendre le relais le lendemain.
.net: En termes d'intégration de shame.css, que proposez-vous?
HEURE: Si vous utilisez un préprocesseur, @importer les honte. [scss | less | etc] classer juste à la fin, idéalement. (Cela peut toujours entraîner des problèmes de spécificité et de commande à la source, votre kilométrage peut donc varier.)
Si vous n'utilisez pas de préprocesseur, mais que vous avez un processus de construction décent, tous vos CSS doivent être concaténés et minifiés avant le déploiement, donc, encore une fois, shame.css peut s'accrocher à la fin de cela.
Si vous n'utilisez pas de préprocesseur et vous n'avez pas de processus de construction, alors un, vous devriez probablement le corriger, et deuxièmement, une section hacks à la fin de votre feuille de style est probablement votre meilleur pari. Shame.css n'est pas destiné à un affichage public, donc ne jamais avoir une feuille de style distincte appelée par un élément de lien dans votre balisage. Vous ne devez servir qu'une seule feuille de style concaténée et minifiée.
.net: Si shame.css en tant que concept décolle vraiment, comment pensez-vous que cela pourrait changer le processus de conception et les sites Web en général?
HEURE: Shame.css n'est aussi utile que les développeurs qui l'implémentent. C'est bien beau d'isoler et de documenter les hacks, mais si vous ne les corrigez jamais ou ne les revoyez jamais, vous êtes juste dans le même bateau qu'avant.
Pour moi, shame.css signale un changement plus large dans le développement; il n'a pas besoin d'être limité au CSS. Le concept consiste simplement à «réaliser, documenter et faire valoir vos hacks». Vous pouvez appliquer cette réflexion à tout.
Le vrai travail impliqué avec shame.css consiste à impliquer votre équipe immédiate (développeurs), puis à sensibiliser l'entreprise / les PM / les Scrum Masters / les BA / les Product Owner (et ainsi de suite) au fait qu'un produit en comprendra parfois moins. -que code idéal, mais que ce code existe pour répondre aux exigences de l'entreprise.
Dites-leur que vous isolez et documentez les hacks et que vous allouez du temps de développement pour ranger les choses. Il est plus facile de faire une analyse de rentabilisation pour ranger une base de code si vous pouvez la quantifier. Le simple fait de dire à votre chef de projet: «J'ai des choses à ranger avant de pouvoir passer à Feature X» ne résoudra pas toujours le problème! Apportez une liste de choses à votre PM et essayez d'obtenir une demi-journée de sprint pour passer le nettoyage.
L'idée derrière shame.css est simplement de rendre vos hacks plus transparents, quantifiables et isolés. C'est à vous de décider ce que vous faites de ces informations!
