Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

L'officier dans la tranchée

Publié par Jean-Francois Gilbert le vendredi 5 juin 2015 à 00:00

Trench

THE PORTUGUESE ARMY ON THE WESTERN FRONT, 1917-1918, Imperial War Mueseum (http://www.iwm.org.uk/)

Récemment, j'ai eu une conversation intéressante avec un collègue à propos du rôle d'architecte organique. À son avis, l'architecte organique n'a pas besoin d'être au courant des détails d'implémentation, des dernières techniques ou frameworks. Bref, il n'a pas à "mettre les mains dans le code". Toujours selon lui, une bonne éducation à l'université, une solide compréhension de la programmation orientée-objet, des bases de données et d'UML suffisent pour faire la conception d'un système complexe. Il s'avère que je suis profondément en désaccord avec ces affirmations. Je vais illustrer mon point avec une analogie militaire.

Imaginez un instant que vous receviez les ordres d'un officier. C'est un grand stratège, mais ses derniers faits d'armes remontent à la guerre des Boers ! Il a fait ses preuves avec la cavalerie mais il ne connait rien à la guérilla urbaine et aux drones. Ou encore, il est au fait des avancées technologiques militaires mais il observe toutes les batailles terré dans son quartier général. Il vous a bien indiqué où se trouvent les ennemis et comment les vaincre, mais sa distance du champ de bataille ne lui donne pas la même perspective que vous de l'évolution du combat. De plus, il ne s'est jamais approché d'une tranchée ou tenu une arme dans ses mains.

D'un autre côté, vous avez un officier qui est avec vous dans les tranchées. Tous les jours il combat à vos côtés, sous la pluie, dans la boue, mangeant la même bouffe infecte. Il a utilisé les mêmes armes que vous, a connu la douleur et la peur.

Qui entre ces deux officiers a le plus de crédibilité aux yeux des troupes selon vous ? Qui entre ces deux officiers risque d'avoir le support de ses compagnons d'armes quand une décision difficile sera prise ?

Je sais, l'analogie n'est pas parfaite. En réalité, je crois que ça prend un mélange entre ces deux officiers. Il est important d'avoir un plan d'ensemble. Et le fait d'avoir une perspective différente de celle des développeurs peut s'avérer être un avantage. Cependant, on dit souvent que le diable est dans les détails. C'est tellement vrai en développement logiciel ! Un plan qui, de haut niveau, semble tenir la route peut être bousillé par une petite chose qui s'appelle "la réalité". Une réalité qui se présente sous la forme de problèmes d'intégration avec un système externe, de performances inadéquates, de l’apprentissage difficile d'une nouvelle technologie. Autrement dit, des problèmes qui surviennent au niveau microscopique, au niveau de l'implémentation. Un architecte organique fort techniquement sera en mesure de comprendre et solutionner ces problèmes. Ça lui donnera une valeur bien plus grande aux yeux de l'équipe et de l'organisation. 

Mots-Clés :

Classique du développement logiciel: Head First Design Patterns

Publié par David Beaumier le mercredi 10 décembre 2014 à 13:06

J’ai remarqué récemment que le livre «Head First Design Patterns » a reçu une mise à jour pour souligner son 10ième anniversaire de publication. Premièrement, il faut savoir que ce n’est en aucun cas le livre le plus avancé sur le sujet, mais comme le dit cet internaute « Si tu ne comprends pas les Design Patterns après cela, c'est alors peine perdue ».

Couverture Head First Design Patterns

Il s’agit donc d’un livre tout indiqué pour le p’tit nouveau de votre équipe ou pour un collègue qui ne connait pas encore les patrons de conception et qui souhaite s’initier au sujet. Présenté dans le format ludique associé à la série Head First (approche néanmoins très sérieuse), c’est une lecture agréable et somme toute légère si on considère le sujet. Le livre propose tout d’abord une introduction au concept de « patrons de conception », sans prendre pour acquis que le lecteur est un programmeur OO ceinture noire. Les principes OO liés aux patrons sont présentés au fur et à mesure, de façon à ce que le lecteur possède les bases requises pour bien comprendre comment mettre en oeuvre le patron.

Un des aspects intéressants de ce livre est l’abondance d’illustrations. Celle qui suit est un exemple typique du style utilisé par l’auteur, qui, il faut l’avouer, est assez différent de celui retrouvé dans la majorité des livres traitant du même sujet.

Exemple Diagramme HFDP

Ce classique propose, pour son édition renouvelée, des exemples basés sur les nouveautés de Java 8. Ceci dit, il est tout aussi pertinent pour ceux qui développent sous d’autres plateformes, telle que .NET. Les exemples sont simples et faciles à comprendre.

 Il est impressionnant de voir que plus de 10 ans après sa parution, il se retrouve au #1 des ventes de sa catégorie (au début de décembre 2014). C’est vraiment ce qu’on appelle un incontournable!

Ranking HFDP

Version française

Une édition française de ce livre a déjà existée, avec le titre « Design patterns : Tête la première », mais elle était basée sur l’édition originale et n’était disponible qu’en e-book (PDF). L’éditeur ayant fermé ses portes depuis, elle ne semble plus disponible pour achat.

D’autres billets qui pourraient vous intéresser

Pour aller plus loin

Si vous souhaitez approfondir le sujet des patrons de conception, je vous recommande la formation Concepts orientés-objet avancés appliqués au développement agile présentée par mon collègue Félix-Antoine Bourbonnais.

Agile Tour 2014 - Architecture Agile et développement durable

Publié par Félix-Antoine Bourbonnais le mardi 11 novembre 2014 à 00:00

Description

Beaucoup d’équipes ont embrassé Scrum sans considérer l’architecture nécessaire pour soutenir un tel rythme et minimiser la dette technique. Comment adopter une architecture émergente, malléable et facile à changer? Bref, comment faire du développement logiciel durable? Principes SOLID, patrons de conception d’entreprise, architecture émergente et pilotée par le domaine (DDD) sont au menu.

Présentation

DDD vs Clean Architecture: un trop court résumé...

Publié par Félix-Antoine Bourbonnais le jeudi 7 août 2014 à 00:00

DDD vd Clean Architecture

La semaine dernière, Anis Berejeb a publié un billet sur l’architecture par cas d’utilisation. Suite à mon commentaire, il y a eu un petit débat concernant la différence entre DDD (Domain-Driven Design) et Clean Architecture. La question portait surtout sur la place des cas d’utilisation (Jocobson) en DDD.

Mon commentaire se résumait à dire que la conception par les cas d’utilisation n’est pas la seule façon d’atteindre les objectifs de séparation de concepts, inversion des dépendances, séparation de la logique de la persistance et de l’affichage, etc.

Disons-le immédiatement, il est difficile de tracer une ligne claire, car DDD et Clean Architecture sont, sur plusieurs aspects, orthogonaux. Mais risquons-nous... 

La portée  

DDD est de plus haut niveau que Clean Architecture qui est plus technique. Ainsi, une bonne partie de Clean Architecture se trouve à être un moyen architectural, parmi d’autres, pour appliquer la philosophie DDD. 

DDD vise la modélisation de problèmes complexes dont la logique d’affaires est importante. DDD va aller toucher la modélisation du domaine et la communication avec des experts du domaine (établissement d’un langage commun, contextes ...). C’est donc beaucoup plus qu’un modèle architectural (technique), c’est aussi une philosophie de modélisation, voire une façon de réfléchir.

L’accent 

Dans l’approche, la principale différence en est une d’accent (focus) lors de la conception. CleanArchitecture focalise sur les cas d’utilisation alors que DDD focalise sur la modélisation du domaine (les entités, valeurs, …).

Ainsi, les praticiens de Clean Architecture semblent plus enclins à encapsuler les cas d’utilisation dans un « Interactor ». DDD risque de préférer intégrer les cas d'utilisation au domaine (dans les entités, Domain Service ...) puisque c’est là qu’est portée toute l'attention.

Où placer la logique

En CleanArchitecture la question sera possiblement: « est-ce indépendant de l’application? » La tendance sera donc d'en mettre plus dans « l’Interactor » et de mettre dans le modèle seulement ce qui est indépendant de manière évidente.

DDD a aussi le même concept (dépendant ou indépendant), mais aura tendance à poser la question à l’inverse en considérant d’abord le domaine, ce qui va avoir comme conséquence de placer d’avantage de code dans le domaine (notamment dans les entités) et de fragmenter le cas d’utilisation. DDD a aussi le concept du Bounded Context qui entrera en jeu dans cette décision en limitant les dérives de l'approche.

À l’inverse, Clean Architecture aura tendance à créer des entités avec moins de logique et d’en placer plus dans les « Interactors ». Évidemment tout cela est du cas par cas, mais on parle de tendance naturelle ici...

À noter qu’avec DDD, la couche d’Application Service en est une d’orchestration, mais pour les considérations plus techniques (ex.: les transactions) ou encore pour orchestrer sur plusieurs contextes (Bounded Contexts). On pourrait la voir comme une couche de cas d’utilisation, mais avec moins de détails (rappelez-vous que la définition et le découpage ne sont pas exactement pareils dans les deux approches).

Les services du domaine (Domain Service) auront aussi un rôle d’orchestration, mais pour ce qui ne peut être intégré à une entité.

Exemple 

Prenons l’exemple du paiement d’une commande illustré par ce graphique qui montre une conception plus orientée cas d’utilisation (Clean Architecture). En DDD, il serait plus probable de voir la méthode « payOrder » initialement placée dans l’entité « Order ». Cela ne veut pas dire que ça ne changerait pas dans le temps par contre. 

Pour un exemple en DDD, consultez le code de l’application DDD Samplecette formation en ligne ou encore le livre de Vaughn Vernon.

Avantages et inconvénients

Voici quelques avantages, inconvénients et risques naturels associés au «focus» différent. 

Quelques avantages de la modélisation par cas d’utilisation (Clean Architecture):

  • Cas d'utilisation identifiables facilement et clairement énoncés;
  • Facile de déployer les entités indépendamment et de les réutiliser dans plusieurs applications de l’entreprise (note: DDD a les concepts de Bounded Context et Shared Kernel pour balancer);
  • Plus facile de comprendre le cas d’utilisation rapidement.

Quelques risques:

  • Domaine moins structuré et plus « vide » ;
  • Réutilisation de la logique pour plusieurs cas d’utilisation plus complexe (ou dangereuse);
  • Danger de tomber dans un domaine anémique ou de faire de la programmation procédurale involontairement;
  • Danger de concevoir par les données les entités plutôt que d’avoir un domaine consistant représentant bien la logique du domaine d’affaires;
  • Moins d'outils concernant la manière d’arriver à modéliser son domaine, d’avoir un langage commun, etc;
  • Risque de complexité plus élevé dans « l’Interactor », plutôt que d’abstraire cette complexité dans le design du domaine.

 Et inversement pour DDD… Évidemment, comme toujours, tout est une question de compromis en fonction de son contexte. C’est ça l’art du développement logiciel !

Résumé et recommandations: complémentarité!

En résumé, tout est une question d’accent (focus). DDD focalise sur le domaine, CleanArchitecture sur les cas d’utilisation. Non pas que DDD ne considère pas les cas d’utilisation, mais ce n’est pas sur ça qu’est placé l'accent!

Si vous êtes dans un domaine de TI avec beaucoup de règles d’affaires, DDD vous sera probablement très utile pour modéliser le domaine, le découper, établir votre langage commun, etc. Vous pouvez certainement y combiner les techniques de Clean Architecture pour ce qui est de l’inversion des dépendances, de l’interfaçage, etc. 

À mon avis, l’important est de se souvenir qu’ils peuvent êtres complémentaires et que ce sont des techniques, pratiques et concepts à avoir dans sa trousse à outils. 

Donc comme le dit Bob Martin lui-même: « It's not really important which of the two [Use Case, Domain] drives […] It is the designers job, in each case, to prevent that muddle. » [2]. 

Après tout, les deux poursuivent le même but ultime! Tous s’entendent sur la nécessité de séparer la logique d’affaires des préoccupations techniques, l’inversion des dépendances, de rendre visible le domaine d’affaires plutôt que les frameworks et outils, etc.

Références 

[1] Comparaison selon Bob Martin:
https://groups.google.com/d/msg/clean-code-discussion/oEFEWq8qdFQ/i0gsi3eU5VoJ

[2] Lequel choisir selon Bob Martin:
https://groups.google.com/d/msg/clean-code-discussion/xm8QtaYwl3k/LWgFBs3erd0J

[3] Réponse connexe concernant l’application layer en DDD:
https://groups.yahoo.com/neo/groups/domaindrivendesign/conversations/messages/24325

UML, agilité, et rétroaction

Publié par David Beaumier le vendredi 4 octobre 2013 à 16:17

Depuis longtemps j’utilise UML comme formalisme pour exprimer certains concepts et favoriser une compréhension commune des personnes impliquées dans le développement d’une fonctionnalité.  Je suis partisan d’un UML pragmatique et des principes de modélisation Agiles.

Il m’arrive régulièrement d’utiliser un bloc-note ou un tableau blanc pour jeter les bases d’une conception. À ce moment-là, il est clair pour toutes les personnes impliquées qu’il s’agit d’une conception initiale, d’un draft quoi.  Personne ne s’attend à ce stade-ci que tous les cas de figure aient été envisagés dans les moindres détails. Il y a une entente tacite sur le niveau de précision du diagramme.

Cependant, il arrive parfois qu’il soit plus pratique d’utiliser un outil de modélisation pour réaliser un diagramme UML. Personnellement, j’apprécie beaucoup Enterprise Architect de Sparx Systems que j’utilise depuis nombre d’années. Avec le temps, j’en suis toutefois venu à  constater que l’entente tacite qui existe lorsque je modélise sur papier ou au tableau ne tient plus vraiment lorsque je produis un modèle informatisé. Les gens plutôt ont l’impression d’avoir devant eu un « plan » précis de ce qui doit être fait.

L’analogie qui me vient à l’esprit est celle d’un plan de bâtiment. Un plan fait avec un logiciel de DAO semble dégager une impression de précision et d’achèvement alors que, dans les faits, il peut être aussi préliminaire qu’un plan à main levée.  Dans l’exemple ci-dessous, le plan fait par DAO semble plus achevé. Pourtant, avec l’esquisse je pourrais déjà débuter les travaux puisque j’ai des mesures. Comme je suis un menuisier Agile, et qu’ainsi ma priorité est de satisfaire mon client en lui livrant rapidement des fonctionnalités, je suis en mesure de débuter un mur et l’assemblage des chevrons dès maintenant.

Plan fait avec un logiciel de DAOPlan fait à la main

J’ai déjà vécu un problème similaire avec les interfaces graphiques  à l’époque où j’utilisais des outils de conception visuelle se rapprochant énormément du produit final. Trop souvent les utilisateurs avaient l’impression que la fonctionnalité était quasiment terminée, tellement la maquette était réaliste. Bien souvent cela avait comme conséquence de limiter l’échange d’idées puisque les parties prenantes voyaient la solution comme déjà établie. Aujourd’hui, j’utilise l’outil Balsamiq Mockups pour produire des maquettes qui ne laissent aucune place à l’ambigüité quant à leur niveau de précision. Ci-dessous, un exemple de ce que permet de faire Balsamiq. C’est vraiment merveilleux car les utilisateurs sont conscient de la facilité à modifier un tel design et sont plus enclins à proposer des améliorations.

Maquette Balsamiq

C’est tout récemment que j’ai eu une révélation sur les diagrammes faits dans Enterprise Architect : pourquoi ne serait-il pas possible de leur donner un style à la Balsamiq? De cette façon il serait évident pour tout le monde qu’il ne s’agit pas de modèles complets et finaux, mais plutôt  d’une base pour débuter le travail. Quelle idée géniale, me dis-je! Avant de soumettre l’idée aux gens de Sparx Systems, j’ai tenté une petite preuve de concept en modifiant légèrement l’apparence des polices de caractères d’un diagramme. Après quelques minutes d’expérimentation, j’ai découvert les options « Hand Drawn » et « Whiteboard Mode » dans les propriétés du diagramme. Wow, c’est déjà là… Trop génial!

Ea Handdrawn Ea Whiteboard
Mode dessin à la main (Handdrawn) Mode tableau blanc (Whiteboard)

Voilà donc, d’un simple clic on peut obtenir une apparence « napkin » pour nos diagrammes. Tout comme avec Balsamiq, il devient alors possible de restaurer l’entente tacite sur la précision du diagramme tout en profitant des avantages d’un outil de conception visuelle. Non seulement cela repositionne les échanges au bon niveau,  mais j’ai en plus l’air d’être super bon en dessin.

Bonne conception!

Archive