mercredi 16 juin 2010

Pourquoi je déteste Drupal (et la plupart des autres CMS)

Voilà quelque temps que je me retrouve régulièrement empêtré dans des débats stériles concernant les CMS (système de gestion de contenus prêt-à-l'emploi) en PHP, et particulièrement Drupal, auquel j'ai été confronté lors de missions chez différents clients, et dont la popularité le désigne tout naturellement comme bouc-émissaire de premier choix pour traiter du mirage que sont les promesses des CMS.

Je vais donc tenter dans ce post de résumer les raisons objectives pour lesquelles je n'accepte plus de travailler sur des projets basés sur cet environnement. Bien sûr la liste n'est pas exhaustive, mais les problèmes qu'elle pointe sont tels qu'il ne devrait pas être nécessaire d'en ajouter plus. Ces observations sont issues de l'expérience, et dénoncent des défauts qui handicapent réellement les projets. Il faut les prendre pour ce qu'ils sont, à savoir une mise en garde.

Voici donc les reproches que je peux adresser à Drupal, même si encore une fois ils pourraient s'appliquer à l'essentiel des autres CMS disponibles à l'heure actuelle :
  1. L'approche procédurale

    Les CMS s'adressent principalement à un public de non-développeurs ; autrement dit, au grand public. Celui-ci ayant quasi systématiquement recours aux hébergements mutualisés, lesquels ont très longtemps (et continuent pour certains !) imposé PHP4 à leurs clients, les CMS ont dû se plier à cette contrainte et maintenir une compatibilité totale avec cette version désormais obsolète de PHP, sur laquelle beaucoup ont en plus été conçus, sans que leur design initial n'ait jamais été remis en cause.

    Ceci semble avoir parfaitement satisfait les développeurs de Drupal (ainsi que ceux de sa communauté), qui sont dans l'ensemble très fâchés avec le développement objet. Songez que l'un des seuls objets core de Drupal est le node (concept absolument central de Drupal), qui n'est autre qu'une bête StdClass !

    Je suis même tombé (merci Alex !) sur un article d'un évangéliste Drupal qui nous explique avec le plus grand sérieux que l'absence de classes dans le design de Drupal est un choix délibéré, mais que cela n'empêche pas Drupal d'appliquer la majorité des concepts du paradigme objet. Encore plus savoureux, il nous est exposé la thèse suivante : en se gardant d'utiliser les objets, il a été possible aux développeurs Drupal d'implémenter des concepts "encore plus objet" que ce que permet le moteur orienté objet de PHP ! Ca me fait penser à ceux des artistes contemporains qui mettent trente secondes à créer une "oeuvre", puis des années à en théoriser le concept, mais c'est une autre histoire... Bref, pour consulter ce chef-d'oeuvre de mauvaise foi, c'est par là !

    Nous pouvons donc constater que ces développeurs sont adeptes de ce que PHP a de plus médiocre à offrir, du fait d'une utilisation sans discernement de sa permissivité, au mépris de toute bonne pratique. Je pense ici notamment à ces fameuses variables globales, à commencer par $user (dont je vous laisse deviner ce qu'elle matérialise...), ainsi qu'au recours à eval(), le honni (encore présent dans Drupal 7, j'ai vérifié) !

    On se retrouve donc confronté à une base de code foisonnant de fonctions par milliers, très fermement couplées entre elles (puisqu'impossibles à redéfinir, naturellement), limitant de fait les personnalisations possibles. Ceci à conduit à la mise au point dans Drupal d'un système de module qui a paradoxalement fait sa renommée. Mais j'y reviendrai dans le point suivant.
  2. Une modularité très discutable
  3. Drupal offre à ses utilisateurs un aréopage de modules hétéroclites, et surtout très souvent en conflit les uns avec les autres. S'il est juste de dire que des modules existent pour couvrir fonctionnellement de très nombreux besoins concrets, il faut toutefois relativiser la soit disant valeur-ajoutée de cette manne :
    • le foisonnement en est tel qu'il est souvent long et difficile de sélectionner le plus approprié (étrangement, la communauté préfère réaliser deux modules disposant chacun de 3 fonctionnalités plutôt qu'un seul doté des 6...)

    • cette vilaine manie qu'ont les développeurs de recourir aux patches pour appliquer leurs modules vous amène très vite à casser toute compatibilité descendante avec les futures versions du CMS, ainsi qu'avec certains autres modules.

    • le recours à l'appel "à l'aveugle" de fonctions via call_user_func(), dans le contexte du mécanisme de hooks, est une plaie du point de vue des performances d'une part (au moins jusqu'à PHP 5.3, dont je ne suis pas certain de la compatibilité avec Drupal par ailleurs), mais aussi et surtout pour la compréhension du flux d'exécution ! C'est bien simple, on n'y comprend rien (point de vue confirmé par d'honnêtes Drupal fan boys...)
  4. Un emploi déraisonnable de la base de données

    Dans Drupal, tout ou presque se passe dans la base de données. Outre que ceci est parfaitement imbécile là encore du point de vue des performances (j'ai souvent vu des pages de sites Drupal nécessiter de 400 à 1000 requêtes SQL pour être générées, le cache n'arrangeant que peu les choses, sans compter les modules qui parfois produisent des requêtes de plusieurs dizaines de secondes), c'est absolument cataclysmique pour les tests (unitaires ou pas), la gestion des versions et des mises en production.

    En effet, les modifications que l'on apporte à un projet sous Drupal sont partagées entre le code et la base de données. Autrement dit, pour tester ce que l'on a fait localement sur un serveur de recette par exemple, il faut synchroniser les bases de données, ce qui n'est pas chose aisée. Bien sûr, cela sera également nécessaire pour que les autres collaborateurs du projet puissent appliquer vos modifications sur leurs environnements locaux. Et une fois de plus sur la production. Et procéder à l'opération inverse pour revenir en arrière, le tout en parfait accord avec le versionning SVN/GIT. Mission quasi impossible.

    Moralité, les développeurs travaillent sur des versions qui ne sont pas identiques, ce qui se révèle être une source intarissable de bugs les plus idiots qui soient.

Conclusion

J'en aurais encore beaucoup à dire sur le sujet, mais je préfère partir du principe que si nous ne sommes pas d'accord à ce stade, nous ne le serons jamais, et inversement !

Je finirai donc en rappelant simplement une fois de plus que les CMS sont conçus uniquement pour un public de non-développeurs, et qu'il ne faut pas y recourir si l'on à la moindre velléité de personnalisation (essayer d'intégrer un véritable workflow à Drupal, on en reparlera...).

Dans le cas contraire, c'est-à-dire dans tous les projets que l'on peut avoir à gérer dans un contexte professionnel (hors "web agencies de quartier" s'entend), ces CMS sont à proscrire. Ils ne sont pas faits pour vous, même si le succès rencontré auprès d'une foule d'amateurs et de quelques professionnels désoeuvrés leur a laissé croire le contraire.

Pour un développement sur la base d'un cahier des charges précis, utilisez des frameworks, c'est-à-dire des environnements maîtrisés de bout en bout, lesquels vous fourniront le cadre nécessaire pour écrire un code métier efficace et maintenable, les outils nécessaires à la mise en place d'un véritable cycle de développement, plutôt que l'illusion de vous fournir un code métier "clés en main" (ce qui est, convenons-en, proprement absurde !).

vendredi 11 juin 2010

Forum PHP 2010 : Appel à conférenciers !

En attendant un contenu propre qui reste en perpétuelle préparation, je me devais de le relayer ce communiqué de presse de l'AFUP, qui enjoint tous les experts PHP de la planète (non, je n'exagère pas :)) à soumettre des sujets de conférence pour le prochain Forum PHP, qui se tiendra le 9 et 10 Novembre 2010 à la Cité de Sciences de La Villette (Paris).

Voici le texte intégral, que vous pourrez également retrouver sur : http://afup.org/pages/site/?route=actualites/412/experts-php-participez-au-forum-php-2010






Experts PHP : participez au Forum PHP 2010 !


A l'occasion de cet anniversaire, l'Association Française des Utilisateurs de PHP organise un Forum plus ambitieux que jamais, prévoyant de nombreuses conférences et débats, ainsi qu'un espace d'exposition pour les équipes de projets libres souhaitant venir à la rencontre d'un public de professionnels (développeurs, décideurs, presse...).


Vous êtes expert sur un domaine, vous avez installé une ou plusieurs applications PHP (CMS, e-commerce, CRM, GED) dans un contexte spécifique (forte charge, client reconnu, projet innovant) ou bien vous participez à un projet Open Source lié à PHP, venez partager votre expérience !


Pour l'édition 2010, les thèmes particulièrement mis en lumière seront les suivants :


* PHP de A à Z : Débuter en PHP, Réussir un projet avec PHP, Choisir son hébergement


* Outils basés sur PHP : CMS et CMF, outils de e-commerce et de business, paiement en ligne, CRM et ERP


* Industrialisation de PHP : Performances, tests, authentification centralisée, frameworks


* Technologies autour de PHP (Javascript, HTML 5, microformats)


Pour soumettre votre sujet de conférence, rendez-vous surhttp://afup.org/pages/forumphp2010/appel-a-conferenciers.php et complétez une demande en ligne avant le 30 Juin 2010.


Vous souhaitez traiter un autre thème ? Vous n'avez pas d'expérience en tant que conférencier ? Vous souhaitez des renseignements sur la logistique que nécessite votre participation au Forum ?


Contactez Sarah sur organisation@afup.org