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'application rigoureuse de la méthode 5S

Publié par David Beaumier, Jean-Francois Gilbert le mercredi 15 juillet 2015 à 17:05

Dans ce dernier billet sur l’application de la méthode 5S en développement logiciel nous abordons l’opération suivre (ou Shitsuke en japonais). Cette 5ième opération vise à contrôler l’application rigoureuse des 4 premiers « S ». En anglais, le terme sustainable est utilisé. L’objectif est donc de s’assurer d’une adoption durable de la méthode.

Sans cette étape de vérification, votre équipe court le risque de revenir à ses vieilles habitudes et de perdre tranquillement les bénéfices qu’elle a obtenu en mettant en œuvre la méthode. Cette opération apporte à la méthode 5S l’aspect contrôle et adaptation qu’on associe fréquemment aux pratiques agiles, telles que Scrum.

Cycle 5S

On doit graduellement apprendre à identifier des façons de ne pas retomber dans ses ornières. Comment peut-on faire pour ne pas qu’un problème ne puisse se produire de nouveau? Par exemple, comment s’assurer que le client ne puisse pas entrer une valeur de configuration qui rende le logiciel instable? Il y a autant de solutions que de problèmes, mais j’aime beaucoup utiliser la photo ci-dessous pour illustrer comment il est possible de mettre en place un mécanisme (simple) pour empêcher le contournement d’une consigne qui pourrait avoir d’importantes conséquences.

5S Suivre

Les pratiques de développement qui peuvent vous aider

Plusieurs des pratiques proposées par eXtreme Programming visent justement à s’assurer que l’équipe puisse mettre en place un cycle de développement qui soit réellement incrémental (pas de régression entre les livraisons fréquentes). Parmi celles-ci on retrouve la programmation pilotée par les tests (TDD), la programmation en paire, les tests d’acceptation par les clients et l’intégration continue.

Si vous n’avez pas déjà une solution d’intégration continue en place, ou si celle-ci laisse à désirer, je vous suggère la lecture de Continuous Integration: Improving Software Quality and Reducing Risk. Une fois un serveur d’intégration continue en place il devient beaucoup plus facile d’automatiser la prise de mesures et de publier les résultats de façon centralisée, pour le plus grand bénéfice de l’équipe.

Livre CI

Une autre suggestion est d’automatiser toutes les vérifications qui peuvent l’être. C’est un des avantages du développement logiciel : nos activités sont généralement vérifiables et on sait comment automatiser (enfin, j’espère)! Par exemple, est-il possible d’écrire un test pour vérifier que personne n’introduise par inadvertance un nouveau schéma dans la base de données? Peut-on valider la valeur saisie dans le fichier de configuration et donner un message d’avertissement si elle n’est pas conforme, évitant ainsi un problème à l’exécution?

Les outils d’automatisation de la configuration comme Chef ou Puppet permettent de gérer la configuration de vos environnements sous forme de cible, réduisant ainsi les risques d’introduire un problème lors d’une manipulation manuelle.  Une liste de vérification c’est bien, mais si on peut l’automatiser c’est mieux!

Intégrer le suivi à votre cadre de travail

Pour ceux qui utilisent Scrum comme cadre de travail, n’hésitez pas à adapter la cérémonie de la revue de sprint pour y inclure un suivi de vos initiatives 5S. C’est un bon moment pour faire le point sur celles en cours, celles qui sont complétées (et les bénéfices que vous en retirez) et pour en proposer de nouvelles. Si vous utilisez une approche Kanban en flux tiré, pourquoi ne pas prévoir une rencontre hebdomadaire de quelques minutes pour discuter des opportunités d’amélioration en cours? Nous sommes certains que 10 à 20 minutes investis à ce niveau permettront à l’équipe de faire le point sur les initiatives en cours et d’identifier celles qui seraient bénéfiques à entreprendre.

Pour mesurer l’impact de chacune de vos initiatives nous vous recommandons premièrement d’identifier le point de départ (état initial) et la cible que vous poursuivez. Ensuite, déterminez quelles mesures vous permettront de vérifier l’atteinte de votre cible (diminution de 7% des appels de service, augmentation de 5% de la satisfaction des clients, etc.).

Vue externe

Si votre équipe le souhaite, et qu’elle possède la maturité suffisante pour le faire, il peut être intéressant de faire appel de façon sporadique à un « vérificateur externe ». Celui-ci aurait comme rôle de valider que l’équipe est en mesure de démontrer qu’elle applique les façons de faire qu’elle prétend avoir mis en place et qu’elle est en mesure de s’auto vérifier. Il est important de voir ce suivi comme une opportunité de développer les gens et améliorer les façons de faire pour le bénéfice du produit et de l’organisation et non comme une façon de les contrôler ou d’évaluer leurs performances.

Pour cette raison, le rôle du vérificateur aura avantage à être exercé par une personne d’une autre équipe. En plus, cela permet un partage intéressant sur les façons de faire à l’intérieur de l’organisation.

Conclusion

Tel que le mentionne le manifeste Agile, il est préférable de « valoriser les individus et leurs interactions plutôt que les processus et les outils ». L'utilisation de la méthode 5S ne devrait pas vous en écarter. Gardez en tête que 5S n’est qu’un moyen parmi d’autres pour améliorer vos façons de faire. En fin de compte, c’est l’implication et la passion de votre l’équipe qui assurera le succès de vos projets!

Travailequipe

Mise à jour

Voici les liens pour consulter les autres articles.

D’autres billets qui pourraient vous intéresser

Standardiser ses activités de développement

Publié par David Beaumier, Jean-Francois Gilbert le mercredi 29 avril 2015 à 14:33

Pour ce 4ième billet de la série sur l’application de la méthode des 5S en développement logiciel nous aborderons l’aspect standardisation (ou Seiketsu en japonais). Ce principe vise principalement à :

  • Standardiser les meilleures pratiques;
  • S’assurer que chaque processus est appuyé sur une façon de faire éprouvée et connue;
  • Maintenir le niveau de qualité dans l’ensemble des activités;
  • Préserver l’ordre et la propreté (les 3 premiers s).

On ne parlera donc pas des normes telles que CMMI, Macroscope ou ITIL dans ce billet. La standardisation dont on parle est à un niveau beaucoup plus tactique et se trouvera complémentaire à vos processus.

Établir les règles

Clean CodePeu importe les conventions, normes et orientations que vous choisirez, l’important est qu’elles soient suivies. Certains membres de l’équipe pourraient préférer une approche différente et ils ont tout à fait le droit. Cela ne devrait toutefois pas les autoriser à contourner les règles communes. Pour favoriser l’adoption de ces règles et faire en sorte qu’elles soient accordées au « nous » il est toujours préférable de les choisir collectivement que de les imposer.

Un des bons points de départ peut être que chaque membre de l’équipe fasse la lecture (ou la relecture) du livre Clean Code de Bob Martin. Même s’il date d’un peu plus de 6 ans, ce livre demeure une référence incontournable pour qui veut produire du code de qualité. J’ai été agréablement surpris de voir qu’il était toujours dans le top 20 des meilleurs vendeurs en développement logiciel.

Adopter un standard de programmation

Bon nombre de ces standards ont déjà été écrits. Vous pourriez donc vous sauver bien du travail en adoptant une convention existante. Par exemple :

Si vous choisissez d’en bâtir un qui soit spécifique à votre équipe, essayez tout de même de respecter les conventions habituelles de votre langage (les nouveaux équipiers vous en seront très reconnaissants). Adoptez aussi un style concis : énoncez la règle et évitez les longues justifications.

N’oubliez pas le code qui tourne autour des bases de données. Sans standard les artéfacts peuvent devenir rapidement aussi différents les uns des autres que le sont les flocons de neige. Encore plus vrai si vous utilisez des artéfacts contenant de la logique (fonctions, procédures stockées, etc.). L'uniformisation de votre base de données viendra aussi vous simplifier la vie si vous souhaitez éventuellement intégrer un ORM car la conversion OO-SGBD s'appui sur une convention.

Au-delà des conventions

La standardisation va bien au-delà des simples conventions.  Ce souci d’uniformisation devrait transparaître dans l’ensemble de votre application.  Prenons l’exemple de Sonos, ce système intelligent de haut-parleurs sans-fil. Sonos propose une application servant à contrôler votre système sur les plateformes les plus répandues (Android, iOS, Mac et Windows). L'entreprise s'est efforcée de standardiser l'expérience utilisateur entre toutes ces plateformes, ce qui fait que vous bénéficierez d'un « look and feel » cohérent que vous utilisez la version iOS ou Windows. En plus, Sonos a réussi cette standardisation tout en tirant profit des capacités particulières à chaque plateforme.

Dans votre application, la standardisation devrait donc transparaître autant de l’intérieur (le code) que du point de vue du client. Voici quelques exemples de standardisation dans un applicatif :

  • Établir un vocabulaire uniforme du domaine d’affaire et s’y référer constamment;
  • Définir des abstractions-clé arrimées avec le domaine d’affaires et en promouvoir l’utilisation dans le vocabulaire autant que dans le code;
  • Favoriser la création de classes réutilisables;
  • Bâtir des mécanismes de déploiement automatisés;
  • Proposer une expérience utilisateur uniforme dans tous les modules.

Une équipe qui gère les dépendances entre les fichiers Javascript à l’aide d’une approche déclarative (telle que proposée par RequireJS) se trouve à standardiser ses façons de faire tout en améliorant la qualité du code et en offrant une meilleure vitesse d’exécution pour l'utilisateur.

Détecter les écarts

Si vous souhaitez maintenir le niveau de qualité à long terme, rien de mieux que de mettre en place des points de contrôle fréquents, idéalement automatisés. Dès que vous trouvez un écart par rapport à la cible, trouvez un moyen que cette situation ne se reproduise pas. Avec le temps vous bâtirez un solide harnais de sécurité.

Un plugiciel comme Checkstyle (pour Eclipse), Rubocop en Ruby ou FxCop (la fonctionnalité Static Code Analysis de Visual Studio) permet de vérifier si les standards de programmation sont respectés. Il est possible de choisir quelles règles doivent s’appliquer et même d’en développer des personnalisées, si besoin est.

Checkstyle

Il est même possible d’appliquer des vérifications automatisées au niveau du respect des principes d’architecture. Visual Studio offre la possibilité de valider que les dépendances entre les différents projets de votre solution respectent les choix que vous avez faits au niveau du diagramme d’architecture. Cette validation peut même être intégrée au processus d’intégration continue. Vous aurez rapidement une rétroaction si un équipier contourne le modèle établi. Beaucoup plus intéressant que de le réaliser quelques semaines plus tard!

Regarder le processus dans son ensemble

Le principe de standardisation aura avantage à s’appliquer au-delà des activités de « codage ». Si vous ne l’avez pas déjà fait, pourquoi ne pas illustrer votre processus de développement dans son ensemble. Cela vous permettra de voir les grandes activités qui le composent et creuser pour voir quels sont les standards existants pour chacune d’elles.

Par exemple, est-ce que la gestion du carnet est standardisée? Est-ce que la formule « En tant que <acteur> je veux <besoin> afin de <bénéfice d’affaires> » est systématiquement utilisée pour vos stories? Les critères d’acceptation sont-ils définis avant la cérémonie de planification? Est-ce que le carnet de produit est révisé (backlog grooming) sur une base régulière? Ce sont toutes des activités qui auront avantage à être standardisées selon votre réalité.

Il en sera de même pour les activités de déploiement (le fameux DevOps) ou de prise en charge des demandes des clients. En fait, standardiser ce type d’activités aura un double bénéfice en offrant à vos clients une expérience beaucoup plus uniforme et prévisible.

Enseigner et diffuser

Vous aurez beau établir les meilleurs standards, développer des procédures simples et précises et offrir des outils hors-pairs, si les membres de votre équipe ne savent pas qu’ils existent ou comment les utiliser, vous risquez de ne pas être plus avancés!

Il existe une foule d’outils disponibles pour consigner ce genre d’information. Peu importe l’outil que vous choisirez (tel qu’un wiki, par exemple), assurez-vous que l’outil en question offre un bon moteur de recherche et encouragez les gens à s’y référer et, surtout, à garder le contenu à jour.

Prévoyez aussi accompagner les gens de votre équipe. Il se peut que le p’tit nouveau oublie d’appliquer certaines des règles de conception (pourtant inscrites dans le wiki) et un rappel amical peut faire toute la différence. La programmation en paire ou les revues de conception sont des façons de guider les équipiers dans l’application des standards.

Contrôler et adapter

La standardisation n’est pas une activité dogmatique et elle ne vise pas à réduire la capacité d’innovation de votre équipe. Il ne faut pas hésiter à remettre en question les façons de faire afin de ne pas tomber dans le piège du « c'est de même que ça se fait depuis toujours ici ». On le sait, en informatique la technologie et les outils évoluent à vitesse grand V. Les façons de faire doivent s'adapter. Les rétrospectives d’équipe sont un bon moment de se questionner sur les standards existants et proposer des changements qui seraient bénéfiques.

Mise à jour

Voici les liens pour consulter les autres articles.

D'autres billets qui pourraient vous intéresser

Nettoyer votre code pour le rendre 5 S

Publié par David Beaumier, Jean-Francois Gilbert le lundi 20 avril 2015 à 08:13

Nous voilà rendus au 3ième concept de la méthode 5S : nettoyer (ou seiso en japonais). Comment ce principe, pensé à la base pour éviter la détérioration de la machinerie et des équipements, peut-il s’appliquer en développement logiciel?

Revenons pour une seconde aux fondements de la méthode 5S : une fois l’espace de travail ordonné (le premier S) et rangé (le second S), il devient beaucoup plus simple de le nettoyer puisque ce qui a besoin de nettoyage devient dès lors visible.  En développement, on pourrait penser à ces bouts de codes qui ont mal vieilli et qui handicapent d’une façon ou d’une autre le système. La fameuse dette technique, quoi!

Évidemment, pas besoin d’avoir fait les étapes 1 et 2 dans l’ensemble du code pour pouvoir passer au nettoyage. En procédant ainsi vous risqueriez même de salir de nouveau certains coins si l’application est d’une certaine envergure. Pourquoi ne pas directement cibler les morceaux qui sont connus pour dégager une odeur (virtuelle, on s’entend) nauséabonde? Probablement qu’il faudrait très peu de temps à l’équipe pour les identifier!

Nous vous proposons dans ce billet quelques suggestions pour procéder au nettoyage de votre base de code.

La règle des scouts

La bonne vieille règle des scouts, soit celle de laisser le campement plus propre au départ qu’à l’arrivée, peut être une bonne façon de procéder à un nettoyer graduel de votre code. En effectuant ici et là une extraction de méthode, un renommage ou en révisant une condition en introduisant un guard clause (quelqu’un a une bonne traduction à proposer?) votre équipe en viendra à rehausser la maintenabilité de la base de code. Et cela, sans impacter de façon significative son rythme de livraison habituel.

L’important dans toute opération de nettoyage de cette envergure est de se donner des objectifs atteignables, de mesurer la progression régulièrement (tous les sprints, par exemple) et d’ajuster le tir en fonction de ce que vous découvrirez. C’est surprenant de voir ce qu’on peut accomplir lorsqu’on rend visible la crasse qui se cache dans certains recoins du code!

Réingénierie (refactoring)

La réingénierie logicielle est la technique qui revient le plus souvent lorsqu’on parle de nettoyer du code existant.

La réingénierie logicielle est un processus ayant pour objectif de transformer et améliorer un logiciel à partir du modèle existant sans toutefois modifier son comportement externe.

Livre RefactoringtopatternMême si elle est simple à comprendre, c’est une technique qui demande beaucoup de pratique pour développer les bons réflexes et savoir bien doser son utilisation. Si vous débutez avec cette pratique, la lecture du livre Refactoring: Improving the Design of Existing Code de Martin Fowler s’avère toujours un bon point de départ (même après plus de 15 ans). Un catalogue des différents types de réingénierie est aussi disponible en ligne.

Le livre de Kerievsky s’adressera quant à lui aux personnes qui ont déjà un peu d’expériences avec la réingénierie et qui souhaitent voir comment cette technique peut être combinée avec les patrons de conception.

Scott Ambler et Pramod Sadalage ont même appliqué les principes de la réingénierie logicielle aux bases de données relationnelles dans leur livre Refactoring Databases: Evolutionary Database Design.  Vous n’aurez dorénavant plus aucune excuse pour ne pas nettoyer votre schéma de base de données!

Outils disponibles

Il existe aujourd’hui des fonctionnalités de réingénierie dans pratiquement tous les IDEs. Sinon, des extensions plus avancées peuvent vous aider, tel que Resharper sous Visual Studio. Ces outils vous sauveront du temps, tout en évitant les erreurs typiques associées aux opérations manuelles de rechercher/remplacer.

Des outils spécialisés pour les SGBDR, tels que Liquibase ou SQL Server Data Tools vous aideront à produire les scripts de mise à jour requis pour offrir une cure de jeunesse à vos bases de données. La vidéo ci-dessous vous permettra d'avoir un aperçu de l'utilisation de Liquibase.

Identifier les candidats potentiels au nettoyage

Encore une fois, les techniques du management visuel peuvent venir à notre rescousse pour vous aider à identifier les bouts de code qui sont de bons candidats à la réingénierie. Par exemple, l'extension Microsoft CodeLens Code Health Indicator (pour Visual Studio Ultimate) permet d’obtenir plusieurs mesures sur la maintenabilité du code et l’indicateur visuel vous indiquera si vous êtes face à un bout de code qui rencontre les exigences (en tout cas, celles de Microsoft). On peut même voir si la modification courante améliore ou non le code et ajuster le tir au besoin. Ça réduit de beaucoup la boucle de rétroaction.

Codehealth

SourceMonitor est un autre outil qui peut aider à identifier les classes qui ont besoin d’un peu d’amour. Bien qu’il ne soit pas directement intégré à un IDE, SourceMonitor a l’avantage de supporter plusieurs langages de programmation, tels que C++, C, C#, VB.NET, Java et Delphi. Il permet de cibler un sous-ensemble plus ou moins grand de votre base de code et produit les métriques de différentes façons, tel que démontré ci-dessous. Il est aussi possible d'en automatiser l'utilisation de façon à prendre des mesures sur une base régulière.

Sourcemonitor

Et vous, quels sont les techniques et outils qui vous permettent de nettoyer votre code? Quels approches ont été les plus bénéfiques pour votre équipe?

Mise à jour

Voici les liens pour consulter les autres articles.

D'autres billets qui pourraient vous intéresser

Appliquer les principes du « 5 S » dans votre code – Ranger

Publié par David Beaumier, Jean-Francois Gilbert le jeudi 9 avril 2015 à 07:45

Dans ce second article de la série sur l’application de la méthode 5S en développement logiciel nous abordons le second concept : ranger (ou Seiton, en japonais). On peut résumer le concept de cette façon : « Une place pour chaque chose, et chaque chose à sa place » (source : Wikipedia).

Le but derrière cette notion de rangement est de s’assurer que les équipiers ne perdent pas de temps de travail à chercher les éléments dont ils ont besoin dans le cadre de leur travail. Dans le cas du développement logiciel il peut s’agir autant des classes communes, d’utilitaires pour effectuer certaines opérations que de documentation sur les patrons de conception. Quoi de plus frustrant que de chercher pendant plusieurs minutes où a été déposé l’utilitaire qui permet de convertir une base de données!

Vous trouverez ci-dessous quelques suggestions pour optimiser le rangement dans votre équipe de développement logiciel.

Bien structurer votre projet

Le découpage (dossiers) de votre projet devrait s’appuyer sur le vocabulaire du domaine d’affaires. Il est important d’avoir une uniformité dans le langage utilisé et cela doit se refléter dans le code aussi. Si on parle de « gestion des accès » dans votre application on ne devrait pas retrouver un dossier « autorisations » dans le projet.

Dans un projet Web, il peut être aussi intéressant de penser à une structure qui permette de rapidement distinguer les artéfacts selon qu’ils s’appliquent à la structure du document (html), aux styles (CSS) ou au code (JS).

Assurer une cohérence physique des dossiers et des paquetage

Des outils comme Resharper vous indiqueront s’il existe des écarts entre les dossiers physiques et le nom des paquetages (namespaces dans ce cas-ci). Avec le temps, on peut avoir renommé quelques dossiers, mais avoir oublié de faire les ajustements dans le code.

5S Ranger Resharpernamespacelocation

Valider la dépendance entre les paquetages

 La dépendance entre les paquetages devrait,  elle aussi, respecter le découpage fonctionnel. Ces dépendances sont souvent exprimées en UML sous forme de diagramme de paquetages.

Les fonctionnalités de Dependency Graph et de CodeMap de Visual Studio permettent de dresser une cartographie des dépendances qui vous permettra de valider que celles-ci sont conformes à la cible.

5S Ranger Dependencygraph

5S Ranger Vscodemap

Des outils comme JArchitect peuvent produire diverses métriques sur le niveau de dépendance entre les différentes parties du code. Celles-ci vous permettront de vérifier si les principes architecturaux ont été respectés et vous éviteront d’avoir un couplage trop fort entre les entités de votre système, ce qui a tendance à rendre l'entretien et la réingénierie plus difficile à long terme.

5S Ranger Dependencymatrix

N’oubliez pas la documentation

On ne parle pas ici de la documentation du code source en lui-même (bien qu’elle soit importante), mais plutôt de celle qui forme la base de connaissances de votre équipe. Comment un nouvel équipier saura quel outil utiliser pour produire un script de mise à jour de la base de données relationnelle? Où trouvera-t-il les règles de nomenclatures à respecter?

Que vous utilisiez un wiki ou un autre outil de gestion documentaire, assurez-vous d’y consigner les informations importantes. Souvent, un bref résumé et quelques liens pertinents permettent de conserver une documentation suffisante sur un sujet. Comme le disait Albert Einstein, « Ne mémorisez pas une information que l’on peut facilement retrouver ».

Mise à jour

Voici les liens pour consulter les autres articles.

D'autres billets qui pourraient vous intéresser

Leçon de vie

Publié par Jean-Francois Gilbert le lundi 9 mars 2015 à 00:00

Il y a quelques temps, j'ai commencé à travailler sur une preuve de concept relativement complexe. Au départ, je n'avais qu’une vague idée des outils et de l’architecture que j’allais utiliser. Il y avait tellement d'inconnus que je ne savais pas trop par où commencer. 

J'ai donc avancé le projet un peu à tâtons. Je m’efforçais de répondre aux exigences fonctionnelles complexes tout en explorant une plateforme que je connaissais peu. Bref, j'en avais un peu par-dessus la tête. Pour sauver du temps et parce que je croyais tout jeter à la poubelle de toute façon, j'ai commencé à coder sans écrire de tests unitaires. Je vois d’ici vos hochements de tête désapprobateurs. Mais je croyais que les chances que mon code puisse être réutilisé plus tard étaient tellement minces que ça me ralentirait d’écrire des tests tout de suite. Oh, mais quelle erreur !

Au début, je dois avouer que ça allait plutôt bien. J'essayais des choses, je changeais d'idée, j’effaçais le code, j’essayais autre chose. Pas de temps à perdre, je produisais du code à la vitesse grand V ! Étant habitué à programmer presqu'exclusivement en mode TDD, je ressentais quand même un certain malaise. Je n'avais pas mon filet de sûreté habituel et je n’étais pas particulièrement fier du design de mes classes. Mais bon, mon prototype fonctionnait, non ?

A un certain moment j’ai réalisé que globalement, la piste que je suivais depuis plusieurs jours était la bonne. Il y avait bien quelques inconnus ici et là, mais je commençais à avoir entre les mains quelque chose d’intéressant. Or, puisque j'avais codé un peu en cow-boy, le design n'était pas génial et ma solution commençait à être sens dessus dessous. J'ai donc commencé à faire du réusinage pour être capable de mieux me retrouver. C'est à ce moment que des bugs ont commencé à faire surface. Je me suis mis à perdre un temps fou. Les modifications étaient suivies par des séances de débogage dans Visual Studio et je maudissais les dieux de la programmation, mais surtout moi-même. Au lieu d'avancer, je faisais des pas en arrière à chaque fois que je modifiais du code.

Je n'ai eu d'autre choix que de recommencer du début. Mais cette fois, j'ai bâti mon code comme je suis habitué de le faire : en TDD. J’ai quelque fois eu le goût de prendre le code du prototype et le copier dans mes nouvelles classes, mais j'ai presque toujours résisté à la tentation. Bien sûr, j'ai gardé certains concepts mais le fait de recommencer du début a fait émerger un design différent et surtout meilleur.

En bref, soyez plus brillants que moi. Prenez le temps de bien faire les choses dès le début et en bout de ligne vous gagnerez du temps. Je crois qu'on peut se permettre d'expérimenter de nouveaux outils sans faire de tests unitaires exhaustifs. Mais il faut savoir identifier le moment où on a une assez bonne idée de la solution et reprendre les bonnes pratiques de développement.

En terminant, voici quelques billets qui pourraient vous intéresser concernant le TDD et les tests unitaires.

Jusqu'à quel point dois-je tester mon code ?

TDD : comment partir du bon pied ?

Comment rendre vos tests plus propres grâce aux builders ?

 

Archive