Le MVC est un design pattern qui est l’abréviation de Modèle-Vue-Contrôleur, et pour une fois, en anglais ou en français, ça fait les mêmes initiales (Model-View-Controller), donc y aura pas de débat sur comment qu’on doit causer. On raconte que son créateur se nomme Trygve Reenskaug, me demandez pas comment ça se prononce — son créateur, ou disons son théoricien, car comme souvent, on ne l’avait pas forcément attendu pour opérer de cette façon, mais il a mis des mots dessus (ce qui ne diminue pas l’importance de son travail).

Pour tout dire, quiconque a fait seul dans son coin des sites web dynamiques en mettant un peu (beaucoup) les mains dans le cambouis des langages/bases de données/exploitations multiples des mêmes informations, etc, a de fortes chances d’avoir à un certain niveau commencé à appréhender plus ou moins consciemment le MVC – ou alors, il a vraiment beaucoup galéré, et il est un petit peu décédé à l’heure qu’il est.
Moi qui vous parle, enfin vous écrit, avant de lire quelques livres intéressants sur le sujet et de découvrir des frameworks, j’en étais arrivé à travailler systématiquement avec d’un côté des méthodes d’accès aux informations (à peu près bien abstraites du système de base de données), de l’autre des fichiers traitant les sorties (pour le web, pour le XML, pour des usages internes…), et au milieu un ou plusieurs points traitant les actions des utilisateurs et décidant ce qui devait être mis en œuvre.

Bien sûr, n’ayant pas conscience clairement des enjeux de cette division (faute entre autres d’avoir mis des mots dessus ; d’où l’importance de nommer), il traînait de nombreuses erreurs d’organisation affaiblissant souvent pas mal l’ensemble. Mais le fond était là : porté par la nécessité interne des traitements récurrents nécessaires pour une application web, j’avais fait un premier pas sans même le savoir, tel le Monsieur Jourdain des design patterns, dans le monde merveilleux du MVC.

Le MVC, ou comment diviser pour mieux régner

Précisons avant d’aller plus loin que comme tout design pattern, MVC n’est pas spécifiquement dédié à une technologie, un langage ou quoique ce soit.
Il concerne de droit toute application avec une interface Homme-Machine, comme on dit (enfin, on dit IHM si on veut avoir l’air au courant), et consiste en une sorte de paradigme de l’organisation de l’application, séparant les données et leur vie (modèle), leur présentation (vue), et la gestion des événements (contrôleur).

Séparer le modèle et la vue repose sur une exigence au fond assez simple, qu’on pourra schématiser comme suit : il faut traiter d’un côté le « fond », de l’autre la « forme ». Je recours aux guillemets, non pas pour pourrir la lecture, mais parce que l’utilisation de ces deux termes et leur séparation semblent aller de soi, or comme tout ce qui « va de soi », elles méritent d’être questionnées. Il est illusoire de croire qu’il y aurait d’un côté du « fond » (du contenu, de la pensée…) et de l’autre de la « forme » (l’expression, qu’elle soit écrite, orale, artistique…)
Autant supposer qu’on peut sans autre forme de procès séparer la musique du son, ou l’objet de sa manifestation — ce fantasme de séparation n’est en fait qu’une autre version de l’illusion platonicienne de la chose en soi, « vraie » chose dont le phénomène serait une version dégradée dans notre pauvre monde d’apparences.
Non pas qu’il n’y ait pas un intérêt théorique capital à pouvoir considérer séparément ces aspects ; mais dans la réalité, je vous le dis, croyez-moi sur parole, le phénomène épuise tout ce qu’il y a à être de la chose, et la forme, comme je l’ai déjà formulé dans une note précédente, et exactement forme de son fond et réciproquement. Bref. J’ai clairement entamé un autre post ici, qui verra peut-être le jour une autre fois. Revenons à nos moutons.

Nos moutons sont le M, le V, et le C. Il n’aura échappé à personne, du moins à personne qui aura lu avec un minimum de concentration le billet précédent sur les prises électriques et les grille-pain (mais je reconnais qu’il faut du courage), qu’une organisation isolant bien ces trois aspects d’un programme est comme l’archétype du découplage.
Votre modèle (en gros, les données) peut changer de principe de stockage, de nature même si ça vous chante, pour peu qu’il soit correctement interfacé avec les autres couches du MVC, elles n’y verront que du feu. Le centre nerveux de votre application (le contrôleur, qui réagit aux actions de l’utilisateur et distribue les réponses) peut de son côté traiter n’importe quel type d’entrées et rediriger les sorties vers n’importe quel affichage, i.e. les vues. Vues qui de leur côté se contentent de mettre en forme (grosso modo) des informations, indépendamment de leur origine. J’ai failli dire « se contentent d’afficher », mais en fait, contrairement à ce que son nom laisse croire, une « vue » au sens du MVC ne résulte pas nécessairement en quelque chose de… visuel. Une vue peut-être par exemple un fichier XML, qui vivra sa vie ensuite selon le client (au sens informatique) qui l’a requis.

Quand l’intelligence gagne la matière

L’intérêt très concret de l’application du MVC est qu’il isole les opérations, donc que chacun n’a à s’occuper que de sa partie. Et comme dans la vie, c’est toujours mieux quand chacun ne s’occupe que de ce qui le regarde. Dans ma Normandie natale, on dit « Chacun son champ, les vaches sont bien gardées« . Eh bien on ne peut mieux formuler le principe du MVC.
En termes de développement, cette division conceptuelle vise à organiser les rôles par fonction, et à traduire les différences de nature en séparations opérationnelles. Comme si on faisait rentrer dans la chair du code, qui a priori n’en a que faire, un peu du sens des objets qu’on manipule. En contre-partie, dans un effet de résonance sémantique, j’irais bien jusqu’à dire : de récompense sémantique, le code, initialement « bête », gagne en intelligence d’organisation et d’évolution. Risquons la formule : bien utiliser le MVC, c’est insuffler de l’âme dans la matière. Ouaip. Pas moins.

L’ultime intérêt, non des moindres, est pédagogique : en s’efforçant d’appliquer cette discipline de conception et d’implémentation, on s’oblige à bien comprendre ce qui fait quoi dans son application. Et croyez-moi, c’est pas de la tarte.
Mais, une fois encore, une bonne méthode appliquée avec constance finit par insuffler plus que du mécanisme, et crée de l’intelligence. Et pas que dans le code. Dans le codeur également. C’est toute la puissance de la méthodologie : des idées régulatrices qui dirigent vers un endroit. Et même si on ne sait pas précisément où est l’endroit, on peut travailler à avancer dans la bonne direction, et à bien arpenter le chemin.
Car pour finir sur une touche étymologique du meilleur aloi, c’est précisément de là que vient le mot méthode : μέθα (méta, qui suit) οδός (odos, le chemin).

___________________________________

Image empruntée ici : http://www.marriedtothesea.com/archives/2007/Aug/

« Réinventer la roue » (ou « rihinveinte zeu ouhile », pour les bilingues), c’est perdre du temps sur quelque chose qui a déjà été fait, bien fait, mieux fait, bref, faire un travail inutile. En programmation, c’est même un antipattern célèbre. Si on peut lui reconnaitre dans une certaine mesure un intérêt pédagogique (l’impétrant développeur, en passant du temps sur une fonctionnalité déjà réalisée, s’initie au code et à sa logique – pour peu qu’il soit guidé), il est clair qu’on déconseille fortement de réinventer la roue. Si ça a déjà été inventé, coco, pourquoi perdre du temps à le refaire, d’autant qu’il y a fort à parier que tu le referas moins bien. En effet, non seulement la roue a déjà été inventée, mais depuis le temps, elle a été perfectionnée.

La bonne pratique est donc de capitaliser, comme on dit, sur ce que les autres ont déjà fait, testé et éprouvé.
En programmation, où l’Histoire est encore fraiche et où tout va très vite, ces « autres » sont parfois des contemporains (voire sont plus jeunes que vous ; sales jeunes), mais pour généraliser on peut dire que cette bonne pratique consiste à apprendre de ce qui a été fait, donc apprendre du passé, des générations précédentes, en d’autres termes : de ses aînés. Ce passé qu’on peut plus ou moins consciemment faire fructifier a un nom : la tradition.

L’Histoire se répétant, chaque nouvelle génération a une tendance plus ou moins forte à vouloir se défaire de la tradition, comme une transposition à l’échelle socio-culturelle de la crise d’adolescence, où le besoin de conquérir son individualité se traduit parfois par des chocs violents (tant il est évident que pour chaque jeune, les vieux n’ont vraiment rien compris, et ne peuvent de toutes façons pas le comprendre lui).

Il y a pourtant une réalité douloureuse, c’est que globalement, vu que l’Histoire n’a pas exactement commencé hier, ni même à la naissance de Bill Kaulitz/Brian Molko/Kurt Cobain/Robert Smith/John Lennon (choisissez pour votre génération ou celle qui vous suit), vu que l’humanité, donc, a quelques heures de vol derrière elle, excusez du peu, il y a de fortes chances que tout ait déjà été fait.

Connais tes classiques

Bien sûr, l’accélération (on va appeler ça comme ça) de l’Histoire dûe à la technologie au sens très large, donc depuis la fin du XIXème siècle, fait que dans pas mal de domaines, le passé est bref. Ça a un côté assez sympathique, on peut croire un peu qu’on défriche des choses — et ça n’est en partie pas faux —, mais il ne faut pas non plus se faire avoir par une courante illusion d’optique : même si concrètement le contenu du savoir/de la technologie en question est « différent », dans l’histoire du savoir, on n’invente que très rarement quelque chose. Pour ne pas dire jamais. La plupart du temps, on repasse en fait par des chemins qui ont déjà été empruntés, même si on ne le sait pas (et dans ce cas, en un sens, on peut se retrouver à réinventer la roue).

Cette illusion repose principalement sur un aveuglement, dû à un manque de connaissance du passé, et la bonne pratique qui préconise de ne pas réinventer la roue exhorte donc à ouvrir les yeux. Mais pour ça, comme on dit, il faut connaître ses classiques. Lire, écouter. Plus tu connais le passé, plus tu maîtrises le présent, plus tu façonnes le futur comme tu le veux (je devrais écrire des slogans pour ERDF, moi).

Ça peut avoir l’air déprimant comme ça, mais ça ne l’est que si l’on se berce de l’illusion (une autre) qu’on est le premier de l’espèce humaine et que tout nous a attendu. Il faut se réveiller. Personne ne nous a attendu, et les morts sont plus forts que les vivants.
Mais en fait, c’est très bien, et ça laisse quand même de la place. Parce que l’histoire est une perpétuelle redigestion, qu’elle engendre quand même du nouveau, et qu’emprunter un chemin qui a déjà été foulé est toujours un nouveau périple.

La morale de cette histoire (qui n’en est pas une), c’est que quand l’ego a réussi à faire le deuil de sa toute-puissance, à entrer dans son humilité, et pas au sens chrétien du terme, alors les choses intéressantes peuvent éventuellement commencer.
J’aborderai probablement une autre fois le rapport à la tradition, qui n’est évidemment pas univoque et ne doit pas consister en une soumission absolue (car, comme disait l’autre, la tradition ça peut aussi être de la paresse ou de la négligence. Mais pour contester ou dépasser, il faut connaître ce qu’on prétend dépasser.

__________________________

Illustration fort à propos trouvée fortuitement ici : http://plennevaux.be/alexandre/general/monocycle-par-ben-wilson/

Ça fait quelque temps que je fomente cette note. A force d’entendre répéter ça et là que telle ou telle chose n’est qu’une question de bon sens, et malgré des années de sommeil (pas si dogmatique), j’ai fini par remâcher quelques vieilles dispositions anti-cartésiennes dont je vais vous abreuver pas plus tard que tout de suite.

Car oui, s’il n’a bien évidemment pas inventé le bona mens, c’est notre ami Descartes qui installe le « bon sens » comme le fourre-tout le plus prospère de l’histoire de la pensée (occidentale) moderne.

La première phrase du premier chapitre de la première partie du fameux/fumeux Discours de la méthode assène anéfé sans autre forme de procès que, selon la formule que chacun connait sans la connaitre :

Le bon sens est la chose du monde la mieux partagée 

Il ne faut pas cela dit prendre Descartes pour plus bête qu’il n’est ; son bon sens n’est pas le pur et mou « sens commun », mais une disposition de l’esprit que chacun peut trouver, une sorte de sagesse de l’évidence (et sans mauvaise blague, Dieu sait que c’est son truc, à René, l’évidence).
Tout comme faire simple est parfois plus complexe que faire compliqué, faire comme on dit « preuve de bon sens » n’est pas si aisé. C’est que l’évidence cartésienne est une sorte de préfiguration du résultat de la réduction phénoménologique (enfin, soyons honnêtes, ce sont les phénoménologues qui réinvestissent Descartes un peu moins de trois siècles après).
Il y a le « bien connu », trop connu, qui camoufle, comme le gros drap poilu et poussiéreux d’années de sensations non questionnées, la phénoménitude du phénomène (Ségo, sors de ce corps).

Mais quand même, le bon sens selon Descartes est bien à la portée de tout le monde. C’est la chose du monde la mieux partagée. En une phrase Descartes signe l’ouverture de la modernité, faisant d’une « qualité » inhérente à tout être humain le butoir à la régression à l’infini du questionnement philosophique : au bout d’un moment, il ne faut plus se demander pourquoi, car c’est bien évident que ça n’est qu’une question de bon sens. Jvous la fait à l’arrache des grands jours, bien sûr, mais l’argument ontologique (qui sert de base à une preuve de l’existence de Dieu) ne vaut pas deux cacahuètes de plus.

Un coup de poing sur la table

Eh oui. Songes-y, toi le voyageur mystérieux (ouaip, j’ai envie de vous apostropher comme ça), si enfin il suffit de faire preuve de bon sens, il n’y a plus rien à discuter. Et si tu ne comprends pas, c’est que tu n’as pas, ou pas assez, de bon sens. Prends-toi ça dans ta face. Et si tu critiques ou te révoltes, c’est que tu ratiocines, que tu coupes les cheveux en un multiple de deux, bref, que tu es du côté de la non-clarté (oui, le « côté obscur », ça a des sortes de connotations dont je vais me passer pour ce soir), donc ferme ta mouille.
En quoi le recours à l’argument, que dis-je, le coup de poing sur la table de l’invocation du bon sens, est un double geste démagogique — le bon sens est la sagesse des humbles, de la France d’en bas, pas des intellos parisiens — et autoritariste : c’est en fait un ordre impératif de se taire.

Comprenons-nous bien : je force le trait, comme souvent, pour donner de la chair au propos. Je reconnais tout à fait, je l’ai évoqué plus haut, la difficulté de la simplicité, et j’admets qu’on a souvent tendance à faire d’emblée compliqué. Je suis assez d’accord pour mettre la sagesse du côté du moins, ou plutôt du kairos, de la juste mesure, quoi (à strictement parler, le saisissement du bon moment, qui est un art délicat). Et je sais bien que Descartes n’aurait pas complètement dit le contraire, mais j’aime bien l’avoiner, car sous maint aspect il nous a bien plombé. Enfin ça n’est pas l’objet.

Et le bon sens, alors ? Je n’ai rien contre le bon sens. Quelque soit ce qu’on entend par là, presque. C’est plus son invocation, utilisée comme stratagème rhétorique, qui a tendance à me rendre un tantinet suspicieux.

Ce sera donc le conseil du jour : tout comme quand vous entendez parler de carreleur, chaque fois que soudain un appel au bon sens surgit, entendez-le bien, mais ne vous faites pas moucher.
Le bon sens n’est pas un argument en soi. Et surtout : il ne va pas de soi (normal, sinon on n’aurait d’ailleurs pas à y faire appel…), donc son irruption dans un discours ne doit pas mettre fin à toutes les questions.
En fait, il ne vaut pas plus qu’un coup de poing sur la table. Alors ok, un coup de poing sur la table, des fois c’est utile, mais il faut savoir où on est et ne pas prendre ça pour un argument.
Or, on peut être intimidé par les coups de poing, mais on a toujours le droit de demander des arguments.

Résumé de l’épisode précédent : un framework, c’est une boîte à outils, des briques de base, et une méthodologie pour développer mieux, plus vite, et de manière plus sûre (un peu comme ça, quoi). Mais si ça peut fortement aider, ça n’est pas magique, et ça demande de suivre les principes du framework lui-même.

Une partie des principes méthodologiques qui va avec un framework est  couramment regroupée sous le nom de design patterns. Une fois encore, on s’abstiendra de traduire l’expression (la version française préconisée étant patrons de conception, et ça sonne un peu Bergère de France…)

Pour faire court (dans un premier temps), disons qu’un design pattern est une façon de résoudre un problème type. Il ne s’agit donc pas d’une solution en tant que telle, mais plutôt d’une recette, c’est-à-dire la description d’une manière d’opérer face à un certain type de problème.

Historiquement, la théorisation des design patterns fait beaucoup référence, et c’est une chose qui ne nous étonnera pas, au domaine de l’architecture, de l’urbanisme et de la construction, notamment suite au travaux de Christopher Alexander dans les années 70.
Constatant que la conception en architecture en particulier, mais aussi en ingénierie en général, conduisait à affronter des problèmes récurrents (isolation, solidité des structures, communication entre l’intérieur et l’extérieur…) il abstrait des archétypes destinés à couvrir tous ces aspects.

Un pattern est ainsi à comprendre comme un « modèle » éprouvé reliant une solution à un problème dans un certain contexte.

Tout problème de conception, dirait Alexander, met en jeu un seul individu face à une immensité. Ce problème contient un certain nombre de variables qui, combinées en sous-ensembles, représentent un nombre de cas débordant rapidement les capacités limitées de son cerveau.
D’où l’intérêt de diviser et de hiérarchiser ces sous-ensembles pour les étudier à part, et recourir à ce qu’on pourrait nommer le bon sens collectif de l’histoire (capitaliser sur les solutions qui ont prouvé qu’elles marchaient).
Dès ses premiers travaux Alexander met l’accent sur la nécessité de comprendre les rapports entre les parties et le tout, et de savoir comment s’y prendre pour traiter ce tout. Ce que nous avons appelé dans l’épisode précédent faire face à la complexité.

De l’urbanisme à la POO

En 1995, les quatre mousquetaires du pattern, le bien nommé « Gang Of Four », s’inspirent d’une partie de ces travaux et transposent la méthode dans la programmation orientée objet. Comme Alexander, même si la démarche est, disons, moins empreinte d’une sourde angoisse métaphysique quant à l’appréhension de l’infini, leur but est de proposer des outils conceptuels pour gérer la complexité, en l’occurrence, posée par certains problèmes récurrents en programmation.
Ils sont issus des bonnes trouvailles et des bonnes pratiques de générations de développeurs et dispensent ainsi, comme on dit souvent, de réinventer le fil à couper la roue.

J’avais commencé un paragraphe complet donnant un exemple (en choisissant le pattern bridge, un modèle assez « simple »), et j’ai renoncé, car on ne peut pas en dire grand chose sans évoquer la programmation orientée objet, que ma chère maman n’est pas censée connaître, donc qui déborde le cadre de cette page.
Je tâcherai de présenter en revanche dans un épisode prochain le MVC, un design pattern assez connu — qui est en fait, pour être rigoureux, une combinaison de patterns. Retenons juste ceci en attendant, et au risque de me répéter : il ne s’agit pas de classes ou de bouts de programme, mais de façons de structurer son modèle de données, son architecture, son application, et ultimement son code (quelque soit le langage objet).

En guise de conclusion, et pour s’éloigner définitivement d’Alexander, signalons qu’on parle aussi de temps en temps du négatif des patterns, les antipatterns.

Comme leur nom l’indique, il s’agit des façons de faire qui sont exactement ce qu’il faut éviter. On regroupe sous ce nom des pratiques hétérogènes aux noms parfois sympatoches, comme la coulée de lave (mise en production d’un code non stabilisé qui de fait devient de moins en moins modifiable, se « solidifiant » comme de la lave), l’ancre de bateau (code conservé pour des raisons « politiques », pour ne pas fâcher un développeur et/ou en se disant qu’il servira plus tard…), ou l’objet divin (méthode ou fonction servant à trop de choses, et dont on finit par ne plus trop savoir comment elle marche).
Elles sont évidemment, presque autant que les autres, utiles au développeur — qui aura toujours au début de son existence mis en œuvre, même à son corps défendant, au moins l’un d’eux, sinon presque tous.

Dans le prochain épisode, cette fois, on parlera de MVC…

___________________________________

Image du Schéma empruntée ici : http://www.simonwhatley.co.uk/coldfusion-and-design-patterns

Quand vous faites partie du second groupe, ou quand vous travaillez dans le développement d’applications, vous apprenez rapidement qu’il existe, au-delà de l’heure, du jour, de la semaine, une unité de mesure capitale : le jour-homme.

Je me dis depuis quelque temps qu’on pourrait même entériner un nouveau mot : le « jourhomme », que la réforme de l’ortografe transformerait en « jourome », et ça serait sympa. Sans parler bien sûr du jourfemme qui devra exister impérativement. Mais je m’égare.

Comme son nom l’indique presque, le jour-homme correspond au travail d’une personne pendant une journée. Ca fait beaucoup rire nos amis anglo-saxons de nous voir utiliser une telle mesure qui passe sous silence toute discussion éventuelle sur la valeur du référent… Il nous faut alors leur expliquer que par chez nous, la durée « officielle » d’une journée de travail est de 8 heures, même s’il s’agit en fait d’une durée admise comme standard – avec toutes les élasticités bien commodes que ça implique, et qui permettent de faire au besoin rentrer deux « jours » en une journée (ben oui, il suffit de travailler de 8h à minuit, fastoche).

Quand on estime une charge de travail, on la chiffre donc en jours-homme.
En général, on colle ça après dans un calendrier (avec ou sans l’aide de certains logiciels pas lourds du tout dont le nom commence par « pro » et se termine par « ject »), et ça nous donne un planning, autrement dit une représentation dans le temps de la vie des vraies gens, week-end et autres jours chômés inutiles pris en compte.
Il est étonnant de remarquer à quelle vitesse on finit à force de faire cet exercice par penser en multiples de 5, et par assimiler 1 mois au chiffre 20 (ce qui est par ailleurs souvent inexact, mais bon, à la louchasse, c’est ça). On met en général plus de temps à intégrer comme un réflexe le calcul inconscient de marges de sécurité conséquentes (de 20 à 50%).

Toujours est-il qu’à l’arrivée, on présente au client un planning, dans lequel il ne regarde en général qu’une seule date, celle de la livraison. C’est le moment où il fait des grands yeux, voire devient livide, voire s’énerve, voire tout ça en même temps ou dans un ordre aléatoire.

Mais, tenez-vous bien, ça n’est pas grave. Pourquoi ? Tout simplement parce qu’on va pouvoir optimiser le planning. Et c’est quoi la solution magique pour optimiser le planning ?

Oui, vous avez trouvé : la parallélisation.

La parallélisation, c’est cette bonne idée qui consiste à dire qu’on va mettre plusieurs gars sur le coup (ou filles, hein, enfin si seulement on en avait dans l’équipe de développement), et que paf par magie ça va linéairement diviser le temps de production par le nombre de ressources affectées. En gros (si vous êtes un peu malcomprenant), s’il y a 60 jours-homme, en mettant deux développeurs, ça va être fait en 30 jours.

Jusque là, je n’aurais presque rien à dire. C’est presque vrai, c’est même presque malin, voire presque réaliste. Sauf que vous connaissez les gens : il leur en faut toujours plus (les coquins). Donc vas-y que jte mets 4 développeurs et c’est torché fait en 15 jours ! Vous voyez venir l’écueil (enfin, j’espère, c’est pas faute d’être lourdement didactique) : tant qu’on y est, mettons 60 développeurs, et ce soir c’est plié.

Sans parler de l’incongruité en termes d’écosystème (essayez de regrouper 60 développeurs et vous comprendrez), on a évidemment oublié un détail dans cette équation, trois fois rien, un mot innocent : la ré-a-li-té.

Eh oui. Dans la réalité, répartir la charge induit très vite des « coûts » collatéraux, notamment en coordination du travail. S’il est souvent envisageable de séparer les tâches en plusieurs lots, il n’est pas dit qu’ils puissent être, d’un point de vue logique, tous réalisés en parallèle.

C’est chiant, la réalité, ça marche pas toujours comme les maths ; par exemple, un lapin plus un lapin, pour peu qu’ils soient de sexe différent, ça a vite des chances de faire plus de deux lapins. Vous me direz : ah mais il s’est passé quelque chose.  Mais justement, ce qui est caractéristique de la réalité, c’est qu’il s’y passe des choses, et qu’il y a des contraintes qu’on ne peut pas réduire, même si on est très bon en maths.

J’aime bien recourir à une image qui fait en général son petit effet. Elle n’est pas de moi, je crois l’avoir trouvée quelque part dans un machin imprimé, un livre, là, mais je ne retrouve pas la référence, et Google est curieusement un peu muet sur le sujet. En la sortant au bon moment, le résultat est garanti :

Si on met 9 femmes enceintes en parallèle, on n’aura pas un enfant en 1 mois.

Si vous faites bien vos devoirs, vous ne devez toutefois pas prendre cette superbe saillie pour argent comptant, et questionner l’analogie (n’est-ce pas). En d’autres termes, demander si développer une application, c’est comme faire un bébé (je vous passerai toutes les bonnes blagues auxquelles ça peut me faire penser, sinon on va y passer l’hiver).

Soyons prudent sans faire de la langue de bois : oui, il y a dans les processus de développement des étapes, qui ne peuvent que s’enchaîner et donc pas avoir lieu en même temps. Il faut pour cette raison ne pas hésiter à affirmer que :

• le temps nécessaire n’est pas linéairement divisible par le nombre de ressources affectées ;
• l’augmentation du nombre de ressources accroit de manière exponentielle les tâches de coordination, et tend pour cette raison très  rapidement à annuler le gain de temps nominal (voire à l’inverser, c’est-à-dire à faire perdre plus de temps qu’on en gagne).

Selon les métiers et les projets, le point de la courbe où la tendance s’inverse est plus ou moins vite atteint, mais d’expérience on constate qu’il l’est toujours plus vite que ce qui serait nécessaire pour satisfaire des plannings irréalistes. Et le plus difficile, c’est de le faire comprendre aux « décideurs » (car les coupables ne sont pas toujours les clients, si si…)

D’où les 9 femmes. Ça n’est pas magique, mais ça peut avoir son poids dans une argumentation.

Ce framework porte le nom de Symfony, pour des raisons expliquées ici. Jusque là, fastoche. C’est ensuite que ça se complique. Déjà, rien que le premier mot : framework. Littéralement, cadre ou structure ; dans la programmation en général, on le traduit plus précisément par « cadre d’applications ». Enfin, on le traduirait, parce qu’on ne le fait jamais, on dit toujours frèmeouorque. A compter de cette phrase, je dirai d’ailleurs « framework » sans autre forme de procès, et même sans italiques (je suis comme ça, jsuis un gueudin).

Pour commencer, donc, qu’est-ce qu’un framework ? S’il y avait une réponse simple, on se passerait de ces lignes. La difficulté majeure tient à ce qu’il y a en fait dans la définition deux dimensions principales, complémentaires mais en partie indépendantes : un framework c’est à la fois une boîte à outils et une méthodologie. Ou, si on n’a pas peur des envolées lyriques : une boîte à outils fournie avec une philosophie.

Une boîte à outils

On a l’habitude de comparer un framework à un ensemble des « briques » toutes faites qu’on peut utiliser pour son application .
Si l’analogie n’est pas trop mauvaise, elle est insuffisante, parce qu’un framework c’est plus que ça. Cela dit, l’image de « brique » convient assez bien à ce qui circule çà et là sous le nom de composants (et d’ailleurs, le monde est bien fait, car certaines parties de Symfony sont justement mises à disposition comme composants : http://components.symfony-project.org ; dingue, hein ?)

Mais revenons à l’analogie de départ, même si elle est un peu faible ; elle dit qu’un framework est à un développeur ce qu’une boîte à outils est à un bricoleur.

Sous plusieurs aspects, un framework peut effectivement fonctionner comme une boîte à outils, en ce sens qu’il propose, dans le cas de Symfony du moins, un certain nombre de trucs pour faciliter le travail, l’accélérer, voire automatiser tout ou partie des tâches qu’on rencontre lors du développement d’une application web. C’est le côté work du framework, si l’on veut.
Enfoncer un clou, à la main, c’est douloureux et très long ; avec une pierre, moins douloureux, mais pas très précis. Avec un marteau, l’outil est assez optimal – même s’il ne dispense toutefois pas de taper. En plus, ce marteau a été testé industriellement, donc a de bonnes garanties de solidité .

Dans le développement web, on ne plante pas des clous, mais il y a des tâches équivalentes qui sont répétitives, peu gratifiantes, et d’autant plus sujettes à erreur qu’elles sont répétitives et peu gratifiantes : construction de bases de données à partir de leur schéma, import de données de test, initialisation d’interfaces d’administration, exécution de tests, gestion du cache, des urls…

Pour tout ça, le framework offre marteaux et tournevis, voire dans certains cas pistolets à clous. Ces « utilitaires »,  testés et mis à l’épreuve du feu par de nombreux développeurs, ont bénéficié de leurs retours d’expérience, leur efficacité et stabilité sont assurées par ce processus. Mais pas plus qu’un marteau ils ne dispensent pas de taper. Vous pouvez vous procurer une belle boîte à outils, ça ne fixera pas pour autant vos étagères au mur …

A un niveau un peu plus complexe, le framework (du moins Symfony) favorise l’intégration en deux coups de cuiller à pot de plug-ins, qui sont un peu comme les briques évoquées plus haut. Il en existe un grand nombre, pour des fonctionnalités plus ou moins évoluées (authentification, gestion de médias, de contenu…). On dépasse là le cadre de la « boîte à outils », et on est plutôt sur des objets de base qui font gagner du temps. C’est comme acheter des planches déjà découpées plutôt que de les scier soi-même. Mais ces objets conviennent rarement tels quels . Il faut les adapter à ses besoins. Par exemple peindre ses planches de la couleur qui va bien, choisir combien on en pose, à quelle distance les unes des autres…

Point crucial : dans le cas du framework, l’adaptation sera grandement facilitée par la méthodologie qui doit avoir été respectée par les créateurs des plug-ins. C’est-à-dire : si elle a été respectée.

Ce qui nous fait une transition toute trouvée pour le second aspect, non des moindres, de la définition d’un framework : en plus d’être une boîte à outils, un framework, c’est une façon de travailler.

Une méthodologie

Pour tenter une analogie, disons qu’un framework est à la programmation ce que grammaire et orthographe sont à la pensée.

On quitte là le champ lexical du bricolage pour celui de la linguistique, ou plutôt de l’apprentissage du langage . Glissement qui semble tout indiqué, puisqu’on parle de langage de programmation. Si on fouille un peu, on verra même que la nécessité de changer de champ répond en fait à une exigence interne, dictée par le caractère spécial des langages artificiels : un croisement génétique, pour ainsi dire, entre de la logique (qui se veut mécanique et déterministe) et de la pensée (qui reste inductive et poétique par nature, mais c’est une autre histoire).

Filons la métaphore. Quand on se met à programmer, on apprend une syntaxe, des fonctions, des mots-clés… ; bref, une sorte de grammaire et de dictionnaire .
Mais connaître par cœur l’intégral de la phpdoc ou autre n’a jamais fait un bon développeur, pas plus que réciter le Bescherelle n’a fait un grand auteur.

C’est là que, tel un cavalier qui surgit hors de la nuit (mince, ça y est maintenant j’ai la musique de Zorro dans la tête), intervient le framework. Il joue un rôle à la croisée de la rhétorique, de la littérature et de la logique :

• il énonce des conventions d’écriture et d’organisation destinées à rendre plus efficace, en homogénéisant et clarifiant
• il s’inspire des bonnes pratiques déjà existantes, notamment en termes de style
• il structure et favorise la discipline du code produit, et son indépendance à l’égard de toute solution logicielle ou matérielle.

En gros, il joue son rôle de « cadre » et de structure. C’est le côté frame du framework : il contraint à un certain nombre de choses, mais pour mieux libérer le processus intellectuel, en particulier en l’affranchissant des routines chronophages, et en aidant, par la clarté exigée, à faire face à l’augmentation de la complexité .

Si tout développeur qui connait un tant soit peu un langage (PHP en particulier, qui est plus facile d’accès que d’autres) est capable, même en tâtonnant, de mettre au point une application plus ou moins évoluée, l’expérience montre toutefois que son degré d’instabilité croît alors exponentiellement à la mesure de sa complexité, et que son code a tendance à devenir incompréhensible (et donc instable, indébuggable, non maintenable, etc…)

Pour faire face à la complexité, il faut être équipé de certains outils, intellectuels cette fois. Un framework a pour but de fournir de tels outils facilitant la modélisation des objets, de leurs relations, et des solutions aux problèmes posés. Il est à la fois une extension du vocabulaire du développeur et un perfectionnement de ses capacités grammaticales.
Du moins, il peut l’être. Car comme le marteau ne tape pas tout seul, le framework ne pense à la place de personne. Pire, comme un marteau, mal utilisé, il peut faire mal. Et s’il tend à structurer, il n’oblige ultimement personne à suivre sa méthodologie ; s’il peut aider à discipliner, il ne remplace pas l’auto-discipline qui est du ressort de ceux qui conçoivent et écrivent le code. Bref : un framework ça n’est pas la pierre philosophale qui changera votre code de plomb en or.

On se résume : côté pile, le framework est un cadre structurant, côté face, le framework est un outil facilitant le travail.
Finalement, on avait bien raison de garder le mot anglais.

Dans le prochain épisode, on parlera de design patterns…