InfOsaurus - Commentaires

TDD et Clean Architecture, partie 1 - Guillaume

Guillaume — Fri, 30 Mar 2012 18:55:54 +0200

Effectivement ta réflexion est intéressante, je n'avais pas vu les choses comme ça.

C'est toujours difficile de placer le curseur au bon endroit, trop KISS on risque en effet de se retrouver avec de gros chantiers à retardement, pas assez on risque de faire de la premature optimization ou du moins du premature design...

En ce qui concerne la comparaison d'instances de figurines, je ne pense pas avoir à en faire car même si ce n'est pas dit explicitement, je suis parti sur Figurine = référence catalogue/modèle de figurine dans une collection et pas Figurine = unité vendue au détail (SKU dans le jargon). On a donc une seule instance de Figurine associée à une quantité dans un panier, et pas X instances à comparer entre elles, ce qui nécessiterait effectivement du mocking quand on veut tester le panier en isolation.

TDD et Clean Architecture, partie 1 - Sylvain

Sylvain — Thu, 29 Mar 2012 23:58:19 +0200

Loin de moi l'idée de vouloir troller…

Je comprends tes arguments et c'est plutôt d'ailleurs comme ça que j'ai l'habitude de faire.

Ceci dit, dans mes réflexions d'amélioration, je commence à penser que certains changements sont intéressants très tôt.
1. parce qu'ils apportent de la lisiblité ;
2. parce qu'ils facilitent l'évolution du code.

J'en ai parlé pour l'introduction de Figurine qui aurait pu être fait tout de suite. Son introduction plus tard a pris plus de temps.

Et bien, je me demande si l'introduction de l'abstraction, comme tu l'as dit, ne serait pas intéressante maintenant. Par exemple, si ton implémentation du panier dépend de la capacité de 2 figurines à pouvoir se comparer, alors il me semble important que cela apparaisse sur l'interface. D'où l'importance de cette interface. Et du coup, il faudra la doubler dans les tests…

C'était juste une réflexion et j'attends (toujours) la suite avec impatience.

TDD et Clean Architecture, partie 1 - Guillaume

Guillaume — Thu, 29 Mar 2012 00:53:48 +0200

Aie aie aie... je sens d'ici un débat trollesque sur ce qui est unitaire ou pas ;)

Plus sérieusement, si tu fais allusion à mettre une interface au-dessus de Figurine et mocker à chaque fois, non je ne le fais pas systématiquement et je considère quand même les tests du panier comme unitaires dans ce cas précis.

Pourquoi ? Tout simplement parce que les tests du panier n'utilisent jamais de méthode de Figurine, tout au plus le constructeur et pour 2 tests une comparaison d'instance. Ca me parait suffisamment basique pour être considéré comme fiable ("don't test the platform"). D'ailleurs on peut mettre à peu près n'importe quoi dans le constructeur et les tests passent quand même (je viens de vérifier) donc ça montre bien que le constructeur est juste un prétexte à créer une instance de Figurine dont on se fiche du contenu. Dans la mesure où il fait le même travail qu'une doublure et où la construction d'une figurine est ultra-simple, je ne vois pas l'intérêt d'une doublure ici.

En revanche, dès que notre méthode A suppose la validité d'une méthode B d'une autre classe, j'estime qu'il faut isoler le test de la validité de A de la question de la validité de B, donc recours à une doublure. C'est justement ce que j'ai prévu de montrer dans la deuxième partie car les interacteurs, comme leur nom l'indique, communiquent avec beaucoup d'objets et ont pas mal de dépendances.

TDD et Clean Architecture, partie 1 - Sylvain

Sylvain — Wed, 28 Mar 2012 22:43:31 +0200

Hello,

2/ je suis d'accord et un peu extrémiste ;-) Je pense juste que l'on a tendance à dire tout le temps "c'est assez lisible" mais qu'avec des classes avec plus de sémantiques, c'est pas mal non plus : lisible ET évolutif.
Et note que, finalement, tu as dû l'introduire cette classe Figurine ;P

3/ Ben, il me semble que la plupart de tes tests du Panier utilise des instances de Figurine non ? Ce n'est donc pas "réellement" unitaire…

TDD et Clean Architecture, partie 1 - Guillaume

Guillaume — Tue, 27 Mar 2012 19:44:08 +0200

Salut Sylvain,

Je vais essayer de répondre dans l'ordre

1/ Tu as raison, dans le feu de l'action mon diagnostic du problème de figurine était mauvais ou du moins incomplet : j'aurais pu introduire n fois la même instance de Figurine dans la liste sans recourir à un dictionnaire. Mais la solution d'associer un produit à une quantité m'a paru plus élégante et plus raccord avec le domaine sur le moment, donc j'ai pris ce raccourci. Sans que mon cerveau percute tout de suite qu'il fallait du coup ajouter n fois la même instance et pas créer n instances ;)

2/ D'accord avec toi sur la primitive obsession, moins d'accord sur le code non expressif. Pour moi le code du kata était suffisamment clair comme ça, avec des méthodes comme AjouterFigurine("Tintin") on est loin d'un entier cryptique ou d'un code ésotérique sur 4 caractères. J'aurais certes pu refactorer dans ce sens mais j'ai dû faire des choix et m'arrêter de refactorer à un moment ;) J'ai d'ailleurs vu des implémentations du kata Harry Potter (celui d'origine) se baser sur des chaînes.

3/ Lequel ?

Merci pour ton retour en tout cas :)

TDD et Clean Architecture, partie 1 - Sylvain

Sylvain — Tue, 27 Mar 2012 14:45:03 +0200

Salut et merci pour cette vidéo.

Quelques petites questions…

Je ne suis pas certain d'avoir compris le changement de design de la liste vers un dictionnaire. Ton problème de départ semblait être la comparaison de Figurine. Puisque tu ajoutais n fois n Figurines avec le même nom, tu aurais voulu savoir si c'était la même figurine ou non. Après ton changement de design, il me semble que tu as eu le même problème et que du coup, tu as choisi d'ajouter n fois la même figurine. Si tu avais fait ce choix au moment où tu as rencontré ton problème, je pense que l'introduction du dictionnaire ne devenait pas nécessaire ?

Tu connais le "primitive obsession". Et bien je pense que tu l'as illustré parfaitement ;-)
En effet, si dès ton 1er kata, tu avais décidé d'introduire le concept de Figurine, simplement parce que tu manipulais le concept métier de Figurine, tu aurais gagné un peu de temps. Code expressif…

Dernière petite question. Il me semble que ton test de panier n'est pas unitaire puisqu'il dépend de Figurine, non ?

Bon courage pour la suite que j'attends avec impatience.

Tintin, course de haies et TDD - Guillaume

Guillaume — Sun, 18 Dec 2011 17:35:54 +0100

Merci pour ton retour. J'ai mis de la musique pour dynamiser le tout. Sans ça, je trouvais qu'on s'endormait un peu pendant les moments creux, déjà que je trouve ma voix pas terrible ^^

Je vais essayer de m'améliorer pour la prochaine ;)

Tintin, course de haies et TDD - Yotsumi

Yotsumi — Sun, 18 Dec 2011 15:40:52 +0100

Excellente idée cette vidéo.

Une petite remarque toutefois, la musique en arrière-plan... à éviter la prochaine fois ^^ C'est gênant pour la compréhension de tes explications.

J'avais fait le Kata Harry Potter 1 ou 2x ces derniers mois, je vais voir ta manière de faire plus en détail.

Tintin, course de haies et TDD - Guillaume

Guillaume — Thu, 01 Dec 2011 23:24:52 +0100

Dans ma version de Resharper, je n'ai le choix que de l'initialiser dans Current Member, Field initializer ou Constructor :(

Tintin, course de haies et TDD - Jean-Baptiste

Jean-Baptiste — Thu, 01 Dec 2011 07:14:26 +0100

Je confonds souvent les possibilités d'Idea et R#, mais dans Idea au moment du introduce field, comme endroit d'initialisation on peu choisir setup method.

Tintin, course de haies et TDD - Guillaume

Guillaume — Wed, 30 Nov 2011 19:57:33 +0100

Merci ;)

Tu as raison, pour le champ en fait j'avais essayé un Introduce Field mais sans succès. Au final j'ai trouvé, il faut juste mettre le curseur sur la variable pour que ça marche mais sans la sélectionner (bizarre).
Par contre pour l'apparition du SetUp j'ai pas trouvé, à moins de créer un snippet...

Tintin, course de haies et TDD - Jean-Baptiste

Jean-Baptiste — Wed, 30 Nov 2011 07:57:30 +0100

Bonne initiative parfaitement exécutée :)

Ma seule remarque serait qu'il me sembe que certaines de tes étapes de refactoring que tu fais à la main pourraient être faites par R# automatiquement . Par exemple la convertion en champs dans le test du panier et l'apparition du setup, ou l'introduction du paramètre dans la méthode calculMontantAvecReduction

L'auto-organisation : analyse d'un concept subversif - Guillaume

Guillaume — Sun, 19 Jun 2011 20:31:13 +0200

@goupils : Beaucoup de choses à dire sur ton commentaire, qui me semble plein de mauvaises interprétations et malheureusement révélateur de la perte de sens de ce qui faisait l'esprit des méthodes agiles, aujourd'hui noyé sous des tonnes de hype et de "marketing" agile...

Sur les contrats et la relation avec le client tout d'abord. Je suis d'accord que le cadre juridique des contrats client prestataire n'est pas du tout adapté à une démarche agile en France, en particulier celui du forfait. En revanche on dirait que tu blâmes la méthode alors que ce genre de problème est plutôt dû à des particularités budgétaro-financières rigides et abhérrentes ou à un client de mauvaise foi... On peut toujours dire que c'est comme ça, que les mentalités n'évolueront jamais, mais à ce compte là, ça ne vaut même pas la peine d'essayer de nouvelles méthodes pour rétablir la confiance entre client et prestataire puisque toute amélioration est impossible...

Sur la structure des organisations, effectivement une hiérarchie est nécessaire entre développeurs débutants, les confirmés, les experts... La présence d'un Scrum Master ne change rien à cela. Là où nos avis divergent, c'est sur la responsabilité individuelle. Sur le papier, c'est bien beau d'invoquer la notion de "chef responsable" pour justifier une structure fortement pyramidale, mais je n'ai jamais vu un membre du middle management, chef de projet, tech lead... et encore moins au-dessus, assumer la responsabilité de l'échec d'un projet ou d'une partie d'un projet. Jamais. En général on se contente de trouver un "coupable" parmi l'équipe de développement (et c'est ce dernier qui a des ennuis), de blâmer le client, la techno...
A cela, l'auto-organisation oppose le principe de responsabilité collective, c'est à dire de réussite collective ou d'échec collectif, qui est à mon avis bien plus pertinent et proche de la réalité. Cela sert non pas à se dédouaner des erreurs commises, mais au contraire à réfléchir tous ensemble à ce qui n'a pas marché et essayer de l'améliorer.

Sur les builds intermédiaires, je rappelle que Scrum, XP... nécessitent la présence d'un représentant du client dans l'équipe, donc le le dialogue avec les développeurs est quotidien et le feedback immédiat, ce qui évite à l'équipe d'"avancer dans la mauvaise direction". Visiblement, ce n'était pas le cas dans le projet auquel tu fais allusion.

Sur la documentation, préjugé encore une fois : le manifeste agile ne bannit pas toute documentation mais recommande de donner la priorité à un code qui fonctionne par rapport à une documentation pléthorique. Cela ne *veut pas* dire qu'aucune doc n'est nécessaire. En l'occurrence, rien n'empêche de faire un court compte rendu écrit du stand-up meeting (chose que je fais actuellement dans mon contexte professionnel), et bien entendu rien n'empêche non plus de noter noir sur blanc les décisions prises lors des workshops métier. En fait, tout détail considéré comme utile devrait être noté dans le backlog, dans les tests d'acceptance des user stories, ou ailleurs.

En conclusion, nous sommes d'accord sur un point : non, Scrum n'est pas la panacée universelle immédiate que certains veulent nous vendre, surtout si aucun effort de transformation et de lâcher prise vis-à-vis des vieux réflexes n'est fait.
Une des choses dont les projets informatiques souffrent le plus, et les projets agiles n'y échappent pas, c'est cette défiance entre les différence acteurs, cette guéguerre client/prestataire, manager/développeur... que tu as bien décrite et qui empêche tout le monde d'aller dans le même sens.

Ce que l'agilité propose face à cela, et que certains ont visiblement oublié en tapant un peu vite sur la méthode, c'est un cadre qui permet 1/ d'identifier et de mettre le doigt sur ce type de problèmes très tôt dans le cycle de développement et 2/ de pouvoir s'améliorer rapidement et redresser la barre facilement *si la volonté est là*.

L'auto-organisation : analyse d'un concept subversif - goupils

goupils — Thu, 26 May 2011 19:05:48 +0200

Bonjour,

Je viens de découvrir ce blog à l'instant et je voulais juste profiter de ce billet pour faire part de mon expérience personnelle. Je travaille sur des projets multimédia assez volumineux et comme beaucoup nous avons succombé à la méthodologie SCRUMM / AGILE. Et je dis: Attention car un effet de mode s'est emparé de notre industrie en vendant les bienfaits d'une méthodologie dont le nom semblait séduisant mais le retour d'expérience a été un peu cuisant pour plusieurs prestataires

- Dans le cadre d'un projet au forfait avec des paiements liés aux livrables mensuels, continuer d'imposer une phase de spécification du projet (80%) pour garantir vos rentrées d'argent.
En vendant le principe que client peut redéfinir ses besoins et les affiner à chaque itération, il trouve cela très plaisant et c'est très constructif pour l'équipe, mais il ne le fait pas pour les paiements en se défaussant sur le service juridique et comptable qui vous annonce que le paiement du mois ne peut pas être fait car le contrat n'est pas respecté à la lettre.
Le Product Owner (client) que vous impliquez dans votre méthodologie n'est pas nécessairement le décisionnaire et cette méthodologie peut rapidement vous étouffer financièrement

- Conservez la notion de Chef de Projet au SCRUM MASTER pour gérer les conflits humains, éviter que chacun partent dans des délires techno et confondent décision de R&D et développement. Dans les grosse équipes comme nous (60 personnes) il faut conserver une structure de lead technique, lead artiste, lead ergonome ... avec des strates (de senior à junior).
Un jour la problématique des responsabilités individuelles viendra sur la table et la notion d'équipe unifiée explose à ce moment. Le lead technique prend des choit techniques pour les juniors et est en responsable. Cette pyramide permet également de conserver un système d'évaluation des individus sur le long terme. Ce n'est pas le chef de projet, mais bien les leads qui vont évaluer les juniors ( en cas de primes ou de promotion)

- ne communiquer pas les builds intermédiaires au client mais uniquement les livrables qui sont liés à un paiement car le client va créer un décalage entre le temps pour lui de faire une évaluation (1 semaine pour les grosse applications comme les notre, de formaliser un feedback et nous le communiquer)
Entre temps l'équipe à avancer dans la mauvaise direction et c'est du temps perdue. Imposer un délai contractuelles (15 jours max) pour le client formalise son feedback et toujours le faire faire par écrit

- Ne négliger pas la documentation, les réunions stand-up meeting ont la fâcheuse tendance de ne laisser aucunes traces. Réduisez les à l'essentielle et laisser les leads organiser des réunions métier avec un COMPTE RENDU à la clef ... ce qui permet aux gens de s'y référer si un problème resurgit et une décision déjà prise

Persistez votre domaine avec Raven DB - Guillaume

Guillaume — Fri, 04 Jun 2010 16:18:20 +0200

Merci, effectivement je viens de voir que ton article sur AppEngine soulevait les mêmes loups :)

Concernant le champ couvert par les bases NoSQL, j'ai du mal à les voir décoller dans un contexte d'entreprise si ça reste du one-shot sans intégration avec les outils et autres sources de données de l'organisation. D'après ce que j'ai compris, une des cibles désignées des bases NoSQL est le business web à forte croissance qui a besoin de scalabilité, en général ce type d'activité nécessite aussi des outils d'administration / sauvegarde / reporting / analyse de données assez poussés.

Pour l'instant ces outils existent peu et si on ne les voit pas arriver, je doute que des bases comme Raven dépassent le niveau anecdotique.

Persistez votre domaine avec Raven DB - Jean-Baptiste

Jean-Baptiste — Fri, 04 Jun 2010 08:24:04 +0200

Chouette article, c'est vrai que j'en causais aussi dans mon billet sur AppEngine du rapprochement DDD/NoSQL. D'ailleurs Big Table et ses drivers java souffrent des mêmes soucis que tu décris.

Ceci dit, je ne suis pas sûr d'être d'accord avec ta conclusion : je ne sais pas si on attend des bases NoSQL de faire tout ce que savent faire les SGBDR. Elles tentent de couvrir une nouvelle plage de besoins j'ai l'impression, que les SGBD n'abordaient pas, ou difficilement.Elles essayent aussi je pense d'enlever le côté "silver bullet" des bases de données classiques, nous donnant el choix dans la manière de persister nos données, mais les deux approchent ont leurs mérites, et l'une n'excluse pas l'autre.

Règlement de comptes à Données Corral - Guillaume

Guillaume — Fri, 21 May 2010 10:59:08 +0200

Oui, les bases NoSQL sont de leur propre aveu limitées à certains usages dont beaucoup tournent autour du Web (cf présentation de RavenDB : http://ravendb.net/documentation/do...).

De l'objet ou du relationnel, qui fait régresser la situation ? Je pense que c'est un débat sans réponse ;-)

Règlement de comptes à Données Corral - Arialia

Arialia — Wed, 19 May 2010 16:03:16 +0200

Je pense franchement que les deux types de bases de données n'ont pas les mêmes usages.

La base de données relationnelle permet de gérer les données et de pouvoir les extraire même sans programme, elles ont été conçues pour pouvoir fournir des réponses à des questions non prévues (pour peu que les données soient présentes )

La base Nosql pour ce qu'en j'en ai vu est dépendante du programme de création/extraction.

Si une nouvelle question surgit il faudra impérativement faire un programme d'extraction ( là où au pire en cas de question difficile on fera appel à l'expert SQL ).

Pour des applications telles twitter c'est très bien mais pour la gestion du personnel ou des aéronefs j'ai un doute.

Par contre j'ai un sérieux doute sur les bases de données conçues ces dernières années sur le modèle objet avec persistence de données dans des SGBD relationnels : facile à remplir , c'est une horreur à interroger ... conséquence des programmes tournent la nuit pour extraire les données de ces bases et les rendre interrogeables par les traditionnels requêteurs/infocentre (Bi-query par exemple) .

Sous prétexte de vouloir faire de l'objet j'ai l'impression que l'on régresse ...

Règlement de comptes à Données Corral - Guillaume

Guillaume — Wed, 10 Mar 2010 23:28:34 +0100

Je suis d'accord avec toi, les deux approches n'ont rien d'inconciliable.
Cette guerre se situe avant tout dans les échanges d'amabilités et réactions violentes de quelques experts. Après, personne n'a dit qu'une guerre se terminait forcément par l'anéantissement d'un des deux camps ;)

Règlement de comptes à Données Corral - Antoine

Antoine — Wed, 10 Mar 2010 12:05:14 +0100

Guerre oui et non. NOSQL permet une nouvelle façon de structurer le stockage de données et il est généralement bon de voir les possibilités techniques s'élargir. Il y a des métiers ou des architectures qui tirent et tireront encore le plein intérêt d'un modèle relationnel, alors que pour d'autres ce type de modèle représente plutôt un handicap. C'est le contexte particulier à chaque application qui déterminera l'adoption d'une approche plutôt que de l'autre.
On est encore dans une zone de turbulences alimentée par des prises de position assez extrèmes, mais aucun modèle de stockage n'est la silver bullet et je ne vois pas pourquoi une solution supplanterait totalement l'autre.