L'Agilitateur - Agile Grenoble 2012, ma journée chez les binômes - CommentairesCréation de logiciels : de l'agilité à l'artisanat2021-10-09T15:11:31+02:00urn:md5:7668924f626a6543fa389f1b4e47e529DotclearAgile Grenoble 2012, ma journée chez les binômes - Rémy Sanlavilleurn:md5:36f01fa8a43808a194f82d60c48b345a2012-11-14T21:32:22+01:002012-11-14T21:32:22+01:00Rémy Sanlaville<p>Si tu passes d'une collection à une map ce n'est pas que tes interfaces ne sont pas stables, c'est plutôt que le choix de l'implantation n'a pas été suffisamment bien encapsulé. C'est vrai que l'exemple collection et map était un peu facile (ne pas oublier la règle 8. Use first class collections).</p>
<p>Plus généralement si tu dois changer du code alors que le besoin n'a pas évoluer alors tu es en train de reprendre des choix d'implantation. Dans ce cas, le changement devrait être le plus centralisé possible.</p>
<p>En tout cas, si ton approche fonctionne plutôt bien sur tes logiciels c'est le plus important et cela signifie que tu gères plutôt bien la responsabilité et l'encapsulation de tes objets. On pourra sans doute en rediscuter un jour sur un de tes projets.</p>Agile Grenoble 2012, ma journée chez les binômes - Oazurn:md5:9a2b5327ad592e602fd01128ab5d31872012-11-14T18:34:50+01:002012-11-14T18:34:50+01:00Oaz<p>Mais si je passe d'une collection à une map, c'est que mes interfaces ne sont pas si stables que ça :-)</p>
<p>En fait, ma vision actuelle de la conception de logiciels (<a href="https://agilitateur.azeau.com/post/2012/03/05/Conception-logicielle" rel="ugc nofollow">que j'ai partagée dans une série de billets</a>) fait que je m'intéresse relativement peu aux détails internes d'un composant (terme générique pour librairie, package, etc.) mais que je recherche un maximum de stabilité au niveau des concepts/interfaces qui font le liant entre les composants.<br />Du coup, partager des états internes à l'intérieur d'un composant ne me dérange pas plus que ça. La zone de partage est de toutes façons très limitée. Et pour les échanges inter-composants, vu que je fais l'hypothèse de la stabilité des interfaces, je n'ai pas de scrupules à enchainer les appels. :-)</p>
<p>Peut-être que je rate quelque chose mais pour l'instant cette approche fonctionne pas trop mal pour les logiciels sur lesquels je travaille.</p>Agile Grenoble 2012, ma journée chez les binômes - Rémy Sanlavilleurn:md5:25e3d58809a2e221ca8faf16e76eab012012-11-12T22:19:04+01:002012-11-12T22:19:04+01:00Rémy Sanlaville<p>Intéressant comme réflexion concernant la loi de Demeter et le fait de n'utiliser que des interfaces.</p>
<p>C'est à creuser mais je dirais que même si je n'utilise que des interfaces je préfère éviter cela et suivre la loi de Demeter car je préfère ne pas rendre visible l'état interne de ma classe même si je retourne une interface. Imagine par exemple que tu veux passer d'une Collection à une Map. Cela pourrait avoir un impact important sur le reste de ton code.</p>
<p>De plus si tu souhaites avoir accès à l'état interne de ta classe c'est sans doute que tu veux demander à ta classe quelque chose de particulier. Autant faire en sorte de rendre visible cela au niveau de la classe et déléguer l'implantation à un collaborateur. Cela permettra de faire mieux apparaître ce que tu demandes à ta classe (tu auras un contrat plus claire) et voir si elle ne porte pas trop de responsabilité.</p>Agile Grenoble 2012, ma journée chez les binômes - Oazurn:md5:118fdb2b3c0241676f7cc7ef657308a72012-11-12T16:06:54+01:002012-11-12T16:06:54+01:00Oaz<p>@Rémy,</p>
<p>Merci pour les détails.<br />Je crois que, en fait, j'ai un petit souci avec la loi de Demeter. Tant que je ne connais mes amis et les amis de mes amis qu'à travers des interfaces, j'accepte de leur parler à tous.<br />Le "parler à travers une interface" me semble être une connaissance suffisamment minimale si les interfaces en question sont suffisamment stables.</p>
<p>@Alex,</p>
<p>Pourtant, j'ai eu bien du mal à choisir mes sessions. J'ai juste choisi sans prendre de risque par manque d'information sur la plupart des sessions.<br />Et puis, comme je l'ai écrit, les personas peuvent être une bonne réponse. Tout dépend de la question. :)</p>
<p>Pour ce qui est des "communicants et organisants" (ce que je suis moi-même d'ailleurs devenu aujourd'hui, bien plus que codeur en tout cas), je suis juste parfois surpris par leur capacité à faire passer le produit logiciel au second plan, même si c'est pour faire avancer une cause...</p>Agile Grenoble 2012, ma journée chez les binômes - Alexurn:md5:88d41e865d0e5efdb6b1cba578d4e5222012-11-12T11:48:00+01:002012-11-12T11:48:00+01:00Alex<p>Salut Olivier</p>
<p>Petite précision, les personas ont été beaucoup apprécié par les personnes qui avaient du mal à choisir leurs sessions ... ce qui n'était manifestement pas ton cas :)</p>
<p>De même pour la 2ème Keynote qui a également été globalement appréciée, mais surement plus par le monde des "communicants et organisants" qui était bien présent et que tu ne portes pas vraiment dans ton cœur ... et qui pourtant font également beaucoup progresser la cause de l'agilité, et par voie directe celle des développeurs :)</p>
<p>Amitié<br />
Alex</p>Agile Grenoble 2012, ma journée chez les binômes - Rémy Sanlavilleurn:md5:d72f5899dcf38ec90e71c011397397972012-11-12T00:28:42+01:002012-11-12T00:28:42+01:00Rémy Sanlaville<p>Salut Olivier,</p>
<p>Concernant la question que tu te poses "Que vaut la règle 5 ("One dot per line") des Object Calisthenics ? Surtout si l'on considère les DSL internes", je vais essayer de donner une réponse.</p>
<p>En premier lieu, c'est bien que tu te poses des questions, les règles sont faites pour cela ;-)<br />
Revenons à la règle 5 "One dot per line" qui correspond à la loi de Déméter (qui peut être résumée en "Ne parlez qu'à vos amis immédiats"). L'idée est faciliter la maintenance évolution en ne cassant pas l'encapsulation des classes.</p>
<p>Concernant les DSLs comme on a pu le montrer dans la solution 4 : quality.doIncreaseBy(1).when(daysBefore, greaterThan(10)); - bien que nous ayons deux appels de méthodes sur une même ligne (Two dots) on reste conforme à la loi de Déméter même si cela ne respecte pas la règle 5. En effet, les DSL (comme par exemple FEST) ont la particularité de retourner l'instance de la classe de la méthode qui est appelée. Du coup, même si on a bien plusieurs appels chaînés (comme dans FEST) cela reste sur la même instance et cela ne casse pas l'encapsulation de la classe.</p>
<p>Comme indiqué, le but n'est pas de respecter à 100% les règles (contraintes), mais elles sont là pour lever un drapeau et nous faire réfléchir (une chance pour sortir de notre cadre de pensée).</p>
<p>En espérant avoir pu répondre à ta question.</p>Agile Grenoble 2012, ma journée chez les binômes - Oazurn:md5:f09ca059a64c723bee196dbfed9596a72012-11-11T16:09:06+01:002012-11-11T16:09:06+01:00Oaz<p>Salut Pablo,</p>
<p>Merci pour les réponses aux questions :)<br />Le problème des questions 1 et 4, c'est que quand on passe la journée à voir du code, ben on se pose des questions relatives au code...</p>
<p>Et pour la question 3, je suis bien d'accord. Le programmeur du XXIème siècle, c'est un peu le médecin du XVIIème siècle. S'il veut gagner un peu de respect, il a du chemin à parcourir.</p>Agile Grenoble 2012, ma journée chez les binômes - pablourn:md5:e75d1f88683cd53558933e2120a213732012-11-11T10:48:56+01:002012-11-11T10:48:56+01:00pablo<p>décidément j'aime bien le positionnement de Mr Oaz. Je ne suis pas toujours d'accord mais il me semble singulièrement cohérent.</p>
<p>Les réponses à tes questions :) :) :)</p>
<p>1) rien compris, je ne sais pas ce que c'est<br />
2) c'est pas plutôt l'inverse ?<br />
3) beaucoup (mais c'est aussi à eux de changer les choses car 100% de ce code provient de développeurs).<br />
4) euh, comment dire.</p>Agile Grenoble 2012, ma journée chez les binômes - Oazurn:md5:3b7017adbcf9448dd94b58c18a07ceb22012-11-10T16:29:02+01:002012-11-11T10:42:52+01:00Oaz<p>Salut Jérôme,</p>
<p>Je crois que les personas sont la bonne réponse à une mauvaise question.</p>
<p>Si la question est "quelles sont les sessions où l'on va évoquer le plus de choses ayant un rapport direct avec le travail d'un profil type X dans une entreprise classique ?" alors, effectivement les personas sont une bonne réponse. Elles vont permettre à des chefs de projet d'aller rencontrer d'autres chefs de projets dans une session où un ex-chef de projet devenu scrummaster raconte l'évolution de sa vélocité lors des 10 premiers sprints de son projet (on peut trouver des situations similaires avec des développeurs, des chefs de produit, etc.)</p>
<p>Maintenant si, depuis mon monde de bisounours, j'essaye de définir différemment l'utilité d'une conf agile, je peux poser une autre question : "comment puis-je amener des personnes de divers horizons mais partageant une communauté d'intérêt à se rapprocher au travers d'une démarche de découverte ou d'approfondissement de l'agilité ?" je n'aurai pas la même réponse.<br />L'approche thématique de l'AT Toulouse me parait être bien plus adaptée au sens où elle donnait des pointeurs sans être clivante. On s'est juste planté en oubliant de préciser (voire de déterminer pour chaque session) le niveau découverte vs approfondissement.</p>Agile Grenoble 2012, ma journée chez les binômes - Jérômeurn:md5:3974881495c991dcdcade7e4fbc368a02012-11-10T11:10:18+01:002012-11-10T11:10:18+01:00Jérôme<p>Salut Olivier,</p>
<p>Merci pour ton retour :)<br />
Une question : je n'ai pas trop compris ton sentiment négatif sur les personas.<br />
Qu'est ce que tu reproches ? le principe ? la façon dont ils étaient faits ? leur nombre ? leur efficacité ?etc.<br />
Car de l'extérieur, ça me paraît plutôt être une idée géniale.<br />
Mais ton retour m'intéresse pour AT Montpellier.</p>