lundi 14 novembre 2016

Le data Model : pierre angulaire du développement applicatif

Le modèle MVC, pour « Model, View, Controller », fait un tabac dans les architectures applicatives web. La vue en est l'aspect le plus connu : c'est ce qui est affiché à l'utilisateur. Le contrôleur quant à lui est bien sûr chargé de contrôler le comportement de la vue, il gère ce qui doit être fait sur un clic, un enter, etc. Reste le M pour modèle qui est beaucoup moins bien compris. On considère trop souvent que ce sont simplement les données. Grave erreur, qui se paiera cher en temps, en quiproquos et en complexité de développement.

Lorsque j'interviens dans une entreprise pour développer du front-end, ma première question est systématique : « quel est votre data model applicatif ? ». La réponse du chef de projet est presque toujours la même : « notre quoi ? ». Au bout d'un temps d'explication j'ai le droit à un « ah oui, je vois ce que tu veux dire, heu, non, on n'en a pas ». Puis je regarde l'applicatif et son code, et là je comprends ce que coûte cette absence. Il m'importe donc dans ce billet de souligner l'intérêt du data model, non seulement pour le développement, mais bien plus encore pour la relation entre l'utilisateur métier et l'informaticien, un aspect des choses qui coûte en général très cher à un projet, voire le plus cher. Le data model doit être la pierre angulaire de tout développement, son fil rouge, et le trait d'union entre le métier et l'informatique.

Le data model en pratique

Comme d'habitude je parlerai ici du développement web et de ses standards, mais cela est applicable à tout développement objet moderne.

Le « M» de MVC est en réalité le « data Model », c'est à dire la façon d'organiser les données. Ce ne sont pas les données en elles même (sinon on aurait dit DVC), mais le réceptacle qui permettra de les structurer. Ainsi un modèle de données peut, et doit pouvoir, exister vide de données.

Au XXème siècle, on utilisait un « modèle de base de données » (sous entendu SQL), qui remplissait finalement la même fonction conceptuelle, mais de façon très laborieuse et indirecte.

En pratique le data model, à létat pur, n'est qu'un fichier Json, c'est tout (standard qui actuellement écrase XML par exemple). Ce fichier décrit comment vos données sont structurées pour faire fonctionner votre applicatif, TOUT votre applicatif. En prenant l'exemple classique d'une bibliothèque municipale, le data model pourrait ressembler à cela :

Figure 1 : un exemple de data model objet Json, dans le cas d'une bibliothèque municipale

Ce data model décrit la position et les dépendances de tous les objets et variables qui seront nécessaire à développer TOUTE l'application. Vous remarquez aussi que ce data model est vide de données, et pourtant il donne une image très claire de l'organisation de celles-ci, telle que le bibliothécaire la conçoit. Cela est structurellement fondamental pour le développement de votre applicatif.

Mais ne vous y trompez pas, seul un utilisateur métier sera capable de décrire cette architecture … métier. Aucun informaticien ne sait en quoi consiste le métier de l'utilisateur, car il est informaticien, pas commerçant, ni avionneur, ni distributeur, ni banquier, ni bibliothécaire, …

Evidemment, à l'inverse, l'utilisateur n'est pas un informaticien, et il y a donc peu de chance qu'il sache ce qu'est un objet json. C'est donc à l'informaticien, comme préalable à tout choix technologique, et donc à tout développement, d'interviewer l'utilisateur pour lui faire décrire son data model métier. Le résultat de cette interview sera retranscrite en objet Json tel que celui de la figure 1. l'informaticien est là l'interprète de l'utilisateur auprès de la machine, sans lui aucun de ces deux là ne pourraient se rencontrer.

Avant tout, LE lien entre l'utilisateur et l'informaticien

Cette pratique du data model possède de nombreux avantages, notamment lors de sa modification.

Si un mois après le début des travaux, l'utilisateur annonce qu'il a oublié un aspect des choses, et qu'il s'est trompé sur un autre (non, non, ça n'arrive jamais =;o), il suffit de modifier l'objet json, en accord avec lui. Etre agile, quoi, mais réellement, et même si on ne fait pas de DSM (Daily Standup Meeting). L'objet Json est idéal pour ça.

Parfois on se rend compte à cette occasion que l'utilisateur veut une chose et son contraire, ou qu'il a une vision incomplète, voire incohérente, de ce qu'il souhaite (le propre de l'homme). Le data model est alors d'une extrême utilité pour lui mettre en lumière les défauts, et parvenir à une adaptation d'un commun accord. Cette adaptation est toujours possible dans le data model, mais il se peut que cela perturbe les méthodes qui ont été développées avant la modification, et dans ce cas, l'utilisateur voit plus directement les conséquences de ses modifications (il acceptera donc mieux une surfacturation, ou le dépassement de délais, dont il est responsable).

Le data model est donc, avant toute chose, LE point commun unissant l'utilisateur métier et l'informaticien, autour d'un applicatif. Au moindre problème l'informaticien peut décrire à l'utilisateur, très précisément, sur quelle partie du data model il bute. Et surtout vice versa, ce qui n'est pas le moindre des avantages. Cela fait gagner un temps fou, en évitant nombre de quiproquos et d'incompréhensions.

Et si vous y réfléchissez bien, combien de temps ont perdu vos projets sur de telles incompréhensions mutuelles ?

Le data model pour l'informaticien

Vu du côté programmatique, le data model est un objet contenant des propriétés, en revanche il ne possède aucune méthode associée. C'est normal car le data model est indépendant du langage objet que vous utiliserez pour votre développement. Gros avantage. Selon le langage, vous pourrez transformer votre objet « data model » en un objet « active data model ». A tout niveau de l'objet Json vous pourrez prototyper les méthodes les plus adaptées à votre besoin applicatif, dans le langage que vous aurez choisi. Sur le front comme sur le back, qui évidemment partageront le même data model.

On voit qu'ici aussi l'utilisateur devra définir ses besoins. Une fois la structure de ses données définies, que veut-il qu'on en fasse ? C'est de sa réponse que découleront les méthodes nécessaires à rendre le data model actif. Une seconde interview sera donc nécessaire, et distincte. Le data model est en quelque sorte l'état initial, mais si l'application est en mouvement, il faut en définir ses lois mécaniques : quelle est la conséquence de la modification de telle donnée ? Ce travail nécessaire est grandement facilité par l'existence du data model, car tout événement mécanique présuppose son existence et peut donc se référer à lui. Je ne vais pourtant pas entrer ici plus en détail de cet aspect mécanique des choses, car cela nous éloigne de notre propos, bien qu'il s'agisse d'un autre facteur important du succès d'une application.

Bien sûr, l'aspect monolithique du data model Json que j'ai décrit jusqu'ici est trop rudimentaire. Par exemple on peut avoir besoin de décrire un objet « book », et de permettre au data model d'en intégrer un nombre indéfini au préalable. L'objet « book » doit alors posséder son propre data model, mais toujours de façon cohérente et en accord avec le data model applicatif père, qui ne doit jamais être perdu de vue, car il est le liant de tout l'applicatif.

Pour ce qui est du développement d'interfaces web, il est en général pratique d'ajouter à « l'active data model » des propriétés relatives à l'état de l'interface. Par exemple un livre de la bibliothèque n'est plus disponible, il ne faut donc pas l'afficher dans le stock. On rajoute donc au « book » la propriété « book.visible : false », qui pourra être interprétée rapidement par la bibliothèque qui gère le DOM. Et en réalité tout dépend de votre technologie, cet ajout étant optionnel, mais toujours possible. On voit par là que le data model n'est pas un carcan, mais une base de départ qui peut s'adapter à toutes les situations. Attention cependant à ne pas rendre « l'active data model » finalement illisible, pensez toujours à structurer proprement vos propriétés et méthodes.

On voit aussi que l'organisation d'un développement requérant plusieurs développeurs sera avantagé par le partage d'un même data model, qui n'est rien d'autre qu'un référentiel commun. Il est en effet possible de distribuer les charges de développements en modules indépendants, chacun traitant d'une partie du data model actif, et pour autant chaque programmeur saura très exactement où il intervient au sein du projet global.

Notez enfin une chose importante, le data model que je décris est immédiatement intégrable à une base de donnée « no SQL », sans filtre aucun. Il est de même nature qu'elles et s'y intègre naturellement, nativement, puisqu'il est un objet.

Message aux Chefs de Projets

Si vous respectez ces conseils, et que vous utilisez une bibliothèque comme Angular, React, Damo, etc., vous parviendrez à développer de façon très rapide. Ces bibliothèques front-end modernes sont fondamentalement structurées sur une arborescence objet, leur adhésion à votre objet data model est dès lors native, immédiate. Dans le cas d'Angular par exemple, une fois le data model mis à disposition du scope (par un service par exemple), tout le travail se fera sur la programmation des tags HTML, et très peu en programmation javascript, sauf application complexe bien sûr. Les bugs sont rares, les développements sont factorisés, il n'y a pas d'incompréhension des intervenants, le dialogue avec l'utilisateur est facilité, tout va plus vite et plus simplement.

En revanche cela vous contraindra à réfléchir avant d'agir, à ne pas vous lancer tête baissée dans le développement, mais d'avoir au préalable une vision globale de toutes vos contraintes. Il faut prendre le temps, avec l'utilisateur, de bien définir votre data model commun, et ce n'est pas toujours simple, comme je le disais plus haut. Mais rassurez vous, ce que vous perdrez ici, vous le gagnerez au centuple au cours du développement. On ne peut automatiser que ce qui est structuré, et donc plus vous structurerez en amont, et plus vous automatiserez, et donc gagnerez en tout. C'est cela dont il est question dans la constitution d'un data model.

Quelques user stories

Chez un constructeur automobile français, j'ai réécrit en 15 jours (WE compris) le travail de trois développeurs pendant un an, non pas que je sois un génie (même si je le regrette =;o), mais simplement parce que j'ai conçu un vrai data model applicatif, et que c'est l'idéal pour Angular. Le côté front-end rapatriait des données du serveur, puis l'application n'avait qu'à afficher (à part un ou deux clics et enter par ci, par là qui écrivaient sur le serveur en ajax). Au total, à part l'installation du framework Angular, toujours aussi lourd et rébarbatif, il n'y avait plus rien à faire, sauf bien sûr une mise en ordre des variables appelées dans les templates HTML angularisées. Les scopes d'Angular étaient vides, il suffisait de passer le data model en service, et il était directement utilisable pour la programmation du DOM, dans tous les scopes, en two-way data binding.

Ma dernière création, funKTest (voir mon billet précédent), à base d'Angular, c'est une semaine de travail grâce au data model (ok, le look est affreux, je ne suis pas graphiste =;o). Mais c'est avant tout le fruit d'une réflexion sur les besoins des entreprises qui souhaitent se lancer dans les tests fonctionnels, et dans lesquelles j'ai pu intervenir. Oui, cela aussi, je veux dire « le métier de testeur fonctionnel », peut-être structuré dans un data model, et aboutir à un logiciel : funKTest. J'ai bâti, à force d'interviews de ces entreprises sur leurs besoins métiers, le data model correspondant. Ce dernier s'est avéré tellement élémentaire que j'en ai créé un générateur de codes de test (Protractor) universel, utilisable pour tous les sites http(s). Cela fait partie des avantages non prévus de la structuration en data model, grâce à cet exercice, vous n'êtes pas à l'abri de réaliser parfois, contre toute attente, une économie drastique.

La version 9 d'OceanVirtuel, un mois de développement seulement, quant il m'en fallait 4 sans data model bien conçu. C'est un applicatif extrêmement complexe. Cartographie à multiples couches actives, moteur météo sur toute la planète, à 1/2 degré de maille géographique et 6 altitudes, massive computing data, noSQL database, responsive for all terminals, intégrations de nombreuses bibliothèques tierces, ... Tout cela s'éclaircit, se structure et se simplifie avec le fil rouge d'un data model digne de ce nom. Cela me permet d'affirmer que le data model est une solution idéale à l'intégration de bibliothèques tierces. Dans ce cas une simple fonction de filtrage, entre leur data model et le votre, est nécessaire pour les intégrer.

Je vous signale enfin ma bibliothèque, Damo.js, qui s'appelle ainsi car « Da(ta)mo(del) ». C'est un Angular, développé en Jquery (pour ôter tout le côté abstrait, inutile, et absconse d'Angular), qui se fonde sur une structuration des données comme celle que je viens de vous décrire. Je vous laisse en lire la documentation pour en savoir plus. C'est avec Damo que fonctionne OceanVirtuel V9, application complexe s'il en est. J'applique donc mes solutions à ma pratique, et je crois que les skippers des « Vents du Globes » en sont très satisfaits (à l'heure où j'écris ces lignes =;o).

Je ne saurais trop vous prévenir que ce qui va arriver demain matin en matière d'applicatif web sera vif, cinglant, rapide, incontrôlable et sans pitié. Et le lendemain sera pire. Votre capacité à vous adapter, vous interconnecter, vous intégrer, sera cruciale. Sans maîtrise de vos data model, vous n'aurez tout simplement pas le temps de vous adapter. Et la nature est ferme sur ce principe : pas adapté = éliminé.

Restant à votre disposition si vous souhaitez en savoir plus,
Cordialement,
Hervé

Aucun commentaire:

Enregistrer un commentaire