28 fév 09 10 règles qui séparent un développeur d’un webmaster

Après une dure semaine coté outils et méthodes de développement, je me lance dans une liste dont j’assume le coté très subjectif et qui n’engage que moi : les 10 choses qui permettent de séparer un développeur, un vrai qui sent la sueur, d’un webmaster.

Cette liste s’entend pour un développement Web et PHP …

Programmation Orientée Objet

Sujet sensible, si l’en est … J’ai encore du mal à comprendre qu’en 2009 on développe en procédural ma bonne dame !

Utilisation d’un framework

J’ai fait mes études à {EPITECH} (pas taper), ou l’on commence sa première année à réinventer la roue : se redévelopper sa propre libc, de atoi() à malloc(). Je comprenais et appréciais le principe de disséquer tout ça pour mieux le comprendre plutôt que d’en apprendre le manuel et s’en contenter.

Et puis est venu le stage, et la je ne comprenais plus ! Mon directeur technique s’était bricolé une librairie PHP3/PHP4 sortie d’un espace intersidéral qui était censée gérer tout, du traitement des chaînes au transferts FTP ; ce mauvais reflexe m’a poursuivi longtemps …

Développer un site ou une application Web, c’est utiliser une base saine, donc un Framework, pour se concentrer sur ce que l’on crée, à quoi bon mal recoder une fonction qui protège les champs d’une requête SQL ? Des centaines de développeurs l’ont déjà bien fait pour vous !

Utilisation d’une architecture MVC

Un développeur qui ne respecte pas MVC :

Si on veut enlever ces liens du footer, je vais devoir modifier la fonction generate_footer()

L’équivalent chez son garagiste :

Sur que je peux vous changer la plaque d’immatriculation, mais je vais devoir démonter la boite de vitesse

L’avantage, c’est que ce point a de fortes chances d’être correlé avec le point précédent puis que la plupart des Framework PHP actuels se reposent sur une architecture MVC.

Définir des tests unitaires

Un développeur, un webmaster ou un boulanger ont une chose en commun : Ils ne sont pas infaillibles. Tout développement comporte forcément des bugs, c’est la loi de murphy.

Bien qu’aillant du mal à l’admettre, le développeur, le vrai, le poilu sait prévoir le fait qu’il oubliera ça et là de jolies erreur de conception, et il veut le savoir avant d’être montré du doigt ; il a donc inventé les tests unitaires.

PHP à donc aussi ses outils de tests unitaires, comme PHPUnit ou SimpleTest. A consommer sans modération !

Utiliser un cache

Même si certains le pensent, les ressources sont chères et il ne faut pas les gaspiller. Le but ultime de toute application Web reste quand même, dans une grande majorité de cas, d’être utilisée par le plus de monde possible. C’est donc automatique, plus votre site est consulté, plus vous aurez besoin de processeur et de mémoire, plus cela vous coutera cher.La meilleure et la plus simple des méthodes d’économie de ressources est l’utilisation de mémoire cache.

Tout résultat d’une requête SQL, tout résultat d’une fonction complexe (calculs, recherches, etc.) doit ammener une question simple : Est-ce que je ne peux pas mettre ça en cache ? Si oui, action !

Le cache le plus simple est d’écrire ce résultat dans un fichier, mais il reste des solutions plus optimisées et simple à déployer comme memcached, sharedance ou APC. Là aussi, les Frameworks vous rendent cette tâche encore plus simple qu’elle ne l’est.

Documenter son code

Le meilleur conseil que l’on puisse donner à un développeur est:

Always code as if the person who will maintain your code is a maniac serial killer knows where you live

Un des primodiaux pour ne pas vous faire éventrer par ce serial killer est de documenter ce code. Ce qui vous parait très clair aujourd’hui ne le sera plus du tout 3 jours ou 3 bières plus tard ; autant dire que cela ressemblera peut être à du bulgare pour un autre développeur 3 ans plus tard.

Et quitte à commenter votre code, autant bien le faire, en respectant une norme communément admise en PHP, j’ai nommé JavaDoc. Ce document est une bible, il est conseillé, sous peine de torture.

Factoriser son code

Ce point coule vraiment de source (mais rarement appliqué). Combien de fois suis-je tombé sur des projets ou la meme chose était codée dans 5 fonctions (et donc 5 fois avec des bugs, même souvent différents !) ?

Donc, vu qu’un développeur poilu code aussi en POO (oui, le premier point), factoriser son code c’est aussi utiliser de l’héritage de classe.

Concentrer la configuration

Toute configuration (j’entend par la des define(), des variables globales, meme si c’est très mal, ou toute variables que l’on peut modifier) doit être séparée du code et concentrer dans un fichier ou plusieurs fichiers dans un répertoire différent, la mettre en haut d’une classe est une absurdité !

De même, même si c’est aussi évident, ce fichier ou répertoire ne doit pas être consultable par les internautes (en dehors du htdocs).

Localiser son code

Personne ne sait de quoi demain sera fait, votre super site peut devenir demain un tel succès que des anglophones veuillent, eux aussi, profiter de cette merveille. Je pense qu’à ce jour, j’ai du assister à plus de 10 fois à un rush pour recoder tout un site en anglais.

Pour éviter ça, un reflexe simple, localiser son code, en utilisant des outils comme Gettext, XLIFF ou Qt Linguist. <radottage>Les frameworks actuels gèrent tous ça</radottage>

Réfléchir avant de coder

Ce point est très subjectif, je sais. Mais c’est un point essentiel du succès d’un développement. C’est très tentant de se jeter dans son éditeur, au début d’un projet, pour mettre les mains dans le camboui.

Résistez à la tentation et jetez sur papier ou sur UML votre réflexion … ca prend 10 minutes pour chaque classe et ca vous sauve souvent 2 heures de prise de tête !

Tags: code, php, social