blog
prenez des nouvelles de l’agence

Fatal Drupal - Hésitation (2/3)

Tranches de vie à température ambiante d’un mineur du code

Attention cet article n'est toujours pas un troll sur Drupal.

Billet nécessitant d'avoir lu le début de l'aventure à suspens accessible ici :
Fatal Drupal - Fascination et Tentation (1/3)


Hésitation
 

Alors que le précédent contexte nous avait transcendé, voila que que nous arrivions tout justement au côté obscur de cette belle expérience.
Vous savez celui moins agréable où l’horizon commence à s’assombrir et votre site en or à se changer en plomb...
 

La vraie vie

Du coup observons bien notre flambant sprinter en pleine lancée car nous remarquerons qu’il est sur le point d’attaquer le premier virage de la piste qui prend la forme d’un «léger» revirement fonctionnel (ou plutôt «précision» en terme client si l’on autorise ici les synonymes). Cette «précision» peut par exemple prendre la forme d’une histoire de comportement de formulaire un peu spécial (du type de ceux dynamico-ajaxifés avec effet de double-morphisme sessionnelle via interposition de combobox) ou bien encore d’une équation d’affichage pas vraiment banale pour un site multi-langues, celle du genre :
(((localisation + traduction - par-defaut-si-non-renseigné) / base-commune) % spécifique-par-moment) * règle-d’administration-breveté-hors-norme ^ je-sais-plus-quoi-inventer = tres-mauvais-bilan-carbonne-de-meninge
Mais la pour le coup, ces détails étant généralement laissés à l’initiative du client, j’inviterai fortement le lecteur à se reporter au Webcronomicon universel pour trouver des illustrations plus parlantes (ou juste de regarder à leur propre porte d’agence web qu’ils sont pour se remémorer ces moments croustillants à forte sueur froide ajoutée).
 
Plus sérieusement il s’agit bien ici de faire face à un phénomène «non balisé» sur aucune carte et «non anticipé» même dans nos rêves les plus fous de spécifications fonctionnelles.
Et la c'est le drame !
 

Plan A :  le ragoût de module

Enfin tout de même : ça serait bien le diable si armé de nos modules en tout genre, nous n’arrivions pas à franchir allègrement cet obstacle ridicule. 
Oui... MAIS... s’il y a une chance certaine «qu’il y ait un module pour ça», il y a surtout une très forte probabilité pour que votre prison dorée commence à vous rendre fou à cet instant précis du conte de fées.
 
Car oui les modules font tout, café noir et tartines compris et très souvent avec un goût de l’exhaustivité et du suivi (mais pas vraiment toujours hein ?). Mais ce coup-ci (et oui encore une fois en fait quand on y réfléchit bien), pas de chance le client vous demande du café au lait et des biscottes suédoises ! Alors ne rêvez pas, même en allant essayer de triturer les options de configuration du module «French Breakfast Node» vous n’arriverez pas à le rendre compatible avec «Swedish Taxonomy» qui n’en est qu’«au» stade de la version de développement et qui de toute façon n’est pas du tout prévu pour aller se marier avec autre chose que le Core. Et dire que le SI client vous interdit tout module en dev, alpha, beta ou RC parce que c’est «impensable»...
 
Et vous revoila à faire face à l’effroyable constat, après 3 jours passés à tenter l’impossible avec ce que vous aviez sous le coude ainsi que les sources communautaires lues et relues de haut en bas : ce sont les impasses totales (oui oui vous avez bien lu : vous en aviez bien pris plusieurs à la fois !!! Chapeau !)... à moins peut-être de développer votre module spécifique. Cela se fait bien de ré-inventer (ou re-tailler) la roue avec les «Framework PHP de bas niveau». Alors pourquoi pas en Drupal dans le fond ? S'ensuit alors l'interrogation des timings (ou oracles) de développement (plus que serrés, ca va sans dire) pour savoir si l’on peut se permettre de développer un module «International Breakfast» qui en plus de faire ce que l’on a besoin, allez soyons fou, pourrait passer le cap d’une sérieuse conception «tout terrain» en vue d’être soumis à la communauté. Réponse à 95% : non !
Argh ! Pourtant on aurait réellement aimé pour cette fois venir grossir la communauté car nous aussi on sait coder et on désire participer à cette grande aventure. Tristesse. 
 
Côté module, mis à part cet extravagant scénario catastrophe (mais quand même j’insiste, pour que ceux qui ne l’ont pas vécu plus d’une fois lèvent la main), il faut bien avouer que les versions du Core avancent dans le temps en fusionnant au passage tous les modules clés dont on ne pouvait se passer. Et je mettrai ma main à couper que les «Drupaleurs chevronnés» attendent avec impatience que les «Views» et autres «Webform» deviennent des capacités innées du Core, pour être encore plus percutants. (Motivation inside).
 

Plan B : le grand détournement

Et donc quand les pré-fabriqués ne suffisent plus, il faut alors passer en mode à l’ancienne et ressortir les outils de papi. Surtout qu'étrangement, des divers CMS «click & publish» à la mode du moment, Drupal est reconnu pour être celui le plus orienté technique et «codeman». Donc logiquement on se dit que ça va donner. Et puis d’ailleurs quoi : vous le voulez ou pas votre projet ? Alors on se bouge car c'est votre boulot après tout. Vous abandonnez peut-être la conception de module communautaire, mais ce n'est pas pour autant que vous abandonnez la guerre ! On vous reconnait bien la.
 
Mais vous voyez directement on va arrêter cette auto-motivation aveuglée. Pas la peine de s’emballer plus que ça en fait. Car une fois arrivé dans les obligations de mettre les mains dans le cambouis, pensez à dire au revoir à votre famille ! Si vous en revenez (ce que je vous souhaite quand même), vous ne serez de toute façon plus l(a)e même qu’avant.
Que les pro-Drupals ne crient pas au scandale si ça sent la mauvaise langue. Car certes on arrive à faire plein de choses (preuve en est la modulothèque gigantesque qui ne s’est assurément pas créée toute seule), et oui c’est super, mais reconnaissons le aussi : quand on vient d’une autre galaxie Framework, on n’a de cesse de rester ébloui et plutôt dubitatif devant la teneur globale de l’oeuvre. Faute peut-être à notre apprentissage «d’enfance» inculqué à grand coup de logiques carrées rabâchées et re-rabâchées ?
En fait, on se retrouve quelque peu désemparé face aux outils estampillés «Drupal» qu’on a sous le coude, et le moins qu’on puisse dire c’est que ca reste quand même un monde vraiment à part.
 
Sans avoir la présomption de dresser tout le paysage du moteur technique (API et concepts compris) voici les quelques facettes clés qui deviendront votre quotidien :
  • Node : ici tout sera noeud. Et le noeud tu dériveras... sous toutes ses formes (types de contenus). C’est l’endroit pivot de stockage du contenu.
  • Block : concept permettant de jouer aux Legos au travers de zones de contenus qui ont été volontairement rendues indépendantes.
  • Menu : par défaut la seule façon de regrouper vos noeuds au sein de liste. Notion malheureusement «limitante» car à vocation manuelle et donc très vite rejointe par le fameux module mastodonte «Views» qui dans toute sa puissance vous permettra de créer des URLs pouvant automatiquement remonter à l’affichage des noeuds (faire du SQL quoi). Attention cependant, Views, tout puissant qu’il est, pourra choquer un public non averti et deviendra le socle d'une micro-vie à l'intérieur même de Drupal. Un symbiote bien nommé quoi !  
  • Taxonomy : adorateurs du taggage structurant, la «Taxo» vous permettra de créer vos vocabulaires à tout va en vue de sur-qualifier tous vos noeuds et créer un terreau fertile pour moultes branchements de futurs modules qui vous font déjà cruellement défaut (ou pas).
  • Hooks : des crochets pour «prendre la main» à votre endroit en vous intercalant rapidement là où Drupal et module-consort auront décidé que cela vous serait possible. Du pur (Drup)altruisme qu'on vous disait !
  • Callbacks : pour aller plus loin que les «Hooks» quand ceux-ci ne suffiront plus à votre insatiable soif de tout contrôler.
  • Logique de Module : comme on l’a vu plus haut, c’est la principale porte d’entrée, en alliant Hook et Callback, pour étendre le Core avec vos fonctionnalités au travers de packages de code d'altération ou de création.
  • Logique de Thème et Suggestions : un peu dans la même veine que les modules, mais beaucoup plus axés sur les traitements d’affichage... mais pas que ! C’est mélange de systèmes de mise en forme via gabarit (au travers des chemins de Suggestions), de possibilités d’injection de Hooks et de fonctions de votre crue pour vous laisser exprimer toute cette créativité qui vous caractérise. Apprenez à les aimer, car cela sera votre principal terrain de jeu !
  • Des nomenclatures du Core quelques fois folkloriques, complexifiées dès lors que d’autres modules "indispensables" sont installés amenant leur «sous-API». Dans ce registre citons la Chaos Tool Suite (non non ce n’est pas une blague). Cependant un nom reste un nom, alors concentrez-vous plutôt derrière les concepts qu’ils amènent !
  • Une démonstration magistrale des adorateurs des fonctions, d’où ces nomenclatures un peu longue à digérer car ce n’est pas tout ça mais il faut bien distinguer tout ce petit monde à l'exécution. L’objet pointe le bout de son nez mais rassurez-vous : les fondations anciennes ont encore de beaux jours devant elles pour qu’une révolution fondamentale ne soit envisageable.
  • Logique extrême de variables tableau/objet surchargés qu’on se surprend parfois à essayer d’aller triturer dans des profondeurs abyssales de pointage sans fin.
  • Liaison avec la BDD laborieuse car au plus proche du SQL (ORM/relationnel vous nous manquez )
  • La documentation au globale est composée certes de la doc officielle (+doc API), mais est surtout énormément suppléée par des discutions articles/posts/forums... pour le meilleur mais aussi le pire avouons le. Car victime d’un certain succès l’effet de masse fait son oeuvre et de nombreuses discussions (parfois surréalistes), snippets (attention terrain miné), ou trolls étranges poussent de toutes parts. Cela au risque d’apporter un bruit réellement pénalisant autour des sésames techniques «one-shoot» qui pour le coup deviennent des denrées rares.
 
Mais maintenant que vous voila arrivé au pied du mur ou plutôt face à la partie submergée de l’iceberg, il ne vous reste plus qu’à commencer ce subtil jeu connu de beaucoup de codeurs Drupal, composé essentiellement de tentatives de détournements, de contournements, de retournements ou bien encore d’écoulements (pour les plus malheureux d’entre vous).
 
Pour le coup, tout ce blabla pour une petite conclusion : c’est après ce moment la qu’on saura si l’on a sauté l’obstacle ou pas.
Donc bonne chance évidemment pour ce plan B !
 

Travail collaboratif

Et qui dit passer aux choses sérieuses (fichiers codés, BDD un peu malmenée) dit aussi regarder ce qu'il se passe à côté de nos lignes de codes.
Et ca donne quoi si l’on se reporte au cycle de vie de la réalisation en cours ? Vous savez les histoires anodines du genre :
  • renforts techniques ou «développement à 4 mains»
  • problématiques entre l’environnement de «développement», et celui de «test client» où en général vous y invitez fortement votre commanditaires à saisir 1 ou 2 noeuds de contenus tests «presque vrais» qui ne contiendraient pas un seul «Lorem ipsum» (A 2 jours de la mise en ligne établie on commencerait presque à être en retard dites donc)
 
Et bien sur le sujet si l’on parlait plus haut de SVN (ou GIT) qui était de notre côté et qu’entre temps on avait pourtant accepté les compromis à faire pour les opérations d’update du Core ou des modules, il faut bien se rendre à l’évidence : le travail d’équipe en collaboratif stagne au stade de lueur d’espoir
 
Tout Drush, Features ou autre module de cette gamme qu’on puisse avoir de notre côté, le jongagle multi-environnements de travail qu’on doit pratiquer au quotidien de nos projets est malheureusement loin d’être vraiment réalisable si l’on compare à un développement Framework plus classique. On y perd alors sérieusement en efficacité sur plusieurs plans. D’autant plus quand on a la malchance d’être équipé en série par un module tiers qui ira nous faire quelques misères à ne pas être compatible avec les modules ou systèmes qui s’évertuent pourtant à proposer des solutions dans ce sens...
Le principal ennemi restant définitivement la problématique des configurations systèmes massivement injectées en DB via les options de configuration de l’UI du Backoffice. 
 
Alors si vous n’êtes pas tout seul à travailler sur votre projet, équipez-vous d’un crayon et d’un papier que vous intitulerez «DIFF» et notez-y le moindre changement de config réalisé en Backoffice. Car quand vous en aurez marre de jouer avec les Dumps SQL de vos collègues qui vidangeront vos moindres malheureuses données de tests nécessaires à votre partie du développement... vous verrez que le papier ce n’est pas si mal finalement.
 
 

Rien n’a servi de courir... 

Mais c’est déjà le moment de revenir sur notre impression initiale de sprint parfait. Finalement il serait temps d’ouvrir les yeux et de se rendre à l’évidence : un projet tient plus souvent du marathon et de la course d’obstacle de longue haleine que d'un petit 100m vite emballé !
 
Donc bien malin que nous sommes avec nos structures posées, et maintenant quasi-immuables, qui aboutissent à des amalgames très hermétiques aux maintenances profondes :
  • soit pour raisons techniques hors de notre portée (on ne de-structure pas impunément ce que Drupal a fondé à grand renfort de click).
  • soit à cause d’infos trop diluées entre des fichiers de code (10%) et des configurations en base de données (90%), avec en guest-star la fonction serialize() de PHP qu’on applaudit au passage.

Et pendant ce temps nos maudits collègues, qui soit dit en passant ont eu le temps de nous rattraper côté avancement, font face à une situation similaire sur leur projet Zend. Revirement de spécification qu'ils absorbent sous notre nez et d’une manière plutôt élégante et agaçante. Surtout qu'ils se payent le luxe de mettre à disposition de l'équipe une petite librairie de rien du tout et toute proprement packagée.

 

D’effets de bord en dommages collatéraux ...

Mais heureusement les sacro-saintes deadlines imposées sonnant toujours le glas avec une irrégulière ponctualité, les rendus projets coincideront souvent avec les heures du bilan. Et c'est la que l'on s'expose à certains nouveaux constats amers :
  • Le point le plus frappant est que l’on risque aboutir à une interface d’administration, victime de sa propre «généricité», qui sera devenue tellement complexe (même si totalement épurée du surplus) que le client final restera figé devant son écran au moindre formulaire façonné pourtant selon ses propres volontés. 
  • Le syndrome «ragoût de modules» épicé par le fait que nous sommes toujours constamment dans la recherche des points de torsion du système, sans pour autant le faire rompre, fait bien souvent regretter la sacro-sainte liberté des autres développements Framework. Et le fait de finir souvent en total acharné pour aboutir sur une solution abracadabrante après une énième jonglerie, nous fait nous demander si ce jeu en vaut vraiment la chandelle.
  • La maintenance sera particulièrement alourdie faute à vos développements ajoutés à la complexité du maillage induit par la multitude des modules installés et aux problématiques de synchronisation multi-environnement des bases de données.
  • Une des rançons de la gloire communautaire et de la forte diffusion de l’information : le suivi et la transparence des correctifs de sécurité forceront à redoubler d’effort et de rapidité sur la maintenance afin de ne pas exposer grandement vos sites aux piratins du dimanche.
 

Même combat et faux semblants

Le trait a été volontairement tiré, car avec Drupal ou n’importe quelle autre technologie, l’histoire pourrait être la même.
Le sens commun nous commandeant bien sûr de toujours effectuer des travaux de pre-validations techniques sur les points ultra clés et pivots d’un projet (et encore plus ceux évalués comme «à risque») . 
 
Mais cette petite démonstration servait surtout à rendre compte du fait que nous jugeons qu'il y a une charge de risques plus élevée à ne surtout pas négliger quand on fait le choix de cette gamme de technologies. Car elles imposeront forcement un cadre qui sera toujours plus contraignant qu’un outils «bas niveau», qui en jettera certes moins aux yeux, mais qui conservera une certaine souplesse non négligeable et parfois salvatrice. Surtout que plus la complexité de la solution à mettre en oeuvre augmentera et plus le cadre sera contraignant, plus l’impasse risquera d’arriver vite.
Et c’est bien le paradoxe et risque de ce type d’outils : tout étant déjà fait et tout étant mis à disposition donc tout ira très bien et très vite. Sacré invitation à partir bille en tête en mettant de côté ce fameux sens commun non ?
 
Une fois ces faux-semblants mis de côté, Drupal nous montre un tout autre visage, rattrapant à grand pas ses "voisins" les Framework, en terme de complexité dans ses rouages "moteur".
Et c'est à cet instant, à "moteur découvert", que l'on peut se préter à la question de l'intérêts entre ces 2 écoles.
 

Et voici donc venue l'heure de dresser notre petit bilan. Et ça se passe ici :
Fatal Drupal - Révélation (3/3)

 




Ajouter un commentaire