Sous les Toits

Pour passer sur la plupart des navigateurs web, pour avoir un code lisible, clair et efficace, pour ne pas développer 12 fois les mêmes choses ou pour ne pas me retrouver le bec dans l’eau quand il faut changer l’aspect d’un site Internet, il y a quelques règles que j’essaye de respecter…
Dis moi comment tu codes, je te dirais qui tu es…
L’arrivée prochaine de quelques stagiaires sous mon aile me donne l’occasion de poster ce billet qui me trottait dans la tête depuis un petit moment…


Réfléchir avant d’agir
Avant de créer quelque chose, il est bon de savoir ce que l’on veut faire. Souvent, une idée met du temps à germer, à s’organiser, et je pense que c’est un moment important (et je ne suis pas le seul), peut-être même plus que le codage qui va suivre pour donner « vie » à l’idée. L’important, quand on commence (un projet, un objet, une simple fonction), c’est de savoir ce que l’on veut faire et de trouver le moyen le plus simple, le plus clair pour y arriver. « Où faut-il vérifier telle ou telle valeur de variable ? Si je la vérifie ici, je n’ai plus à le faire par la suite, si je la vérifie là, il faudra que je le refasse ici et là aussi… » Bref, l’optimisation du code se pense tout au long du développement, mais aussi et surtout, avant.

Optimiser le code
Avoir un peu conscience de la manière dont est interprété le code que l’on donne en pâture à la machine est une bonne chose. Ce n’est peut-être pas la peine de rentrer dans les détails, mais savoir par exemple qu’une commande PHP ou ASP dans une page HTML interroge l’interpréteur n’est pas inutile. Evidence me direz-vous, oui, c’est une évidence, et pourtant, dans combien de scripts ais-je vu ce genre de code :

<% maVariable=2 %>
<% print maVariable %>

Du coup, avec ce type de méthode, à chaque fois que l’on ferme les balises de script, on lâche l’interpréteur, qui est rappelé immédiatement à la ligne suivante. Pour optimiser ce code, ce n’est pourtant pas dur d’écrire

  <% maVariable=2
        print maVariable %>

De même, on préfèrera utiliser un « print » ou un « echo » quand on est au milieu du code, et on préfèrera lâcher l’interpréteur quand on envoi un peu plus de HTML qui ne soit pas clairsemé de langage serveur.

Garder un code propre
Travailler avec un outil WYSIWYG (What You See Is What You Get ; en Français ça veut dire utiliser un outil de mise en page graphique tel que FrontPage, DreamWeaver, etc.) est souvent très pratique, mais il ne faut pas en abuser. Il va permettre de saisir du texte au bon endroit sans passer 2h à farfouiller dans le code, mais en revanche, il risque de placer un tableau, ou un imbroglio intordable de conteneurs pour afficher bêtement quelque chose de simple. Le code devient vite illisible, et n’est quasiment plus maintenable qu’avec le même outil. C’est assez gênant. Ces outils ont aussi la fâcheuse tendance de réécrire votre code à leur façon. Ils suppriment les sauts de lignes soit disant inutiles, coupent les lignes là où bon leur semble, etc. Bref, là où il est si simple d’avoir un code propre et facile à entretenir, on se retrouve vite avec un machin incompréhensible…

Le respect des standards
Afin de passer correctement sur la plupart des navigateurs d’aujourd’hui, mais aussi sur ceux de demain, l’essentiel est de bien connaître les recommandations du W3C. Le W3C établit des normes de développement et valide les langages qui jalonnent le web (côté client). Les navigateurs commencent à respecter ces normes et ces langages. A terme, on peut espérer que tous les navigateurs tendront à respecter les standards du web du mieux qu’ils le peuvent. A ce moment là, un site qui respectera la syntaxe établie sera alors affiché de la même manière sur tous les navigateurs. Et le travail de développeur sera beaucoup plus simple (C’est beau de rêver…). Aujourd’hui déjà, de très gros progrès ont été faits et on arrive assez facilement à avoir un site qui s’affiche de manière très approchante sur la plupart des navigateurs. Le respect des standards, c’est donc avant tout les connaître (CSS 2, XML, HTML, XHTML). Ensuite, c’est aussi vérifier que l’on a pas écrit de grosse bourde dans ses pages. Pour ça, le W3C met des validateurs (XHTML, CSS2) à la disposition des développeurs. Les fichiers CSS changent peu une fois établis. Une des solutions consiste donc à vérifier qu’ils sont justes puis à utiliser un validateur de HTML comme Tidy (dont un plugin existe notamment pour FireFox) pour les pages. Ceci dit, attention, Tidy ne voit pas toujours tout, un petit passage par les validateurs du W3C de temps en temps est un impératif.

La séparation de la forme et du fond
Un site web et toujours conçu avec un contenu (ce que je dis) et un contenant (le graphisme). Souvent, il arrive que l’on ait envie de changer l’un sans toucher à l’autre. De temps en temps même, il ne s’agit pas d’une envie mais d’un impératif. Si les pages du site intègrent toutes le graphisme du site, il faudra les modifier toutes, ça va être long. En revanche, si la forme est bien séparée du fond, il suffira de changer quelques lignes ou quelques fichiers. Une telle technique n’est pas à négliger et ouvre de nombreuses perspectives. Il devient alors possible de changer le graphisme d’un site pour une occasion spéciale, pour un mois, pour un jour, ou pour une heure. Là, on est au summum de la réactivité. Pour séparer le design au sein d’un site, la base, ce sont les feuilles de styles (CSS), sur ce point, AlsaCréations est une excellente école et on peut jeter un oeil envieux sur CSS Zen Garden pour bien comprendre ce que séparation de la forme et du fond signifie.
Pour aller plus loin, diverses solutions s’offrent au développeur. La première qui vient à l’esprit, c’est le moteur de templates, je n’aime pas trop, ils sont souvent rigides, il faut apprendre à les manipuler et quid des mises à jour du moteur ? La seconde solution, c’est l’inclusion de fichiers, bien gérée, elle peut-être très pratique. Cette solution consiste à insérer quelques fichiers dans l’ensemble de vos pages, ces fichiers peuvent être un haut de page, un bas de page, un menu, etc. Ensuite, pour changer l’intégralité de l’aspect du site, il suffira de modifier ces quelques fichiers. Couplé avec l’utilisation de feuilles de style, c’est d’une efficacité redoutable. L’application d’une telle solution peut se faire de manière variées, inclusion brute des fichiers, emploi d’une fonction dédiée, etc.
A titre personnel, je préfère l’utilisation d’une fonction dédiée qui me permet de prévoir plus d’espaces inclus que ce dont j’ai besoin au moment de la création du site sans avoir à charger ensuite des fichiers vides (ce qui consomme des ressources inutilement). Cette solution a pourtant quelques limites. Notamment quand on veut créer de jolis cadres arrondis autour d’un texte. Le CSS ne le permet pas encore facilement et l’inclusion de fichiers dans ce cas précis devient un casse-tête à éviter…

La séparation des médias
Un site Internet n’est pas uniquement fait pour être consulté sur un écran, ben non… Il se doit de pouvoir être imprimé, écouté, éventuellement lu sur un PDA, etc. On touche ici à un point très important de l’accessibilité d’un site web. La séparation du code et du graphisme permet, via les CSS d’effectuer de telles prouesses. L’internaute, quand il imprime une page web n’a que faire de l’intégralité du menu sur lequel il ne peut plus cliquer, pas besoin non plus de le dépouiller de ses cartouches d’encre (vu leur prix) s’il cherche à imprimer un site contenant un texte blanc sur un fond noir. Non, le visiteur veut le texte, il le veut lisible et il le veut entier (beaucoup de sites aujourd’hui ne s’impriment pas convenablement sans passer par le mode paysage de l’imprimante, c’est déplorable). Pour ce faire, il suffit d’utiliser un fichier CSS par média, on peut alors gérer chaque type d’affichages.

En parlant d’accessibilité…
Quand on crée un site Internet, on souhaite en général qu’il soit vu par le plus grand nombre. Or, aujourd’hui, on s’aperçoit que beaucoup de personnes sont mises à l’écart parce que les développeurs ne pensent pas à eux. Il y a des foules d’exemples, les titres sous forme d’image (sans texte alternatif), les plugins sans solution de remplacements, le blocage de la taille des polices dans les textes, les petits scripts qui permettent de lancer une action dès que l’on a fait une sélection dans une liste déroulante, etc. Pour la liste déroulante, il faut savoir qu’un logiciel de lecture audio lit la liste… et se retrouve sur une autre page. Il suffit de mettre un bouton de validation et le tour est joué, le logiciel ne le validera pas tout seul. Ce sont toutes ces petites choses qui vont rendre la vie difficile à bon nombre de gens. Pas uniquement les déficients visuels d’ailleurs, mais peut-être aussi les visiteurs avec des navigateurs un peu exotiques, ou ceux qui ont désactivé certaines possibilité. Un bon moyen de vérifier que tout se passe bien et de jeter un oeil sur son site avec Lynx, ce qui peut donner un aperçu de la manière dont un site est vu par un moteur de recherche.

Tant qu’on y est, il est aussi un handicap que l’on tend à oublier aujourd’hui, c’est le 56k. « Ah ben je comprend qu’ils appellent ça un navigateur!! P’tain comme ça rame !!! », rien de nous empêche pourtant de développer un site léger, c’est tellement plus agréable.

Produire un code réutilisable
Ca coule de source (Argh ! Le mauvais jeu de mots), et pourtant… le pire des cas qu’il m’ait été donné de voir, c’est l’appel à une base de données, avec adresse serveur, nom d’utilisateur et mot de passe dans toutes les pages ! Si, c’est vrai ! Une véritable horreur ! Et c’était l’oeuvre d’une entreprise qui a vendu son site très cher… Le jour où j’ai voulu changer d’hébergeur, il m’a fallu beaucoup de patience…
Un développeur passe son temps à faire les mêmes choses, l’idée est toute simple, le développeur étant par nature un peu fainéant, développe une fonction (ou un objet) qui effectue la tâche requise et il va employer cette fonction dans toutes les pages où il en a besoin. Cela revient à scinder son code et c’est une excellente chose. Pour ce qui est de maintenir le code par la suite, il suffira de modifier quelques lignes pour que la fonction rétive soit corrigée dans l’ensemble du projet.
Cependant, attention aux travers. Il est très facile de se dire « je vais tout scinder en fonctions, ce sera mieux » et bien non, pas forcément… un code trop scindé devient un vrai bordel et on ne sait plus où donner de la tête.

Un code orienté objet
Pour aller plus loin, PHP (entre autres) permet aujourd’hui de travailler avec un code orienté objet. Un gros mot qui donne tout de suite une impression de « développeur fou ». Mais il n’en est rien, le principe est ma foi fort simple. Imaginons une application web pour gérer une classe d’école. On a un maître, des élèves, etc. Le développement objet consiste à créer un objet pour chaque élément. On aura un objet maître et un objet élève. Quand on veut modifier une propriété de l’un d’eux, il suffit de faire appel à cet objet et de donner la valeur souhaitée à la variable à modifier. Les objets (ou classes) acceptant des fonctions, il est ensuite possible de sauvegarder un objet, l’exporter, l’effacer, etc. Le développement objet permet de clarifier grandement le développement. On passe un peu de temps à créer la ou les classes correspondant à l’objet mais ensuite, c’est un véritable plaisir de les modifier en quelques lignes seulement.

Réinventer la roue ?
Il existe sur Internet de véritables banques de scripts, il n’est nul besoin de tout pondre soi-même. D’autres l’on peut-être fait avant, et pour peu que le code soit bon, cela permettra de gagner du temps. Par contre, il est rarement judicieux d’utiliser un script énorme truffé de possibilités si on a besoin que d’une infime partie…

Nommer juste
J’ai l’impression de ressasser des évidences dans ce billet…mais bon, soyons courageux, le ridicule ne tue pas.
Quand on commence un projet, il faut se projeter un peu dans le futur. Et ce, sur plusieurs plans, d’une part, au niveau du code. Il doit être propre et réutilisable par d’autres développeurs, donc les noms des fonctions, ceux des objets, des variables et autres constantes se doivent d’êtres uniques. Sur ce plan, j’aime bien la solution employée par l’équipe de Dotclear qui consiste à placer devant chaque entité un petit « dc_ ». De cette manière, si on reprend un bout de code de Dotclear, les variables ne viendront pas s’entremêler à celles existant déjà. Bien entendu, à l’intérieur des fonctions ou des objets, tant que les variables ne bavent pas au-delà du script (variables privées), on peut faire ce que l’on veut, on choisira donc des noms très clairs.

Le nommage est important au niveau du code, des noms de tables dans les bases de données, mais chose qui paraît peut-être moins évidente, il est aussi tout à fait essentiel dans les noms de fichiers. Notamment pour ceux qui seront accessibles directement au public. Dans ce cas là, il faut anticiper d’éventuelles évolutions, jusque dans les fonctions mêmes du site. Il faut garder en mémoire que chaque nom de page (donc chaque URL) est sujet au référencement, changer un nom de page, c’est perdre tout le bénéfice du référencement précédent. Cela peut-être souhaitable dans certains cas, mais tout a fait absurde dans la plupart des autres. Sans parler du désagrément causé à l’Internaute qui déboule tout frétillant sur une page « 404 non trouvé ». Il convient donc de bien penser le nom de son fichier (et des dossiers) dès le départ.

Sur le métier, 100 fois remets ton ouvrage…
C’est bien d’aller vite, mais c’est encore mieux d’aller propre, sachant qu’à terme, développer propre c’est aussi développer vite…

Je suis sûr que j’ai oublié une foule de trucs… A vos marques ? Prêts ?? Commentez !!