Je vais vous présenter la DDD:
Display Driven Development après ce petit laïus:
Alors que j'étais sur deux projets (voire trois) projets, je me suis aperçu d'un détail troublant: Il est parfois difficile de saisir "le futur" du projet. (élément troublant quand on doit assurer un suivi).
Il me fallait comprendre pourquoi sur un projet, nous "voyons" les moindres détails et sur l'autre, nous ne sommes pas capables de déterminer ce qu'on va faire le lendemain même.
J'ai mis du temps à comprendre, je crois l'avoir saisi lors de la lecture d'un article sur un cinéaste qui refusait de réaliser des films sans que l'idée ne soit de lui.
Je crois que ce problème vient simplement d'un déchargement de la conception en elle-même. D'un côté, nous avons des concepteurs
externes à l'équipe (le client en général), et de l'autre les concepteurs
internes à l'équipe.
Après réflexion, je pense que nous devons laisser le client assez éloigné de la phase de développement et de la conception; Ceci afin que les développeurs accaparent le produit, le développement et surtout le suivi: Décharger la conception du développeur, il ne devient plus qu'un pisseur de code. A la longue, il sera démotivé et n'aura plus qu'un principe: Arriver à la fin de l'itération le plus rapidement possible.
De part cette démotivation, le développeur n'aura plus aucune vision à long terme du développement: Du fait d'un déchargement de la conception, le développeur ne peut pas imaginer le futur du produit. Il a laissé cela aux concepteurs ... qui ne sont pas les codeurs.
On peut y voir une forme de gymnastique intellectuelle plaisante pour le développeur. Lui enlever cela lui fait perdre 60% de son boulot (les 40% sont la découverte de facebook et de twitter
Comme disait une personne qui se reconnaitra:
« J'ai embauché des ingénieurs et des développeurs; Si j'avais voulu des copistes de code, j'aurais embauché des secrétaires »
Attention, je ne dis pas qu'il faut écarter totalement le client, il faut simplement le remettre dans son contexte: il ne sait parfois pas véritablement ce qu'il veut et comment il le veut. Le mieux est de le "conduire" dans sa démarche intellectuelle.
Autrement dit, le plus simple est d'avoir une ébauche d'idée: « Je veux que l'application fasse ceci ». Durant cette phase, on ne décrit pas tout le logiciel dans ces moindres détails, mais seulement ce qu'il doit faire au final. Une sorte d'explication abstraite sur le pourquoi-du-comment. (si vous me suivez plus, bippez hein!)
Lors des conceptions, nous avons plusieurs techniques de développement, la méthode à l'arrache, les méthodes pyramidales de développement (on écrit un cahier des charges, les développeurs pissent le code et on se revoit dans 6 mois), ou alors les méthodes agiles.
« Maintenant, nous allons changer la façon de faire ici. Nous devrons faire/être [en méthode] Agile »
« Cela veut dire quoi ? »
« Rien ne change véritablement, sauf que maintenant les managers, les designers et les architectes ont une excuse pour tout changer le vendredi en fin de journée... »
Avec la méthode agile, vous avez une pratique qui consiste à diriger le développement par rapport aux jeux de tests. Ce principe est fortement intéressant sur plusieurs aspects. Déjà nous avons une sorte de container qui permet de délimiter le périmètre de développement et - si des modifications étaient apportées - de découvrir des problèmes inhérents à l'ajout de code (ou sa modification).
Ceci dit, après en avoir effectué pendant quelques temps, j'ai pu constater certains problèmes à ce genre de concept. Ils existent donc des limitations et leurs implications dans le concret peut parfois poser problème.
Si je lis Wikipedia, les TDD (Test Driven Development) sont :
En écrivant les tests d'abord, on utilise le programme avant même qu'il existe. On s'assure ainsi que le code produit est testable unitairement. Il est donc impératif d'avoir une vision précise de la manière dont on va utiliser le programme avant même d'envisager son implémentation. Cela évite souvent des erreurs de conception dues à une précipitation dans l'implémentation avant d'avoir défini les objectifs.
Ce qui me dérange dans ce concept, c'est le fait que les tests dirigent le "comment" on développe nos applicatifs.
Je vous explique le concept, dans une méthode TDD classique, vous codez d'abord le test qui teste la fonction, puis après vous codez la fonction. Cela est bien dans un système parfait, ou autrement appelé: théorique. Dans le concret, nous sommes parfois bloqués par des impératifs :
- Technologiques
- Conceptuels
- Temporels
Technologiquement: vous pouvez vous retrouver devant une impossibilité technologique que vous n'aviez pas estimé.
Conceptuels: le code produit ne correspond plus à vos attentes, il est tellement dirigé par le test que vous avez du produit du code alambiqué afin qu'il rentre dans "les cases" du test.
Temporels: vous perdez deux fois plus de temps, entre coder le test, l'implémenter la fonction ... remodifier le test.
Par exemple, en C/C++, lorsque je code mon test, je voudrais que ma fonction nécessite une structure en argument et me redonne un autre type de structure complètement différent. Je commence à coder mon test, la fonction est belle, le test est beau: tout est parfait. Je code maintenant ma fonction, j'implémente la structure d'entrée, j'implémente la structure de sortie. Je compile le tout: zut, ca ne marche pas.
Pour des raisons diverses
(mauvaises connaissances du langage, bug dans le compilateur, le jugement dernier, que sais-je..), votre code pondu ne marche pas dans le contexte idéal que vous avez établi.
Vous modifiez donc votre code au fur-et-à-mesure pour que celui-ci fonctionne
(par exemple, vous abandonnez la structure, vous mettez un autre type de variable, etc...), vous vous retrouvez donc avec un test qui n'est plus synchronisé avec le code produit. Vous modifiez donc le test pour le rendre compatible. Vous avez donc deux problèmes: votre fonction qui était parfaite (pour ce que vous vouliez en faire), ne l'est plus à cause du test
(certains me rétorqueront que le problème vient peut-être d'un élément entre le clavier et la chaise).
Un autre aspect qui me dérange, c'est d'être conditionné par le test. Ainsi, si une technologie ne possède pas de méthode ou de moyen de test, la technologie est écartée.
Nous avons donc des concepts ou des fonctionnalités qui sont entièrement écartées à cause de leurs "manquements" dans un autre domaine.
Nous pourrions évoquer la technologie Flash où, sauf erreur de ma part, il n'existe pas de méthode afin de tester le résultat final
(il existe AsUnit, mais il ne teste que les fonctions et non l'affichage en lui-même: si je clique ici, cela fait cela).
Bien entendu, vous me rétorqueriez qu'il existe toujours une méthode pour tester. Certes. Mais à quel prix ? Je doute que le client accepte une itération pour de la recherche pure qui ne lui apportera rien en production et surtout sur le terrain.
Les tests sont très utiles lorsque le code et le produit ont besoin d'être parfaitement contrôler pour éviter tout problème après modification. Ceci dit, je préconiserais une autre approche du TDD: L'after-TDD (avec un zeste de clubbing derrière).
En gros, vous écrivez vos fonctions, classes, structures et l'approche fonctionnelle, puis après, vous développez les tests afin de "cloisonner" le produit. Cela permet d'être sûr des entrées, sorties et du comportement de l'application développée.
DDD: Les Développements Dirigés par le Dessin (ou en anglais: Display Driven Development)
Nous voilà enfin à la partie intéressante
Sur plusieurs projets, j'ai pu constater des différences de timing en terme d'implémentation et de résultat final pour le client (sauf si la demande n'a pas pu être comprise ou expliquée correctement, auquel cas, c'est un autre débat):
Dans
une méthode classique agile, on code la fonctionnalité, on l'applique sur un affichage classique et lambda développé pour l'occasion pour les besoins de la présentation client et surtout pour l'affichage des données que le client a demandées. Ce dernier juge du travail et évalue la pertinence;
Généralement, le client voudra toujours modifier l'affichage qu'il trouve trop simpliste ou pas assez à son goût. Il voudra donc toujours "plus du comme-ci, plus du comme-cela". Les développeurs modifieront donc l'affichage pour les besoins clients.
Manque de chance, cela "casse" une partie de la fonctionnalité ou comment cela s'imbrique au sein de l'application. On se retrouve donc avec une désynchronisation entre l'affichage et les fonctions internes: Nous avons finalement
perdu du temps pendant la phase de développement, puis après la phase de modification. Vous rajoutez - à cela - la démotivation de devoir faire de nouveau, si finalement le client change d'avis sur le type d'affichage qu'il voulait.
Cela arrive plus souvent qu'on ne le pense: Un client veut une information en théorie, mais en pratique, il ne la trouve plus forcément pertinente, voire préfère un affichage complètement différent de ce qu'il avait en tête.
Il faut aussi prendre la vérité en pleine face: les "clients" ne veulent absolument pas savoir comment est construite l'application. Vous savez, votre belle fonction qui fait des trucs incroyables; Et bien cela va faire délirer que ... vous (voire votre collègue, et encore ...
C'est dommage à dire, mais cela est naturel: L'être humain normalement constitué ne veut qu'une chose: Du visuel. Ce n'est pas pour rien que les produits Apple marchent bien (je parle notamment des iPhones et autres iPods qui ont 10 fois moins de fonctionnalités que le constructeur concurrent de base)
Il faut donc probablement avoir une autre approche du développement plus graphique...
Voyons donc le problème (et donc la solution) d'un autre sens:
Pourquoi ne pas voir la direction du développement directement avec une vision utilisatrice: on "design" l'interface en amont et avec le client.
Ainsi on voit tout de suite:
- Ce que le client veut
- Le client voit de suite si le résultat est satisfaisant ou pas du tout
- Cela permet surtout d'avoir un vecteur de communication standard
- Les erreurs et mauvaises interprétations sont mieux détectées
(mieux ne veut pas forcément dire toute)
Cela peut sembler étrange, mais finalement pas tant que cela. Quand un projet de film arrive, on fait un storyboard (papier, voire des premiers shots) et cela n'étonne personne.
Pourquoi ne pas faire aussi dans l'informatique ?
Attention, quand je dis "on design l'interface", ce n'est pas dessiner rapidement trois rectangles et de définir leurs buts. Non. Le DDD va plus loin. Votre graphiste (voire un des développeurs qui manie bien le Photoshop/Gimp) va dessiner clairement les différentes interfaces.
Au final, la
planche doit être à peu de choses près un screenshot de votre prochain applicatif. Cette dernière validée, on passe à la phase de conception: on ne code aucune fonctionnalité. On ne fait qu'implémenter l'interface "photosophée" pour une interface
action-live (en gros, on peut cliquer dessus).
UPDATE: De plus cela vous permet de tester rapidement les limitations de votre interface graphique sans avoir à tout refaire. Ainsi si vous aviez
designé un élément mais qu'il est -finalement- impossible de le faire (limitation technologique), vous n'avez revenir voir le client en lui proposant des modifications dans votre phase "screenshot". Grâce à cela, vous n'aurez pas à re-développer une partie de votre interface graphique et de recabler les fonctions-datas (dans une phase de conception normale).
En HTML, sortez vos plus beaux CSS, DIV et Jquery. En application graphique, sortez votre plus belle librairie graphique (GTK, Cairo, OpenGL,...). Et ainsi de suite ...
Sitôt l'interface terminée, le client (et vous-même) pouvez dès à présent "utiliser" l'application:
Si on clique ici, cela ouvre ceci; Dans cette partie-là, on voit les informations et les données (factices bien entendu)
Sitôt terminé, on a plus qu'à remplacer les occurrences visuelles et conceptuelles "factices" par le résultat de votre code.
Ainsi, on ne développe que les fonctions dont on a besoin pour le rendu visuel: plus besoin de développer une fonction qui va récupérer X informations (au cas où le client change d'avis), mais une seule. Et le lien entre controller/model et le visuel sera beaucoup plus rapide et moins frustrant pour les deux parties.
Cette méthode utilisée sur quelques projets, je me suis aperçu que le rendu final et la rapidité de développement avait été accrue.
Et au final, le client était détendu du slip
UPDATE: Petit worflow du DDD en pratique:
Note: si vous avez des observations sur vos méthodes de développement, sur la méthode indiquée ici-même, des contre-argumentations, des "jetages-de-tomates-pourries"; ou bien si vous remarquez des fautes, n'hésitez pas, toussa ... commentaires .. toussa. ("lâchez vos coms'" comme on dit sur skyblog 
« Bonjour mââââdaâââme ! »
« Je suis en r'tard, en r'tard, en r'tard !!! »
Derniers commentaires