Julien Pauli DevPHP blog

Un article de doctorrock    Pas de commentaires

Commençons ce billet par un contre exemple.
Je vous propose de visiter le site le plus affreux du monde, de tous points de vues.
En fait il fait quasiment tout le contraire des bonnes pratiques du métier de developpeur web, que je vais vous rappeler, regardez plutot http://www.hrodc.com/. Avouez que c’est quand même grandiose non ?
Le pire, c’est que beaucoup de sites de grands comptes ne respectent pas ces bonnes pratiques d’un web sémantique, clair, réfléchis, accessible, logique, sécurisé …
Et il n’est pas rare donc que des « grands » sites, entendez par là, à (très) fort traffic, ne respectent pas certaines règles, pourtant claires et logiques, faute de temps, de conscience des problèmes, de moyen, d’envie, de bon-sens …
On commence ?

1°) Utilisez la compression

De nos jours la plupart des serveurs, comme des clients, gèrent la compression du flux échangé. Pourquoi s’en priver ?
En php, ceci peut se faire de 2 manières simples différentes, soit via php_ini, soit via (ob_start(), en lui passant un gestionnaire de compression ‘ob_gzhandler’.
Le mod_deflate de Apache permet la même action.
Le poids des pages est ainsi fortement diminué, et si le client ne peut le décompresser, un flux non compressé lui sera envoyé lors de la négociation HTTP.
La compression des fichiers Javascript est aussi recommandée.

2°) Séparez vos couches, et vos langages

XHTML – Javascript et CSS doivent être séparés et non tous regroupés dans un fichier, même si votre IDE colorie chaque code de manière différente.
La séparation assure la maintenabilité du code, un developpement plus simple, mieux architecturé, et bien plus pratique lorsqu’une équipe bosse sur une même partie.
N’oubliez pas que sous Framework, et avec MVC, la page de résultat servie au client peut faire l’objet de dizaines de « raccords » de pages différentes.

3°) Utilisez un DocType, et validez le

Le web regorge de pages non valides, écrites dans un HTML très pauvre, vieux, et imposant un mode de rendu ‘quirks’ dans les navigateurs, synonyme d’interprétation hasardeuse par celui ci.
Utilisez un DocType adapté, mais respectez le ! Ne servez pas une page bâtie sur un modèle de Doctype, mais qui ne le respecte pas … Passez par un validateur et pensez au web sémantique ( chaque balise a un rôle précis ).
Usez d’outils tels que Firebug et gardez toujours une vue sur la qualité de votre code final.

4°) Utilisez un design web moderne

Les tableaux en présentation sont clairement à mettre au placard. Le CSS est à adopter au plus vite, quant aux logiciels tels que DreamWeaver, il faut les fuir, sauf à écrire un code correct dedans, mais ne pas leur laisser la main. Aucun logiciel de ce type n’est capable de remplacer un code main appuyé sur des connaissances pointues de l’intégration de contenu – métier à part entière – et gage d’accessibilité, de maintenabilité et d’évolutivité.
De plus, des tas de sites existent pour apprendre, developpez.com regorge de tutoriaux à ce sujet, et possède une communauté évoluée, compétente et réceptive.

5°) N’effrayez personne, ne vous exposez pas aux pirates, arretez d’afficher vos erreurs !

Si votre application est testée, ou pilotée par les tests, aucune erreur ne doit survenir.
Nul n’étant parfait, un serveur de production loggue les erreurs, alors qu’un serveur de développement(recette) les affiche. Arretez d’afficher vos erreurs à vos visiteurs qui s’en retrouveront déboussolés. De plus, ceci peut vous décrédibiliser, sans compter la sécurité, chaque information donnée à l’exterieur, sur le fonctionnement de votre application, peut entrainer des failles. Les cas classiques du mysql_error, mysql_timeout, ou de la transformation du type des variables d’entrée en tableaux, laissent souvent apparaitre des informations très intéressantes pour un pirate chevroné.
Vous devez attraper vos exceptions et servir le cas échant une « belle » page d’erreur à vos visiteurs, tout en logguant toutes les erreurs pour les servir aux developpeurs qui les analyseront et corrigeront les problèmes.
Ne laissez pas de commentaires dans votre XHTML de sortie en production, idem pour votre code métier ou applicatif coté serveur.

6°) Supportez tous les navigateurs modernes

Les jours des « sites compatibles IE », ou du 100% IE sont révolus définitivement. Il existe tout un tas de navigateurs sur le marché, sans compter les clients encore peu communs, mais amenés à se multiplier dans le futur ( pda, telephones, smartphones, consoles portables ou fixes …).
Vous servez un contenu pour la planète entière, pour tout le monde, vous pouvez avoir recours à des « hacks » ( hacks IE ), c’est tout à fait valable, tant qu’un effort au niveau du mode de rendu de certains clients (humm, j’ai cité personne) ne sera pas fait.
Sortez de votre esprit que vous envoyez un contenu à un internaute derrière son écran et son navigateur. Vous êtes plus généralement un serveur, qui sert un contenu à un client.

7°) Testez vos applications avec de VRAIS internautes

Un developpeur, un chef de projet, n’importe qui participant à un projet d’applicatif web, ne peut avoir un point de vue neutre sur sa propre application. C’est impossible, ne cherchez pas.
Navigation claire, moteur de recherche efficace, sécurité de l’application; des personnes extérieures doivent tester ceci pour vous.
Dans ce cadre, sortir un site en version ‘béta’ prend tout son sens.
Votre site vous plait ? Ah bon, vous l’avez fait pour vous ? Vous êtes son unique destinataire ?

8°) Si vous utilisez une technologie qui peut gêner l’internaute, spécifiez le lui

Javascript, Flash, cookies, plugins et activX sont autant d’élements qui peuvent ne pas être supportés, ou désactivés, chez vos clients ( Ce ne sont pas obligatoirement des navigateurs webs, sur des PC(MAC)).
Faites des vérifications, et avertissez vos visiteurs des composants techniques que vous utilisez, ne les laissez pas sur la paille, ils sont votre intérêt et la raison d’être de votre site. Idéalement, évitez de leur compliquer la vie. Presque 10% de la planète surfe sans Javascript, ou en désactivant les cookies; batissez le plus large possible, quitte ensuite à améliorer avec certaines technologies ( Javascript en particulier ).

9°) Utilisez de vraies bases de données, monitorées

Oubliez Access, ca n’est pas un vrai SGBDR. Si vous ne pouvez vous offrir Oracle ou SQLServer, des solutions gratuites existent comme Mysql ou Postgresql.
Le SGBD représente souvent un goulot d’étranglement dans les applications webs, ils nécessitent une attention particulière, et dédiée à un professionnel compétent dans le domaine.
Du coté applicatif, il est possible de profiler sa base de données, certains Frameworks le permettent, facilement, et à moindre cout.

10°) Compressez, pesez, pensez aux 56k restants dans le monde

Compressez, combinez, et cachez lorsque possible. Il reste une quantité non négligeable ( oui, j’ai dit non négligeable ), de connexions bas débits sur la planète, et quand on crée un site web, on le crée, au risque de me répéter, pour tout le monde. Par exemple, entre 15 et 20% des US sont en 56k ( j’ai pas de chiffres pour la France, désole ).
Les images doivent utiliser un format adéquat ( JPG ou PNG ), et être compréssées de manière pensée, et non pas laisser cette action à la charge du logiciel.
Prenez garde aux Frameworks Javascript, ils sont en général très lourds, et la page reste bloquée tant que celui ci n’est pas chargé à 100%.
Gardez à l’esprit que la plupart des navigateurs sont bloqués à 2 requêtes par serveur, une page pleine d’images, même légère, paraitra aussi lente au chargement, à cause de l’engorgement de la connexion

11°) N’utilisez pas de fonctionnalités propriétaires

ActiveX controls are the most evil things you can use. They lock you into a platform, and yet don’t work easily in IE7 anyway. Just say no. If you have to Flash is always a better choice since it is available to most people.

12°) Pensez accessibilité et internationalisation très tôt

Même si à la base votre projet ne concerne qu’un seule langue, pensez à l’internationalisation dès le départ. Car rajouter des langues dans un site ne l’ayant pas prévu peut s’avérer être une opération couteuse.
Coté accessibilité, n’oubliez pas les balises de type « accesskey ». Ne validez pas vos formulaires via javascript. Pensez que les CAPTCHA à base d’images ne peuvent être lus par les personnes à déficience visuelle

13°) Testez souvent, et commencez vos tests tôt

Les méthodes agiles incluent le Test Driven Developpement, qui consiste à écrire les tests avant même le code métier. Testez tôt, chaque méthode; puis faites des tests de groupe.
Testez tout, pas seulement l’application, mais la sécurité, l’affichage final sur différents navigateurs, l’infrastructure qui supporte l’application…
Ceci permet de péréniser votre application et votre developpement en général, en évitant la plupart des mauvaises surprises, et en accélerant les processus de developpement.
Même si un test est long à écrire ( surtout quand on est pas habitué ), il reste gage d’un gain de temps.

14°) Stoppez net les popups.

Tout est dans le titre. Remarquez même qu’en XHTML Strict, le paramètre « target=_blank » n’est pas valide. Avec les systèmes d’onglets maintenant largement répandus, ce n’est pas au developpeur d’imposer le choix d’ouvrir un lien dans une nouvelle fenêtre, mais bien à l’utilisateur final de faire ce choix s’il le désire.
Les popups sont pires encore, souvent bloquées par les filtres anti-popup, elles rendent le surf difficile. A la limite, les popups Javascript de type Web2.0 peuvent être tolérées. En fait il ne s’agit pas de popups à proprement parler, les pages s’ouvrent par dessus la page en cours, dans la même fenêtre.

15°) Jettez les Frames(cadres) à la poubelle

Les Frames dénaturent le web et gène son principe général : à une URL correspond une page. Un document contenu dans un ensemble de cadres perd cette identité propre pour endosser celle de son parent, de sorte que plusieurs documents viennent à être regroupés sous une seule adresse, rendant passablement difficile l’action de pointer vers un document spécifique.
Aussi on peut ajouter impossibilité d’ajouter aux favoris, Indexation par les moteurs de recherche difficile, imprécision de l’impression, aucune séparation entre structure et contenu, programmation d’externalisation de sources (les cadres permettent au développeur mal intentionné de faire afficher dans son site une information Web ne lui appartenant pas dans le but de se l’approprier), et pour terminer, ce concept est abandonné dans les normes Strict, et donc pour le futur.