S’il y a une chose particulièrement importante que vous devez savoir à propos de l’intégration, c’est qu’il s’agit avant tout de faire des choix. Tout le temps. Choisir la bonne balise, le bon nom de classe, la bonne méthode de positionnement, le bon framework, etc… En mai dernier, j’abordais déjà (maladroitement) ce sujet dans mon article sur les contraintes de l’intégration. Mais l’importance de nos choix en intégration m’est revenu à l’esprit à travers deux exemples.
A Paris Web, j’ai pu assister au très bon atelier de Jean-Pierre Vincent sur la performance sur les sites mobiles. Ce qui m’a marqué, c’est la dualité entre certaines bonnes pratiques. Par exemple, afin d’améliorer le temps de chargement de votre site, il est conseillé de diminuer le nombre de requêtes. Une bonne pratique consiste alors à privilégier l’emploi de propriétés CSS pour éviter d’utiliser des images pour des effets graphiques (bords arrondis, ombres, fond en dégradés). Sauf que l’utilisation de ces propriétés a un coût important sur le temps de rendu de la page une fois téléchargée côté client. En optimisant d’un côté, vous alourdissez de l’autre. Quel choix allez vous faire ?
Et puis la semaine dernière, il y a eu ce tweet de Raphaël Goetter : « WebPerf says : « id is the best CSS selector »; OOCSS says : « don’t use id ». Well.« . Si l’impact bénéfique sur la performance d’un id n’est plus vraiment d’actualité, son utilisation reste toujours sujet à débat. En utilisant des ids dans votre HTML, vous aurez potentiellement une page plus légère. Mais vous serez contraint d’alourdir vos sélecteurs CSS, en compliquant au passage la maintenabilité de votre code. Quel choix allez vous faire ?
Si certains choix vont être faits en réponse à des objectifs clairs de votre site, d’autres vont plutôt relever de votre personnalité d’intégrateur. En mai dernier, je résumais :
S’il est assez naturel de voir la personnalité d’un graphiste transparaître à travers ses créations, il en va de même pour un intégrateur. Mais contrairement à un graphiste, le travail de l’intégrateur est souvent invisible, et beaucoup plus difficile à juger.
L’intégration, c’est faire des choix. Mais souvent, il ne s’agit pas forcément de faire le meilleur choix, mais plutôt de faire le moins pire.
Nico, le
+1000 ! C’est pour cela entre autre que je dis régulièrement aux débutants de vraiment apprendre le plus qu’ils peuvent sur l’accessibilité, les perfs, la qualité, etc., afin de faire ces choix en toute connaissance de cause.
« Comment je dois intégrer ? » Mais avec soin et en faisant tes choix mon jeune padawan !
Et disons-le net, clouer le bec à une discussion/troll en avançant des arguments solides, ça invite au respect… et ça fait économiser du temps.
Remi Grumeau, le
C’est d’autant plus vrai avec les nouvelles notions de RWD et sa gestion des images. Faire les choix les moins pires devient malheureusement la norme…
Bartdude, le
Dans une plus grande structure, il me semble également important d’avoir certaines guidelines afin que chacun puisse s’y référer… ca permet d’avoir un résultat plus uniforme, et pas un patchwork des personnalités des différents intégrateurs se succédant sur un projet. C’est valable aussi en dev cela dit. Je lisais justement il y a quelques jours un article à ce sujet sur smashingmagazine : http://coding.smashingmagazine.com/2012/10/25/why-coding-style-matters/
Et si manifestement dans beaucoup de cas il n’y a pas un et un seul « best-practice », on peut cependant souvent pointer quelques « worst-practices », à bannir, eux…
Draeli, le
Le « moins pire » est effectivement devenu la norme pour les projets en environnement pro. et concilier toutes les contraintes est parfois compliqué surtout quand on a un client qui veut du site réactif, compatible, beau, modulable, ect … ; tous cela à bas prix et dans des délais « pour avant hier ».