mageekblog - Les tests sont les panneaux routiers du développeur - CommentairesLe blog personnel de Frédéric Hardy. Au menu, PHP, agilité, FreeBSD, cuisine et photographies.2021-12-02T08:20:54+01:00Frédéric Hardyurn:md5:26874ca5b8cd4cac8d08b0e68e64f63aDotclearLes tests sont les panneaux routiers du développeur - Ouarzyurn:md5:8056f2fd9fb7a6d4571f27e9543a20412014-03-20T15:33:08+01:002014-03-20T15:33:08+01:00Ouarzy<p>Pour commencer, on peut te retourner la remarque: "si ta méthode te convient et marche très bien pour toi il n'y a rien à redire !"<br />
A la limite j'ajouterais: "si ta méthode <a href="http://blog.mageekbox.net/?post/2014/03/10/..." title="..." rel="nofollow">...</a> marche très bien pour toi ET POUR TES COLLEGUES <a href="http://blog.mageekbox.net/?post/2014/03/10/..." title="..." rel="nofollow">...</a>"</p>
<p>"moins j'ai à refactoriser, moins j'ai à déboguer et mieux je me porte"<br />
Ceci montre une limite intrinsèque des outils de ton langage, qui sont de faite peu adapté pour du TDD, qui lui prone un refacto continu.</p>
<p>"Pour moi la phase de rédaction ne doit venir que lorsque les idées s'articulent bien"<br />
Oui mais le tout est de savoir où placer le curseur? Je te recommande l'exercice d'écriture de billet de blog pour le voir. Trouver une idée à exprimer est assez simple. L'exprimer de façon clair et agréable est beaucoup plus compliqué. Et il faut souvent plusieurs itération et beaucoup de relecture (y compris de tiers) pour arriver à quelque chose de "satisfaisant".</p>
<p>"il faut fournir un cadre propice au changement"<br />
Oui, oui et mille fois oui <img src="/themes/default/smilies/smile.png" alt=":)" class="smiley" /> On est tout à fait d'accord!</p>
<p>"et c'est bien là le rôle de l'architecture "<br />
C'est notre avis, mais dans un projet Waterfall standard, c'est tut l'inverse. L'achitecture va rigidifier autant que possible l'environnement, de façon à garantir le suivi d'un plan dans lequel on aura anticiper tous les problèmes <img src="/themes/default/smilies/smile.png" alt=":)" class="smiley" /></p>
<p>"je veux avoir des retours rapides sur mon architecture, la question étant encore de savoir comment"<br />
Notre réponse c'est: en l'implémentant. Mais le problème je pense c'est qu'on peut mettre bcp de chose derrière "architecture". De mon point de vue, une bonne architecture c'est seulement avoir une structure souple. Bon pour ça pas besoin d'y passer une plombe: on respecte SOLID, on fait de l'injection de dépendance, on tests, et c'est gagné.</p>
<p>Par contre quand on parle d'architecture "fonctionnel", c'est à dire qu'on sort du cadre technique et qu'on se demande comment bien gérer les problèmes du métier pour lequel on code, il n'ya pas de pattern tout fait. C'est spécifique à chaque métier. Et c'est là qu'on trouve qu'il est plus rentable d'itérer sur de petites tentatives, plutôt que de passer des mois à théoriser sur ce qui doit être fait.</p>
<p>Cela demande deux choses importantes:<br />
- être capable de changer son code sans régression (architecture souple + TU)<br />
- ne pas considérer une réécriture comme un échec, mais comme une étape de plus vers la production d 'un code satisfaisant</p>Les tests sont les panneaux routiers du développeur - bouhurn:md5:3266a150e6d738ce792f2a6bea3219872014-03-17T13:55:10+01:002014-03-17T13:55:10+01:00bouh<p>Bon de toute façon @mageekguy, si ta méthode te convient et marche très bien pour toi il n'y a rien à redire !<br />
Pour ma part elle ne me convient que moyennement, et cela pour plusieurs raisons :<br />
- J'aime bien coder mais ce n'est pas non plus ma grande passion : je tire peu de satisfaction du processus lui même, ce qui me plait avant tout c'est ce qu'il permet et aussi le fait d'avoir mis en œuvre une solution efficace et élégante. Du coup coder un premier truc "sale" puis ensuite en refaire un "propre" m'embête un peu. Si il y a des parties pour laquelle je ne suis pas certain de la faisabilité, je préfère tester les limites de ma plateforme à côté.<br />
- Des plateformes avec lesquelles je travaille : VBA (sic) et Scilab (re-sic). Cette dernière ne fournit aucun modèle objet (et ne permet pas de bien l'émuler), pas d'auto-complétion ni d'outils de débogage pratique (pas de points d'arrêts, etc). En conséquence de quoi moins j'ai à refactoriser, moins j'ai à déboguer et mieux je me porte.<br />
En fait j'ai pour le développement à peu près la même idée que la composition de dissertation. Pour moi la phase de rédaction ne doit venir que lorsque les idées s'articulent bien. Tout comme sur un brouillon ne figure que le plan des idées et non pas la dissertation entièrement rédigée, il n'est pour moi pas nécessaire d'aller jusqu'à "la mise en production de sa première itération". Du coup j'ai un peu le fantasme de parvenir à faire des itérations "virtuelles" d'architecture afin d'arriver à stabiliser mon "plan" avant de commencer à rédiger -à savoir déboguer et intégrer.<br />
C'est peut être irréaliste, mais je veux m’entrainer à cet exercice qui je pense ne peut que m'être bénéfique. Je me suis trop souvent maudis à devoir réécrire du code par précipitation. Précipitation à vouloir coder pour d'obtenir des fonctionnalités (la gratification) mais le problème c'est que sans architecture on contraint l'ensemble des solutions et il arrive qu'on se retrouve face à une impasse lorsqu'on souhaite rajouter des choses.<br />
Du coup j'essaie de me trouver un processus qui me permettrait d'arriver à une architecture stable le plus rapidement possible. Pour l'instant voilà comment j'essaie :<br />
- Je définis les spécifications avec quelques user stories associées.<br />
- J'étudie l'impact des contraintes d'ergonomie, de performance, de sécurité et d'évolutivité sur chaque spécifications.<br />
- Je définis un premier modèle objet avec une première API.<br />
- J'essaie de réaliser (toujours sur papier / rapport) mes user stories avec l'API (cela revient en fait à réaliser des diagrammes de séquence UML) et je met à jour mon API.<br />
Après j'aimerais bien essayer de définir des "tests d'architecture". Ils consisteraient à faire des scénarios où j'évalue l'impact d'un changement de fonctionnalité ou l'ajout d'une nouvelle et à voir si il faut tout réécrire ou pas mais j'ai pas encore d'idée bien précise là dessus.</p>
<p>@ouarzy : Je n'ai pas tout lu encore mais, dans ton text il est dit "He came up with a new problem that he set out to solve: How can you build a plane that could be rebuilt in hours, not months?" Il a donc réfléchit en amont à comment créer un avion dont les caractéristiques soit évolutives. En d'autre terme, il faut fournir un cadre propice au changement (je parle au niveau du code), et c'est bien là le rôle de l'architecture comme le mentionne la phrase suivante : "So what’s the lesson? When you are solving a difficult problem, re-frame the problem so that your solution helps you learn faster. Find a faster way to fail, recover, and try again."<br />
D'ailleurs comme je l'ai dis plus haut, je veux avoir des retours rapides sur mon architecture, la question étant encore de savoir comment.</p>
<p>(comment on fait des sauts de ligne ? xD)</p>Les tests sont les panneaux routiers du développeur - ouarzyurn:md5:cfc5b12f7eaacba91b73651a7ab9da142014-03-14T09:17:39+01:002014-03-14T09:17:39+01:00ouarzy<p>Pour ajouter un peu de sel à votre discussion: @Bouh je te recommande cette histoire sur la création d'un avion propulsé par l'homme par Paul MacCready: <a href="https://signalvnoise.com/posts/2861-how-nature-and-naivet-helped-paul-maccready-build-a-human-powered-airplane-in-only-six-months" title="https://signalvnoise.com/posts/2861-how-nature-and-naivet-helped-paul-maccready-build-a-human-powered-airplane-in-only-six-months" rel="nofollow">https://signalvnoise.com/posts/2861...</a></p>
<p>En très résumé, c'est un exemple montrant qu'en cas de forte incertitude (ce qui est la définition même d'une phase de conception architecturale), il est plus rentable d'avoir une approche empirique itérative plutôt qu'une approche conceptuel et théorique qu'on ne valide qu'en fin de parcours.</p>
<p>C'est un point fondamental de l'agilité. Cela étant dit ça n'interdit à personne en aucun cas de réfléchir, comme l'explique bien l'oncle bob: <a href="http://blog.8thlight.com/uncle-bob/2014/03/11/when-to-think.html." title="http://blog.8thlight.com/uncle-bob/2014/03/11/when-to-think.html." rel="nofollow">http://blog.8thlight.com/uncle-bob/...</a></p>
<p>Simplement on réfléchi à condition d'avoir un feedback court. Si le feedback qu'on a sur notre décision n'est que dans plusieurs mois, alors on risque un grave problème.</p>Les tests sont les panneaux routiers du développeur - mageekguyurn:md5:9ae9d302da1781dc10ab64531e097e5e2014-03-11T09:34:56+01:002014-03-11T11:29:04+01:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2014/03/10/Les-tests-sont-les-panneaux-routiers-du-d%C3%A9veloppeur#c6652" rel="nofollow">Bouh</a> : </p>
<blockquote><p>Cela donne l'impression que vous misez tout votre processus de développement sur les TDD, y compris la phase de conception. J'ai le sentiment que c'est seulement parce que vous voulez mettre en place des tests "faciles" à maintenir (à savoir, invariant lors de changement de code à périmètre fonctionnel constant) que vous vous intéressez à comment vraiment mettre en place une architecture flexible.</p>
</blockquote>
<p>Exactement !</p>
<p>Les tests sont pour moi une barrière qui me permet de me canaliser dans mon développement (car par nature, je suis plutôt du style bulldozer), et cela d'autant plus que même avec une phase de réflexion en amont, il est très difficile pour moi de penser à tout sans avoir un minimum de code fonctionnel à ma disposition.</p>
<p>Et comme l'expérience m'a montré que les tests sont, par rapport à ma façon de développer, bien plus efficace pour faire émerger une architecture correcte que toutes les minutes/heures/jours que je pourrais passer à y réfléchir, je mise effectivement tout sur mes tests, même si pour les choses "originales", je code bien souvent un POC "à l'arrache" pour avoir une idée relativement précise du flux d'information et des enchaînements, POC qui me sert ensuite à la rédaction de mes tests et donc au développement du code "propre".</p>
<p>J'ai de cette manière un feedback beaucoup plus rapide et précis par rapport à une "intellectualisation" de l'architecture du code et je suis donc plus productif.</p>
<p>C'est une approche empirique et pragmatique (tiens tiens…) mais dans mon cas, elle fonctionne très bien notamment car le TDD permet de coder de façon à avoir un code modulaire, donc facile à faire évoluer sans les changements drastiques d'API dont tu parles (Si tu fais du SOLID, les changements drastiques d'API ne sont plus nécessaire, et comme le TDD force le développeur à suivre SOLID, car pour être testable, un code doit suivre ces règles, la boucle est bouclée).</p>Les tests sont les panneaux routiers du développeur - Bouhurn:md5:701e68fdf8821e545771c36a1790f7f02014-03-10T23:20:59+01:002014-03-10T23:20:59+01:00Bouh<p>Bonjour,</p>
<p>Tout d'abord, comme toujours, l'article est apprécié!!<br />
Via hackernews je suis tombé sur ce texte de James Coplien qui contient la même citation : <a href="http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf" title="http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf" rel="nofollow">http://www.rbcs-us.com/documents/Wh...</a></p>
<p>J'ai trouvé ce texte assez intéressant, il parle, entre autre, de la finalité des tests, et de l'information et la valeur que procure un test. D'un point de vue personnel, il m'a permis de prendre un peu de recul vis à vis des tests unitaires. Car la période suivant ma découverte de cette démarche j'avais tendance à repousser la majeur partie de ma réflexion à plus tard : lors de l'écriture des tests.</p>
<p>Or c'est peu le sentiment que j'ai quand en ayant lu vos derniers billets, notamment : "Le développement piloté par les tests m’oblige en effet, pour que je puisse rédiger mes tests, à réfléchir à l’architecture de mon code avant de l’écrire, au lieu de laisser émerger cette architecture de mon code et éventuellement de la corriger à postériori, au risque d’y introduire des bogues ou de provoquer des régressions."<br />
Cela donne l'impression que vous misez tout votre processus de développement sur les TDD, y compris la phase de conception. J'ai le sentiment que c'est seulement parce que vous voulez mettre en place des tests "faciles" à maintenir (à savoir, invariant lors de changement de code à périmètre fonctionnel constant) que vous vous intéressez à comment vraiment mettre en place une architecture flexible.<br />
Et pourtant, d'après moi, la phase de conception de l'architecture devrait être faite au préalable (même dans une démarche agile) afin justement de fournir le support permettant l'ajout / modifications de fonctionnalités sans une refonte drastiques des API. Une fois cette étape suivie, alors naturellement les tests seront plus stables au changement.<br />
Bien à vous</p>