Je veux que l’Agile existe. J’y crois ! J’y crois !

((/dotclear/public/peterpan.gif|Peter Pan|L|Peter Pan, aoû 2009))Chaque fois qu’un manager dit : « Je ne crois pas à l’Agile », il y a quelque part un projet qui meurt.%%% %%% Je veux que l’Agile existe. J’y crois ! J’y crois !%%% %%% {{Everytime a manager says: I don’t believe in Agile, there is a project somewhere that falls down dead. I do believe to the Agile! I do! I do!}}%%%

Rétrospective Apéro Agile du 17 août 20h-22h à l’Oxford Arms

[((/dotclear/public/./.agile_washing_s.jpg|Agilewashing|L|Agilewashing, aoû 2009))|/dotclear/public/agile_washing.jpg]__What went well__%%% %%% – Convivialité du lieu%%% – Qualité d’accueil et ouverture d’esprit%%% – Je suis toujours étonné de ressentir l’énergie positive dégagée par mes interlocuteurs agilistes : il ne s’agit pas ici de parler de la dernière version d’un langage à la mode mais bien de la réussite d’une équipe mobilisée autour du développement d’un produit : la qualité et la simplicité du code sont prônées, le dosage de l’effort de développement revendiqué. Ça rend humble…%%% <- Petit délire sur l'Agilewashing (dans la même idée que le ''Greenwashing'', utilisation/récupération des valeurs de l'Agile sans justification, contraction de brainwashing = lavage de cerveau)%%% %%% __What went wrong__%%% %%% - Nous n'étions que trois. Les aoûtiens ont boudé notre apéro...%%% - Colin, l'organisateur, s'est pointé 1h trop tôt, complètement jetlaggé ;-)%%% %%% __Puzzles__%%% %%% - Comment se définit une "équipe" ?%%% - Pas de programme affiché pour l'++[Agile Tour Bordeaux|http://www.agiletour.org/fr/at2009_bordeaux.html|fr]++ ! Difficulté à trouver des intervenants ? En fait, non, chaque chose en son temps, le programme officiel va bientôt sortir avec de belles surprises... Par contre, à vot'bon coeur les ++[sponsors|http://www.agiletour.org/fr/sponsoring.html|fr]++ !%%% - Un Agile Open à Bordeaux ? à l'image de ce qui s'est fait en ++[Alsace|http://www.agileopen.net/node/370|fr]++ en début d'année ?%%% - Zut, j'ai oublié de demander ce que signifiait le nom et le logo de l'association...%%% %%% __Appreciations__%%% %%% - Merci à Arthur et Colin (association ++[Okiwi|http://www.okiwi.org/|fr]++).

Aikido33.fr c’est fini !

Je n’ai malheureusement plus le temps de m’occuper du site ++[Aikido33.fr|http://www.aikido33.fr/spip/index.php|fr]++. Son hébergement prendra fin le 16 août 2009. Pendant 2 ans, je me serais bien amusé avec le système de publication ++[SPIP|http://www.spip.net/fr|fr]++.%%% %%% Je vous renvoie donc au site officiel de ++[Serge Sans|http://aikido.sans.free.fr/|fr]++ pour retrouver toutes les informations sur les clubs et stages et sur le forum ++[« Les Aikidokas du Médoc »|http://aikido-medoc.forum-actif.eu/index.htm|fr]++ pour les actualités.%%% %%% [((/dotclear/public/./.aikido33_m.jpg|www.aikido33.fr|C|www.aikido33.fr, juin 2009))|/dotclear/public/aikido33.png] %%% J’en profite pour rapidement présenter __Serge Sans__ :%%% * Haut gradé de l’Aïkikaï de Tokyo%%% * __5° Dan__, Brevet d’état 2° Degré%%% * Élève direct de __Maître Tamura__ délégué par l’Aïkikaï de Tokyo en Europe%%% * Responsable Technique National chargé de mission pour La Fédération Française%%% * Formateur des Moniteurs Fédéraux d’Aïkido pour la région Sud-Ouest%%% * Jury d’examen pour les grades nationaux%%% * Ancien compétiteur en Karaté et Full Contact%%% * Serge anime __5 clubs en Gironde pour pratiquer tous les jours__ (St-Médard-en-Jalles, Eysines, Bordeaux, Castelnau-de-Médoc, Le Pian Médoc).%%% > Venez faire un cours d’essai, vous pourrez vous rendre compte de l’efficacité de son enseignement et de sa pratique…%%% ///html

///

Okiwi : prochain Apéro Agile le lundi 17 août

Présentation d’Okiwi par –son actuel président– l’un de ses illustres membres : ++[Colin Garriga-Sallaün|http://www.linkedin.com/pub/colin-garriga-sala%C3%BCn/9/670/600|fr]++ :%%% > Située à Bordeaux, l’association ++[Okiwi|http://www.okiwi.org/|fr]++ est un lieu pour partager nos expériences, nos connaissances, pour l’enrichissement de chacun, en espérant qu’en émergent des projets libres et utiles à tous.%%% > %%% > – Nous organisons régulièrement des présentations et des ateliers pratiques sur la base du volontariat.%%% > – Nous donnons rendez-vous aux agilistes le troisième lundi du mois à 20h, à l’++[Oxford Arms|http://www.oxford-pub.com/|fr]++ (++[agenda|http://www.google.com/calendar/embed?src=emrdkvvu6iuqkp6g2etjp5295g%40group.calendar.google.com|fr]++).%%% > – Nous participons à l’organisation de l’++[Agile Tour Bordeaux 2009|http://www.agiletour.org/fr/at2009_bordeaux.html|fr]++.%%% > %%% > Si vous êtes intéressés, le mieux est peut-être de nous contacter sur ++[notre liste de diffusion|http://groups.google.fr/group/okiwi?hl=fr|fr]++.%%% > N’hésitez pas ! Nous serions ravis d’accueillir de nouvelles têtes !%%% %%% J’ai légèrement customisé le logo de l’association :%%% ///html

/// %%% Association déclarée le 18 janvier 2006 (++[JO Association|http://www.journal-officiel.gouv.fr/association/index.php?ACTION=Rechercher&HI_PAGE=1&HI_COMPTEUR=0&original_method=get&WHAT=okiwi&JTH_ID=&JAN_BD_CP=&JRE_ID=&JAN_LIEU_DECL=&JTY_ID=&JTY_WALDEC=&JTY_SIREN=&JPA_D_D=&JPA_D_F=&rechercher.x=0&rechercher.y=0&rechercher=Rechercher|fr]++).

Les Principes de la Conception Orientée Objet

((/dotclear/public/programmation.gif|Programmation|L|Programmation, aoû 2009))J’ai traduit un article fondateur écrit par Robert C. Martin (++[Uncle Bob|http://en.wikipedia.org/wiki/Robert_Cecil_Martin]++) le 11 mai 2005 : « ++[The Principles of OOD|http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod|en]++ ».%%% %%% > Qu’est-ce-que la conception orientée objet ? De quoi ça parle ? Quels en sont les bénéfices ? Quel est son coût ? Cela peut sembler absurde de poser ces questions à une époque où presque tous les développeurs de logiciels utilisent un langage orienté objet. Mais la question est importante car, il me semble que la plupart d’entre nous utilisent ces langages sans savoir pourquoi, et sans savoir comment en tirer le plus grand bénéfice.%%% > %%% > De toutes les révolutions qui ont eu lieu dans notre métier, deux ont remporté un tel succès qu’elles ont influencé notre façon de penser, à un tel point que nous les prenons pour acquis. La Programmation Structurée et la Programmation Orientée Objet. Tous nos langages modernes sont fortement influencés par ces deux disciplines. En effet, il est devenu difficile d’écrire un programme qui ne reflète pas à la fois une programmation structurée et une programmation orientée objet. Nos principaux langages n’ont pas de __goto__, et semblent donc obéir à la plus célèbre condamnation de la programmation structurée. La plupart de nos principaux langages sont fondés sur la notion de classe et ne prennent pas en charge les fonctions ou variables qui ne sont pas dans une classe, par conséquent, ils semblent respecter les principes les plus évidents de la programmation orientée objet.%%% > %%% > Les programmes écrits dans ces langages peuvent sembler à première vue structurés et orientés objet, mais en y regardant de plus près on peut être déçu. La plupart des programmeurs d’aujourd’hui ne sont pas conscients des principes fondateurs dont dérivent leurs langages. Je discuterai dans un autre billet des principes de la programmation structurée. Dans ce billet je souhaite parler des principes de la programmation orientée objet.%%% > %%% > En Mars 1995, dans comp.object, j’ai écrit un ++[article|http://tinyurl.com/84emx|en]++ qui a été le point de départ d’une série de principes concernant la Conception Orientée Objet sur laquelle j’ai écrit plusieurs fois depuis. Vous les verrez documentés dans mon livre ++[PPP|http://www.objectmentor.com/PPP/|en]++, et dans de nombreux articles sur le site ++[objectmentor|http://www.objectmentor.com/]++, dont le bien connu ++[article de synthèse|http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf|en]++.%%% > %%% > Ces principes traitent de la gestion des dépendances en Conception Orientée Objet, par opposition à la conceptualisation et la modélisation. Cela ne veut pas dire que l’Orienté Objet est un mauvais outil de conceptualisation ou de modélisation. De nombreuses personnes utilisent très certainement avec succès ces aspects de l’Orienté Objet. Mais ces principes insistent très fortement sur la gestion des dépendances.%%% > %%% > La Gestion des Dépendances est une question à laquelle la plupart d’entre nous ont dû faire face. Chaque fois que nous lisons sur nos écrans un code pourri et fouillis, nous constatons les résultats d’une mauvaise gestion des dépendances. Une gestion des dépendances médiocre conduit à un code qui est difficile à maintenir, fragile, et non réutilisable. J’aborde ces problématiques dans mon livre PPP, toutes liées à la gestion des dépendances. Lorsque les dépendances sont bien gérées, le code reste flexible, robuste et réutilisable. La gestion des dépendances, par conséquent ses principes, est à la base des qualités intrinsèques souhaitées par les développeurs pour leurs logiciels.%%% > %%% > Les cinq premiers principes sont des principes de  »conception d’une classe » :%%% > %%% ///html

SRPLe Principe de Responsabilité Unique (The Single Responsibility Principle)Une classe ne doit avoir qu’une et une seule raison de changer.
OCPLe Principe Ouvert/Fermé (The Open Closed Principle)Vous devez pouvoir étendre le comportement d’une classe sans la modifier.
LSPLe Principe de Substitution de Liskov (The Liskov Substitution Principle)Les classes dérivées doivent pouvoir être remplacées par leurs classes de base.
DIPLe Principe d’Inversion des Dépendances (The Dependency Inversion Principle)Dépendez des abstractions, pas des compositions.
ISPLe Principe de Séparation des Interfaces (The Interface Segregation Principle)Écrivez des interfaces à granularité fine et qui sont spécifiques au client.
/// > %%% > Les six prochains principes sont sur les packages. Dans ce contexte, un package est un livrable binaire comme par ex. un fichier .jar, ou une dll par opposition à un namespace comme un package java ou un namespace C++.%%% > %%% > Les trois premiers principes sont sur la  »cohésion » des packages et nous disent ce qu’il faut mettre dans les packages :%%% ///html
REPThe Release Reuse Equivalency PrincipleLa granularité de réutilisation est la granularité de livraison.
CCPThe Common Closure PrincipleLes classes qui changent ensemble sont packagées ensemble.
CRPThe Common Reuse PrincipleLes classes qui sont utilisées ensemble sont packagées ensemble.
/// > Les trois derniers principes sont sur les couplages entre les packages, et parlent de métriques permettant d’évaluer la structure des packages d’un système :%%% ///html
ADPLe Principe d’Acyclicité des Dépendances (The Acyclic Dependencies Principle)Le graphe des dépendances des packages ne doit pas avoir de cycle.
SDPLe Principe des Dépendances Stables (The Stable Dependencies Principle)Dépendez de packages qui soient stables.
SAPLe Principe des Abstractions Stables (The Stable Abstractions Principle)L’abstraction encourage la stabilité.
///

10 commandements pour écrire un bon code

((/dotclear/public/programmation.gif|Programmation|L|Programmation, aoû 2009))J’ai traduit un article très intéressant provenant du blog de Alberto Gutierrez : « ++[10 commandments for creating good code|http://www.makinggoodsoftware.com/2009/06/04/10-commandments-for-creating-good-code/|en]++ ».%%% %%% > __1. DRY : ne vous répétez pas.__%%% > %%% > DRY est habituellement le principe le mieux compris, mais il reste très dur à appliquer.%%% > %%% > Cela signifie que lorsque vous trouvez un code similaire à au moins deux endroits, il faut le factoriser dans une nouvelle méthode et transformer les fragments de code précédents pour appeler la nouvelle méthode avec les paramètres appropriés.%%% > %%% > ++[DRY|http://en.wikipedia.org/wiki/Don%27t_repeat_yourself|en]++ est sans doute le principe de codage le plus universel, je n’ai jamais rencontré de développeurs argumentant que répéter du code est bon, j’ai trouvé des développeurs qui oublient ce principe lorsqu’il code des tests unitaires, par exemple : imaginez que vous avez changer l’interface d’une classe qui a beaucoup de tests unitaires, si vous n’avez pas utilisé DRY, vous devrez changer à la main l’appel à l’interface de cette classe pour chacun des cas de tests.%%% > %%% > __2. Ecrivez des méthodes courtes.__%%% > %%% > Il y a trois bonnes raisons d’écrire des ++[méthodes courtes|http://www.agiledeveloper.com/blog/PermaLink.aspx?guid=8a745e85-2a34-4d9c-8c25-ca371530e281|en]++.%%% > %%% > 1) Votre code sera plus facile à lire.%%% > 2) Votre code sera plus facile à réutiliser (les méthodes courtes sont susceptibles d’offrir un couplage lâche).%%% > 3) Votre code sera plus facile à tester.%%% > %%% > __3. Utilisez de bons noms pour vos classes, méthodes et variables.__%%% > %%% > Il n’y a rien de plus agréable que d’utiliser le code développé par un autre et de ne pas avoir à lire sa documentation parce que les noms des classes veulent dire tout ou n’importe quoi, donc, rendez la vie facile à tout le monde et prenez cette approche, passez quelques secondes pour ++[nommer un élément dans votre code|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/08/10/7-1-conseils-pour-nommer-les-variables|fr]++.%%% > %%% > __4. Affecter la bonne responsabilité à chaque classe.__%%% > %%% > « Une classe, une responsabilité », cela semblera familier à ceux qui connaisse les principes ++[SOLID|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/08/13/Les-Principes-de-la-Conception-Orientee-Objet|fr]++, mais pas n’importe quelle responsabilité, la bonne responsabilité, donc si on a la classe Customer, nous ne lui assignerons pas la responsabilité de créer un acte de vente, nous lui assignerons juste la responsabilité de gérer toutes les données relatives à un client.%%% > %%% > __5. Maintenez votre code organisé.__%%% > %%% > Cette organisation se fait à 2 niveaux :%%% > %%% > – Organisation physique : quelque soit la structure que vous employez, packages, espaces de noms, dossiers, … Organisez vos classes de telle façon qu’il soit facile et intuitif de trouver le code.%%% > – Organisation logique : tout ce qui appartient à une même organisation logique doit pouvoir accéder aux autres membres, mais ce qui appartient à une structure logique différente doit être accédé par une interface. Ces groupes logiques sont communément implémentés sous forme de couches, services, …%%% > %%% > __6. Créez des lots de tests unitaires.__%%% > %%% > Plus vous avez de tests, mieux c’est, c’est votre filet de sécurité pour tous les changements futurs que nous devrons accomplir dans le code.%%% > %%% > __7. Refactorez souvent et plus rapidement.__%%% > %%% > Le développement de logiciels est un ++[processus de découverte continue|http://www.makinggoodsoftware.com/2009/04/13/what-is-good-software-development/|en]++, afin de maintenir à jour un bon code qui prenne en compte les exigences nouvelles ou modifiées il est essentiel de ++[refactorer le code au fur et à mesure|http://www.makinggoodsoftware.com/2009/05/26/refactoring-the-main-5-questions-why-when-what-how-who/|en]++. Comme il s’agit d’une tâche risquée, il y a 2 principales conditions préalables pour éviter de créer de nouveaux bugs dans le système.%%% > %%% > 1) Avoir beaucoup de tests unitaires.%%% > 2) Refactorez par petites étapes. Dans le développement de logiciels, il n’y rien de plus ennuyeux que de démarrer la refactorisation de 2000 lignes de code et après 3 heures de travail de réaliser qu’il est nécessaire de revenir à la version d’origine parce que plus rien ne fonctionne et que la trace des changements en cause est perdue.%%% > %%% > __8. Commentez, c’est mal.__%%% > %%% > Ce sujet est un peu controversée, la plupart d’entre nous ont appris que les commentaires sont bons, et en fait il est mieux d’avoir un commentaire dans un morceau de code « obscur » que simplement le code par lui-même, ce que signifie : au lieu d’avoir un commentaire sur un morceau de code obscur il est préférable de ne pas avoir ce code du tout, contentez-vous de le refactorez jusqu’à ce qu’il soit convenable et lisible. Je vous invite à lire ++[cet autre billet pour une meilleure explication|http://www.makinggoodsoftware.com/2009/06/06/comments-are-evil/|en]++ de ce que veut dire « commentez c’est mal ».%%% > %%% > __9. Codez une interface, pas une implémentation.__%%% > %%% > C’est un classique, coder une interface doit nous libérer des détails de la mise en œuvre, nous définissons juste un contrat et nous nous reposons sur l’appel des opérations définies dans le contrat, en comptant sur la fait que le mode d’implémentation réelle nous sera transmis ou décidé lors de l’exécution.%%% > %%% > __10. Déclenchez des revues de code.__%%% > %%% > ++[Nous faisons tous des erreurs|http://www.makinggoodsoftware.com/2009/05/22/3-unusual-tips-to-be-a-better-software-developer/|en]++, et il n’y a rien de mieux que de demander à une autre personne d’examiner rapidement et informellement notre code pour les trouver, afin de faire des revues, il est préférable de ne pas attendre que le code soit terminé, il vaut mieux demander des revues à chaque fois qu’une part de code importante a été terminée ou lorsqu’un certain délai s’est écoulé depuis la revue précédente.%%% %%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign| |Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Scrum, Agilité … et Contrôle parental

J’ai eu quelques surprises en activant la fonction « Contrôle parental » sur mon pare-feu. L’accès au ++[blog de Claude Aubry « Scrum, Agilité … et Rock’n roll »|http://www.aubryconseil.com/|fr]++ a été bloqué pour cause de « Jeux de hasard » ! Claude, je pense que vous jouez trop au (Planning) Poker. ;-)%%% %%% ((/dotclear/public/firewall_on_caubry_blog.JPG|Blog de Claude censuré par mon pare-feu !|C|Blog de Claude censuré par mon pare-feu !, aoû 2009))

Comment écrire de bons tests. Top 5 pour construire des logiciels sans défaut.

((/dotclear/public/programmation.gif|Programmation|L|Programmation, aoû 2009))J’ai traduit un article très intéressant provenant du blog de Alberto Gutierrez : « ++[How to write good tests. Top 5 considerations to build software without defects|http://www.makinggoodsoftware.com/2009/08/05/how-to-write-good-tests/|en]++ ».%%% %%% > Le Test a été considéré (et est encore considéré dans certaines entreprises) comme la dernière étape du développement de logiciels, __les développeurs espéraient qu’ils allaient construire leurs applications à partir de zéro et sans erreurs, de sorte que la phase de test serait une simple formalité où seules des erreurs mineures apparaîtraient, heureusement, nous passons de cette utopie à un nouveau concept où le Test fait partie intégrante du processus de développement.__%%% > %%% > Ce qui suit est un extrait des « meilleures pratiques » illustrant ce nouveau paradigme du Test.%%% > %%% > __1. Tester le code est aussi important que produire du code.__%%% > %%% > Une des raisons les plus courantes d’échouer pour les équipes se mettant au TDD est que leurs tests ne sont pas codés proprement, cela peut donc coûter plus cher de maintenir des tests que d’écrire le code du produit logiciel, afin d’éviter ce scénario, il est important de garder à l’esprit qu’avoir des tests codés proprement est aussi important que d’avoir un produit codé proprement.%%% > %%% > __Réutilisez les spécifications de contenu des tests (fixtures).__ Si vous avez besoin de certaines données pour mener différents tests, rendez les réutilisables et disponibles en un seul endroit.%%% > %%% > __Écrivez vos propres assertions.__ Si vous testez des données dans 5 scénarios différents, et si vous voulez prouver que tout fonctionne bien pour chacun des scénarios, vous avez besoin de 5 assertions différentes, écrivez donc votre propre assertion qui effectue les 5 autres et appelez-la depuis votre code, au lieu d’écrire 25 assertions différentes.%%% > %%% > __En général, utilisez les mêmes principes que ceux que vous appliquez pour écrire le code de votre produit logiciel :__ dans cet autre billet, vous trouverez plus d’indications pour écrire du bon code: ++[10 commandements pour écrire un bon code|http://www.makinggoodsoftware.com/2009/06/04/10-commandments-for-creating-good-code/|en]++.%%% > %%% > Pour aller plus loin, je vous recommande fortement la lecture du livre suivant: « ++[xUnit Test Patterns: Refactoring Test Code|http://www.amazon.com/xUnit-Test-Patterns-Refactoring-Addison-Wesley/dp/0131495054/ref=sr_1_1?ie=UTF8&s=books&qid=1249513626&sr=1-1|en]++ ».%%% > %%% > __2. Testez autant que possible, testez dès que possible, testez le plus souvent possible.__%%% > %%% > Comme je l’ai dit dans ++[mon précédent billet|http://www.makinggoodsoftware.com/2009/08/03/fitnesse-and-xunit-the-perfect-tdd-marriage/|en]++, je suis un développeur TDD convaincu, mais peut-être ne l’êtes vous pas, ce qui est important est que peu importe si vous écrivez le test avant ou après, __vous ne devez pas écrire de nouveau code avant d’avoir un test qui prouve que le code que vous venez d’implémenter fonctionne comme prévu__. Cette habitude de tester autant que possible, dès que possible et aussi souvent que possible, vous empêchera de créer de nouveaux bugs dans le système, et cela vous rendra donc également plus confiant et plus productif.%%% > %%% > __3. Testez à différents niveaux.__%%% > %%% > N’essayez pas d’écrire des tests qui couvre aussi bien l’IHM que le « backend », cela prend trop de temps à écrire, c’est difficile à maintenir, c’est lent à exécuter, c’est également très difficile de tester tous les différents éléments de votre application si vous ne les avez pas séparé, la meilleure approche est de tester à différents niveaux. Envisager d’avoir au minimum la série de tests suivante :%%% > %%% > ++[Tests unitaires|http://en.wikipedia.org/wiki/Unit_testing|en]++. Tests qui vérifient tous vos composants séparément, sans tenir compte de leurs interactions avec d’autres composants.%%% > %%% > ++[Tests d’acceptance|http://en.wikipedia.org/wiki/Acceptance_testing|en]++. Spécifiés par le Product Owner, ces tests représentent le minimum de fonctionnalités que l’application doit fournir pour être accepté d’un point de vue métier.%%% > %%% > ++[Tests d’intégration|http://en.wikipedia.org/wiki/Integration_testing|en]++. Ces tests ne sont pas identifiés par le Product Owner dans ses tests d’acceptance mais élaborés soit par l’Assurance Qualité soit par le développement.%%% > %%% > __Tests d’IHM__. Les tests IHM sont lents, l’IHM est également susceptible de changer durant le développement et l’on doit donc réaliser des tests ciblés, en conservant les tests IHM séparés des tests backend nous ne serons donc pas impactés à chaque fois que l’IHM change.%%% > %%% > __4. Le Test fait partie intégrante du process de développement. Intégration continue.__%%% > %%% > __Le Test doit faire partie intégrante du processus de développement, une chose n’est pas terminée tant qu’elle n’a pas été testée__, oubliez le fait d’avoir une étape différente dans laquelle une personne se soucie des tests, tout le monde est responsable et validateur des tests : le développement, l’assurance qualité et le product owner. Idéalement, vous pourrez également mettre en place une intégration continue, qui dépasse le périmètre des tests, pour plus d’information sur l’intégration continue je vous renvoie sur cet excellent article de ++[Martin Fowler|http://martinfowler.com/articles/continuousIntegration.html|en]++.%%% > %%% > __5. Utilisez des outils de tests et des frameworks.__%%% > %%% > Heureusement, il existe un ensemble d’outils et de frameworks développés récemment pour nous aider à tester nos applications, une sélection de ces outils suit :%%% > %%% > ++[FitNesse|http://fitnesse.org/|en]++. Un outil pour créer des tests d’acceptance, les non techniciens peuvent écrire leurs propres tests.%%% > %%% > ++[xUnit|http://en.wikipedia.org/wiki/XUnit|en]++. Framework pour développer des tests unitaires, intégrés avec les plus populaires IDEs et langages de programmation.%%% > %%% > ++[CodeCover|http://codecover.org/|en]++. Un plugin Eclipse pour la couverture de code, utile pour savoir quelles parties du code nous sommes en train de tester et celles qui ne le sont pas.%%% > %%% > ++[Jira|http://www.atlassian.com/software/jira/|en]++. Un outil de reporting et de traçabilité, majoritairement utilisé pour tracer les bugs.%%% > %%% > ++[Mercury|http://en.wikipedia.org/wiki/Mercury_Interactive|en]++. Suite logicielle très connue, composée de différents outils pour différents types de tests, y compris les tests d’IHM.%%% > %%% > ++[Selenium|http://seleniumhq.org/|en]++. Outil de test d’IHM pour les applications web.%%% > %%% > ++[Hudson|https://hudson.dev.java.net/]++. Outil d’intégration continue, utilisé pour garantir que le code est toujours prêt à être livré et qu’il est passé à travers toutes les batteries de tests. Je ne résiste pas à ajouter ce dessin de ++[CodeSmack|http://tshirts.codesmack.com/tshirts/agile]++ :-)%%% [((/dotclear/public/./.All-Code-Is-Guilty_t.jpg|All Code Is Guilty||All Code Is Guilty))|/dotclear/public/All-Code-Is-Guilty.jpg]%%% %%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign| |Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

7 + 1 conseils pour nommer les variables

((/dotclear/public/programmation.gif|Programmation|L|Programmation, aoû 2009))J’ai traduit un article plein de bon sens provenant du blog de Alberto Gutierrez : « ++[7+1 tips for naming variables|http://www.makinggoodsoftware.com/2009/05/04/71-tips-for-naming-variables/|en]++ ».%%% %%% > __1. Le nom de la variable doit être aussi descriptif que possible. N’utilisez pas de noms génériques.__%%% > %%% > Bons exemples : daysDateRange, flightNumber, carColor.%%% > Mauvais exemples : days, dRange, temp, data, aux, …%%% > %%% > Beaucoup de développeurs vont préférer donner des noms courts aux variables plutôt que des noms descriptifs pour gagner du temps lorsqu’il tape le code, mais qui s’en soucie ? Cela ne contribue pas à améliorer la qualité du logiciel, cela permet seulement de gagner quelques minutes par jour (maximum) et par développeur, alors que, lorsque les noms de variables sont descriptifs, la qualité générale du logiciel va augmenter parce que ce sera plus facile de lire et modifier le code.%%% > %%% > __2. Le nom de la variable doit être aussi court que possible.__%%% > %%% > Cette règle va de pair avec la première règle, les noms des variables doivent être aussi courts que possible, mais aussi descriptif que possible. Cela signifie que même si nous continuons à essayer de trouver des noms courts, nous accordons la priorité à des noms descriptifs plutôt qu’à des noms courts, et nous ne faisons que prendre le plus court quand ils sont aussi descriptifs que le plus long.%%% > %%% > Mauvais exemples: howLonDoesItTakeToOpenTheDoor, howBigIsTheMaterial, …%%% > Bons exemples: timeToOpenTheDoor, MaterialSize.%%% > %%% > __3. D’accord pour utiliser des abréviations, mais expliquez l’abréviation par un commentaire.__%%% > %%% > Parfois, pour avoir un nom bien descriptif, il est nécessaire de produire des noms de variables très longs, ce qui est bien, mais la taille du nom de la variable peut être améliorée en utilisant des abréviations, assurez-vous simplement que, lorsque la variable est déclarée, il y a un commentaire qui explique sa signification.%%% > %%% > __4. Utilisez la notation Hongroise si nécessaire.__%%% > %%% > Il y a un ++[très bon billet de Joël|http://www.joelonsoftware.com/articles/Wrong.html|en]++ qui explique ce qu’est la notation hongroise et comment l’utiliser. Fondamentalement, il est dit que lorsque une méthode de codage que nous avons les mêmes variables d’exploitation des données, mais aussi avec différents types, la notation hongroise peut nous aider. Fondamentalement, il est dit que si dans une méthode on code avec des variables exploitant des données identiques, mais de types différents, la notation hongroise peut nous aider.%%% > %%% > Exemple : imaginer une méthode qui reçoit des pommes, et qui classe les pommes selon leurs couleurs, et finalement écarte celles qui ne sont pas assez mûres. Nous pouvons utiliser dans cet exemple les noms de variables suivants : incoming_apples, red_apples, yellow_apples, notMaturedYellow_apples, maturedGreen_apples, …%%% > %%% > __5. N’utilisez pas de logique négative pour vos noms de variables.__%%% > %%% > Bon exemple : IsEnabled.%%% > Mauvais exemple : IsNotEnabled.%%% > %%% > Il est toujours plus facile de lire et comprendre un énoncé qui est exprimé dans un langage dans la forme positive que dans sa forme négative.%%% > %%% > __6. Soyez cohérent.__%%% > %%% > Si vous avez utilisé un nom de variable appelé « customer » dans une méthode, alors il ne faut pas l’appeler « client » dans la méthode suivante, ou si vous utilisez une abréviation dans une méthode, utilisez-la pour toutes les autres méthodes.%%% > %%% > __7. Faites correspondre la terminologie du métier de l’application avec vos noms.__%%% > %%% > Dans différents domaines, différents concepts ont des sens très différents et précis, par exemple, « ordre » ne signifie pas toujours la même chose dans les différents domaines, essayez donc de faire correspondre ces concepts spécifiques à vos noms de variable de sorte que lorsque vous nommez quelque chose avec le nom d’un concept provenant du domaine métier de l’entreprise, cela signifie exactement la même chose.%%% > %%% > Exemple : Si votre client considère que « order » est juste une « commande » qui a été acceptée, n’utilisez pas « order » pour nommer dans votre code une commande non acceptée, appelez-la dans ce cas « nonApprovedOrder ».%%% > %%% > __Règle d’or. Investissez quelques minutes pour penser à vos noms de variables.__%%% > %%% > Si vous vous retrouvez à écrire des noms de variables dès que vous en avez besoin dans votre code sans même réfléchir une seconde à leur nom, vous êtes probablement en train de choisir de mauvais noms.%%% > Si vous essayez toujours d’avoir de bons noms de variables, et que vous y avez consacré quelques minutes pour trouver le meilleur nom, même si vous ne suivez pas les autres conseils, vous allez probablement utilisé de très bons noms de variables dans votre code.%%% %%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.