« 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/

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