Copier le contenu d’une liste en python, pas sa référence
Quand j’ai commencé à coder en python, j’ai passé un peu de temps sur des problèmes de copies de listes. Regardez cet exemple :
»> a = [‘1’,’2’,’3’]
»> b = a
»> a[2] = ‘4’
»> b[2]
‘4’
Quand je fais b = a je copie les références. L’objet liste [‘1’,’2’,’3’] n’est pas dupliquée en mémoire. Pour être sur, il suffit de lancer la commande id( ) qui donne l’id de l’objet passé en paramètre.
»> id(a)
11889480
»> id(b)
11889480
b et a pointent vers le même objet liste.
J’ai cherché une manière « pythonique » de copier le contenu d’une liste dans une autre. Et j’aime beaucoup la manière suivante :
b = list(a)
list( ) est le constructeur d’une liste. La fonction vient créer une nouvelle liste avec la séquence passée en paramètre. Elle construit une nouvelle liste.
»> id(b)
11868840
Avant j’utilisais b = a[:] que je trouve moins explicite que b = list(a)
The discipline of Test Driven Development has made a profound impact upon our industry and has become one of our most fundamental disciplines.
La contractualisation agile dans une SSII
Rien qu’en lisant le titre, je fais la grimace. Le contrat a été inventé pour se prémunir des tentatives d’un des deux partis pour exploiter l’autre. Et c’est un outil indispensable dans n’importe quel projet informatique. Dans ce billet j’essaye de répondre à la problématique suivante :
Comment aujourd’hui une société de service peut-elle faire de l’agilité sur un projet au forfait avec un engagement de résultat ?
Douloureux comme problématique ! Pour simplifier le contexte, je me place dans le cas concret où un client effectue un appel d’offre et la société de service envoie une proposition technique et financière. Généralement le contrat essaye de fixer les délais, les coûts, le périmètre fonctionnel du projet. C’est pour cette raison que souvent, on s’appuie sur le cahier des charges pour valider le contrat.
Engagement de résultat implique une notion de « terminée » du point de vue du client. Le client attend une proposition pour réaliser « l’ensemble » des fonctionnalités du produit décrites dans le cahier des charges. Il s’attend par la même occasion à ce que le produit final comporte aussi l’ensemble des fonctionnalités énoncées dans le besoin initial.
En plus une prestation au « forfait » nous retire toute possibilité de pilotage. L’ajustement en fonction de l’évolution du projet sur le terrain est impossible. Nous savons que nous avons les mains liés, mais nous continuons à nous engager. Le prix de la prestation augmente.
Vous l’aurez compris tout le monde est perdant!
S’adapter au changement
L’objectif de la contractualisation est de proposer une réponse qui prenne en compte ce « changement » tout en assurant au client que ce qu’il demande sera bien réalisé !
Ne jamais s’engager sur un nombre de fonctionnalité ! Mais engager-vous sur un volume d’unité d’oeuvre1. C’est assez simple comme idée. En fonction du cahier des charges, listez les fonctionnalités. Morceler l’ensemble de ces objectifs fonctionnels pour en extraire les users stories. Effectuez l’évaluation avec une équipe transverse du coût d’une user storie. Avec la matrice ainsi générée vous pouvez piloter votre projet de manière simple. Vous transformer le poids d’une storie en jour homme ou tout autre unité que vous utilisez.
Vous vous engager à livrer à la fin de chaque sprint un produit fonctionnel2. Vous explicitez que le client doit en contrepartie s’engager à faire un retour d’expérience sur le produit à la même fréquence.
Les craintes du client
La principale crainte du client devient alors la sur-évaluation d’une storie. Les échanges et la collaboration client fournisseur prennent tout leur sens. Si ce point est très bloquant vous pouvez envisager un planning poker chez le client.
Essayer le contrat 50/50. Vous palier ainsi aux craintes liées au retard éventuel d’un projet et aux craintes de la sur-évaluation du volume utile pour réaliser le produit. En fonction du projet vous pouvez découper le paiement du projet en X fois. Ce qui correspond à un paiement toute les Y itérations3.
Pour rassurer un client qui débute dans l’agilité vous pouvez rajouter ces points là :
- La possibilité pour un client d’arrêter les frais après n’importe Y* itérations et récupérer ce qui a déjà été réalisé.
- A la fin de chaque sprint vous envoyez les indicateurs du suivit du projet (burdown chart, taux de couverture du code).
- A la fin de chaque sprint chaque partie analyse la vitesse d’exécution du projet et discute sur les améliorations à apporter.
Les mentalités ne changeront pas, si nous ne changeons pas !
- unité d’œuvre, poids d’une User Storie ça n’a pas d’importance. L’objectif est bien de rattacher une fonctionnalité à une unité pour rendre le pilotage plus facile.
- Oncle Bob estime que c’est la principale raison d’un echec lors de l’utilisation de l’agilité: ne pas produire de manière continue, un logiciel qui fonctionne!
- Y = Durée du projet / ( X * Durée Itération)
L’agilité en solitaire c’est difficile – le retour
Dans ce billet, je vais vous donner ma recette pour réussir un projet en solitaire. Il complète un précédent billet sur le même sujet, où je décrivais les problèmes que j’ai rencontrés. Je rappelle le contexte de ma situation: je travaille dans une SSII Bordelaise. J’ai effectué plusieurs missions en solitaire. Je vais essayer de lister l’ensemble des points qui me paraissent important pour réussir :
Participez activement à l’avant vente
notre métier consiste trop souvent à réaliser un produit, vendu par un commercial sans expertise technique, pour un client qui ne connait pas notre métier
Votre entreprise a un réel intérêt à vous faire participer à l’avant vente. La réponse à appel d’offre est plus technique, plus pertinente, plus proche du désir du client. Vous pouvez directement ouvrir les hostilités avec votre chef en précisant que dans le temps indiqué et en consommant de l’extasie, vous ne ferez que 50% du projet. Qui mieux que vous, êtes plus à même de juger du temps que vous prendra la réalisation du projet ?
Réalisez vous même vos users stories
A partir du cahier des charges du client, découper votre travail en users stories. Prenez un moment en début de projet pour classer vos fonctionnalités par ordre d’importance pour le client (Jouer le rôle de product owner). Réitérer l’expérience quelque temps après le début du projet, autant de fois que nécessaire.
Alertez rapidement
Essayer d’estimer vous même la durée du projet. Utilisez vos users stories pour réaliser un burndown chart (représentation graphique du temps de travail qu’il reste à faire). Puis alertez votre responsable. Le meilleur moment pour le faire ? Après 25% du temps du projet, vous avez une meilleure vision du projet : votre burdown chart est pertinent. Et vous avez assez de matière pour justifier vos inquiétudes.
Développez avec les tests
Je me suis longuement demandé si ça valait le coup ! Pourquoi ne pas faire des tests d’intégration directement ? Puis après j’ai arrêté de boire. Le développement piloté par les tests est la démarche qui me permet de réaliser moins de documentation technique, de réaliser un produit de meilleur qualité, plus proche du réel besoin du client. Elle me permet de dormir la nuit, de répondre à des questions du client par des affirmations.
En solo vous n’avez pas le droit à l’erreur, la pression est plus forte.
si vous n’êtes pas sûr qu’un seul mousqueton suffise, rajoutez en un!
N’abandonnez jamais vos tests
Il est très facile de tomber du côté obscurs de la force : n’abandonner jamais les tests ! Durant votre projet vous serrez peut être amené à changer et refaire des tests parce qu’une fonctionnalité a changé.
Feedback du client, soyez malin !
Le retour d’expérience (feedback) du client est très important. Vous êtes seul, votre projet a potentiellement plus de problèmes. Il faut donc anticiper la phase d’intégration finale. Elle sera douloureuse. Essayer d’obtenir le plus de retours de votre client, en lui faisant comprendre que le logiciel comportera moins de fonctionnalités. C’est un sujet délicat, et la meilleure solution est d’en parler à son responsable hiérarchique avant d’en parler au client. Votre commercial peut aussi à ce moment vous aider à faire avaler la pilule. Mettez en avant la qualité du logiciel et son acuité fasse à son utilisation réelle.
Si le feedback est difficile, vous êtes dans la merde ! Obtenez au moins une réunion en début de projet. A ce moment, proposez le logiciel en version pré-beta avec une interface graphique. Vous obtiendrez forcément un retour du client, l’interface ne plaisant pas complètement. Profitez en à ce moment pour poser quelques questions pertinentes sur le produit et ses fonctionnalités (savoir si le bouton de validation doit être rouge ou bleu, on s’en tape le haricot). Attention à ce moment, faîtes preuve de diplomatie.
relecture: merci @chalou33
Coder en français ou coder en anglais ?
Gros débat même au sein des développeurs de mon entreprise, faut-il coder en anglais ou en français? Je ne sais pas si la question a de sens dans la mesure ou le contexte définit souvent la langue du code. Mais si j’ai le choix, je pense que le code doit être en anglais pour les raisons suivantes:
• les propriétés du langage sont difficiles à traduire,
Les GET SET en java par exemple, entraine du franglais ou un code à rallonge.
• j’envisage de faire de l’offshore ou d’agrandir mon équipe,
Votre futur sous traitant ou votre prochaine recrue sera peut être étrangère. Reprendre une partie
de votre code sans le comprendre serait une catastrophe, une perte d’argent et de temps énorme.
• j’évite le franglais,
setCarColor est mieux que setCouleurVoiture non ? Quand il s’agit d’un mot difficile à traduire, ou bien impossible à traduire, alors je l’utilise tel quel. Exemple un objet DICOM propre au médical. DICOM n’a pas de traduction. Dans ce cas j’utilise l’agrégation de termes qui n’apparait pas comme du franglais et qui garde tout son sens (dicomObject, dicomFile, dicomName, etc…).
• les accents rajoutent des problèmes,
Il faut faire attention à l’encodage et certains langages n’acceptent pas les accents. validerMessageSupprime (au lieu de validerMessageSupprimé) devient moins clair que confirmDeletedMessage.
• le client veut voir le code, et en anglais il ne comprendra rien,
C’est la seule raison qui selon moi peut justifier l’utilisation du français dans le code. Mais j’aurai tendance à dire: chacun son métier. Toute la difficulté est de comprendre le langage du client (en termes métiers) et de le retranscrire dans notre langage. Il est très rare que le client mettent le nez dans le code. Et pour les quelques fois ou le client voudra une explication sur le code, un développeur sera en mesure de le faire.
• je ne réinvente pas la roue,
Beaucoup de fonctions, d’api, de librairies existent en anglais, sont écrites et documentées en anglais. Je me vois mal lorsque je récupère un morceau de code, le traduire en français. Je le réutilise tel quel.
• je demande de l’aide, j’utilise stackoverflow,
Et oui cela parait bête mais j’utilise de moins en moins les forums d’aide en français. Copier coller sur un forum anglais du code en français avec des questions en anglais entraine moins de réponses
que si je fais l’effort de traduire. Essayez vous verrez. Depuis que je sais ça, et parce que j’utilise souvent ces médias, je m’efforce de réaliser un code propre en anglais qui ne nécessite pas de refactoring quand je veux demander de l’aide.
• quand ma fonctionnalité métier devient une valeur ajoutée,
C’est assez facile de comprendre qu’un code en français est plus facilement compréhensible par le client qu’un code en anglais. Mais des fois, un morceau de code est réutilisé dans tous nos programmes. C’est intéressant de capitaliser ce code, pour en extraire une API et de la réutiliser ensuite. Et si on réfléchit « business », si on veut vendre cette API par la suite, en français ça risque d’être difficile. Et même si on fait de l’open source, la communauté anglophone est bien plus importante que la communauté française. J’obtiendrai plus de contributions si je code en anglais.
Je pense qu’il y a d’autres raisons, qui se valent plus ou moins. Mais ce sont pour moi les plus importantes.
En même temps que j’écris ce billet, Evernote m’indique « Synchronisation Terminée : une note téléversée ». C’est un signe » codons en anglais.
Edit: Pour avoir un autre chant son de cloche, je vous invite à lire ce post de Fabien Bezagu
déroulement d’un projet logiciel
Sémaphore du flux de productivité
Rachel Davies et Liz Sedley dans le livre « Coaching Agile » parlent d’améliorer le feedback sur l’état du build.
If the team makes the move to using a Continuous Integration server to run the build and let them know the test results, they won’t need a build token anymore
Elle précise que si l’équipe se met à utiliser un serveur d’intégration continue pour exécuter le build et l’informer du résultat des tests, elle n’aura alors plus besoin d’un objet de build (ou jeton de build). Je ne suis pas d’accord avec cette idée. Je vois deux intérêts à ce que l’équipe continue à utiliser un sémaphore d’intégration même si elle utilise un serveur d’intégration continue.
Un sémaphore est un merveilleux indicateur du flux de productivité. Dans une pratique Lean un sémaphore qui ne circule pas signale un flux discontinu. Le premier intérêt est donc de permettre à une équipe SCRUM de s’arrêter et d’aider l’acteur en difficulté à venir « pousser son code ». La plus grosse difficulté pour l’équipe est de se rendre compte, d’elle-même, que le jeton n’a pas beaucoup circulé. En parler lors du stand-up meeting peut être une bonne solution.
L’autre intérêt de continuer à utiliser un sémaphore d’intégration est que son utilisation, outre le fait qu’elle fait ressortir un problème de flux, montre que l’équipe commence à s’auto-organiser. Dans un processus difficile d’équipe auto-organisée, un sémaphore bloqué pendant une journée est très révélateur d’une mauvaise communication.
Pourquoi à un moment donné, un binôme se lève et essaye d’aider un autre binôme ? Est ce que la fonctionnalité attendue est bloquante ? Ce transfert de ressource n’est pas naturel. L’encourager par des indicateurs comme le sémaphore de build est une excellente idée.
Référence: L’Intégration continue est un système multitache – Blog d’Emmanuel CHENU.
Le Coding Dojo
Qu’est ce qu’un coding dojo ?
Un coding dojo est une session amusante et intense pendant laquelle des développeurs améliorent leurs compétences en programmation. Ils cherchent collectivement à résoudre un problème informatique. Il existe différentes formes de coding dojo, et de plus en plus, cette pratique voit le jour dans les entreprises. Pour ma part je pratique le coding dojo au sein des locaux de l’entreprise Yaal. Jeune entreprise innovante agile du tissu bordelais. Généralement nous sommes entre 5 et 10 et nous développons une application ou un jeu.
Le but d’un coding dojo ?
Le but d’un coding dojo est de permettre à l’auditoire d’apprendre de manière collective différentes pratiques du développement logiciel. Pour vulgariser, je dirais qu’un coding dojo est un savant mélange entre une formation et un tutoriel. Ajoutez à cela que la pratique est bon enfant, et vous obtenez un cocktail détonnant.
J’ai jamais autant appris en 5 mois de coding dojo qu’en 3 ans d’études en école d’ingénieur.
Qu’est ce que cela m’a apporté?
Actuellement nous nous appuyons sur le TDD (développement piloté par les tests) et la programmation en binômes. Durant toutes les sessions auxquelles j’ai assisté, j’ai toujours appris quelque chose et c’est dans mon travail que j’utilise cet apprentissage. Autre élément important, nous nous permettons d’exprimer nos craintes ou nos désaccords. Démarche moins aisée en entreprise (il est difficile de venir critiquer une façon de faire surtout si ça dérange). Plus les coding dojo avancent, plus nous prenons des risques. Nous avons de moins en moins peur de dire :
Je ne sais pas
Humilité, courage et intelligence sont trois qualités que nous développons.
L’agilité en solitaire, c’est difficile!
Le constat est malheureusement pessimiste, l’agilité en solitaire, c’est difficile!
Frédéric Doillon va même plus loin et affirme:
A tous les développeurs du monde, si un chef de projet tient à vous mettre sur un projet où vous serez seul, fuyez ! À toutes jambes, sans même vous retourner. N’acceptez jamais ce genre de mission. Sinon, vous signez votre arrêt de mort !
Je ne suis pas tout à fait d’accord. Il est facile de comprendre que scrum est à proscrire dans un projet en solitaire. Scrum est le terme anglais signifiant mêlée, notamment au rugby. Faire une mêlée tout seul ça n’a pas de sens. D’ailleur l’expression « équipe scrum » est plus souvent utilisée que le terme scrum lui même. Et jusqu’à preuve du contraire, une équipe ça se compose au minimum de deux individus.
Une équipe scrum est composé d’au moins trois personnes: un ScrumMaster, un product owner et un développeur. Appliquer l’agilité en solitaire sous entend que je représente ces trois personnes en même temps. A part si je suis atteins d’une double schizophrénie (que les médecins ne m’en veuillent pas, je fais l’amalgame entre double personnalité & schizophrénie) il est difficile pour moi de jouer tous ces rôles en même temps.
Pour ma part, je n’ai pas pu refuser ce genre de mission, et j’ai du faire avec, m’adapter ! Ma première idée à la suite de l’article de Frédéric Doillon était de faire jouer le rôle de Scrum Master par mon chargé de projet, et le product owner par le client. Je devais impliquer au mieux le client dans le processus de développement. J’ai vite compris que ce n’est pas aussi facile que ça ! Souvent, et ce fut mon cas, le client ne veut qu’un intermédiaire (chef de projet). Il pense gagner du temps. Je me retrouve donc avec un seul acteur pour construire mon équipe agile: le chargé de projet. Moi j’ai de la chance, mes idées farfelues d’appliquer l’agilité sont passées comme une lettre à la poste. Mon chef de projet a accepté de jouer le rôle de product owner. Mais ce n’est pas vrai pour tout le monde.
J’ai réalisé moi même mon backlog produit et je me suis tourné vers mon product owner pour prioriser mes taches. Je n’ai pas utilisé de planning poker, mais c’est une idée que j’ai envisagée.
Couplé à cette méthode, j’utilise aussi d’autres pratiques tirées d’XP. Par exemple je travaille en sprint d’une semaine (5 jours). La durée de mon projet étant de 50 jours. J’ai toujours un logiciel qui fonctionne (intégration continue). J’utilise le développement piloté par les tests. Et comme le dit très bien Fabien Bezagu, je n’ai pas à demander pour utiliser TDD.
Néanmoins, c’est la seule méthode que j’applique vraiment en solo, car je ne peux pas binômer, je n’utilise pas non plus d’autres outils comme kanban ou les burndown chart et je ne fais pas de rétrospective pour moi tout seul. Par contre je promets d’essayer d’autres idées d’XP avant la fin du projet.
Le double planning poker!
J’ai longtemps mal compris le rôle du planning poker, et aujourd’hui je vous propose une vision un peu novatrice de son utilisation : le double planning poker !
L’intérêt du planning poker est normalement de trouver la vélocité de chaque user story du backlog produit. L’équipe SCRUM au complet se réunit et passe en revue l’ensemble des user stories pour être sur que tout le monde est d’accord sur la difficulté de la tache à réaliser. Généralement l’ensemble des participants possèdent un certain nombre de cartes, toutes ayant un numéro correspondant à la suite de Fibonacci (0, 1, 2, 3, 5, 8, 13, 20, 40, 100)1. Une fois la fonctionnalité expliquée, chaque participant estime l’effort nécessaire à l’équipe pour produire cette fonctionnalité. C’est un effort relatif : ce chiffre n’a pas d’unité et n’a de sens qu’en comparaison avec d’autres fonctionnalités2.
Maintenant je donne l’idée d’une deuxième utilisation possible du planning poker. Facilitons la prise de décision parfois difficile coté client et évitons le changement en excès. Le planning poker devient un outil pour prioriser les fonctionnalités du backlog produit. Equipés d’un jeu de cartes pour le planning poker, le product owner et le client se réunissent autour d’une table et reprennent l’ensemble des user story du backlog produit. Ils cherchent à définir l’ordre de priorité des fonctionnalités. C’est très utile quand le client a du mal à spécifier son besoin et/ou que les premiers sprints sont soumis à trop de changements. Si ça gène la vélocité moyenne de l’équipe de développement (changement architecturaux, changement techniques, etc..) alors il faut freiner l’élan du client. Attention je ne dis pas qu’il faut fixer le besoin ! Mais ça permet à l’équipe de développement d’avancer, et surtout au product owner d’avoir une meilleur « Vision Produit ». Je pense que l’utilisation de cette méthode est intéressante avec des clients qui ne connaissent pas bien les concepts agiles.
Pour aller plus loin :
Quel outil choisir pour un planning poker
1 La suite de Fibonacci est meilleure qu’une suite linéaire, car elle permet d’accélérer la prise de décision. En effet quand on cherche à estimer la valeur d’une fonctionnalité dans un gros projet, il est difficile d’éviter l’incertitude de l’estimation. Si vous prenez la suite linéaire suivante : 0,1,2,3,4,5,6,7,8,9,10 et que votre équipe fait ressortir une vélocité allant de 6 à 9 pour la user story une, et 5 à 8 pour la user story deux, vous serez dans l’obligation de débattre pour savoir si vous êtes dans le vrai. Avec la suite de Fibonacci votre équipe aurait défini une vélocité de 40 et donc la décision aurait été plus rapide. De plus la représentation d’une estimation est plus représentative de l’importance des fonctionnalités entre elle, avec une suite de Fibonacci.
2 Certains chefs de projet, pour des raisons purement pratiques, convertissent ses points de vélocité en jour/homme en multipliant le chiffre par un coefficient qui leur va bien. Vous l’aurez compris la vélocité n’a pas d’unité. Elle représente un effort.
La rétrospective, son principal intérêt
Dans l’application de bonnes pratiques agiles, il est recommandé de faire une rétrospective. A la suite d’un sprint dans une démarche SCRUM, l’équipe est amenée à discuter des différents problèmes qu’elle a pu rencontrer lors du développement de son application. C’est un moment important, qui oblige tout le monde à se remettre en question. Cela favorise l’amélioration continue passive.
Prenez un exemple, si vous afficher clairement votre consommation électrique dans votre salon, avec l’affichage en temps réel du montant de votre facture, votre consommation va naturellement se réduire. C’est inévitable! Avec la rétrospective c’est pareil. Vous mettez en avant les problèmes rencontrés durant le dernier sprint. Naturellement votre équipe fera en sorte que les problèmes rencontrés soit corrigés. Essayez vous verrez, c’est l’adopter!
Test Driven Development (TDD)
Dans ce tutoriel, je vous propose de comprendre le fonctionnement du TDD, appelé aussi développement piloté par les tests. J’ai essayé de le rendre le plus accessible possible. J’utilise une approche didactique, avec pas mal d’explications. Cette démarche est complétée par un deuxième tutoriel plus pratique, où je vous propose de venir essayer ce que je vous ai appris. Bonne lecture!
Qu’est-ce que le TDD ?
C’est une pratique de développement beaucoup utilisé dans la réalisation de logiciels en informatique. C’est une méthode que les développeurs utilisent pour faire ressortir une sorte de patron de conception. TDD n’a rien avoir avec le test ou le développement à proprement parlé. C’est vraiment un motif de conception (une façon de faire) qui indique comment le développeur doit coder une application. C’est pour cette raison que le TDD est difficile à maitriser et à appréhender.
Dites ce que vous voulez, avant de le faire, et ensuite assurer vous que ce que vous avez obtenu correspond bien à vos attentes. Cela permet de faire émerger des petits modèles de conception.
Un modèle de conception (appelé aussi design pattern) décrit un problème qui apparait encore et encore dans votre environnement de travail. Ensuite il explicite une solution que vous pourrez utiliser à chaque fois pour résoudre ce problème.
Comment faire du TDD ?
C’est très facile à dire, et moins facile à faire. Mais très simplement, vous réalisez un test qui échoue, un test qui définit clairement ce que vous voulez que votre code fasse. Donc je sais que je vais devoir écrire du code, donc la première chose que je dois me demander est: A quoi cela va-t-il ressembler ? Et pour mieux définir les choses on pourrait se dire: Comment je sais, que ce morceau de code que je suis en train d’écrire, fait bien ce que je veux qu’il fasse ? Vous savez que votre morceau de code fait bien ce que je veux si… et là vous listez l’ensemble des assertions possibles. Ou alors vous savez que votre objet doit être dans tel ou tel état, et l’environnement autour de cet objet doit être de tel ou tel forme. L’objectif est de tester l’ensemble de ces cas. Donc vous décrivez cela dans un test formaté pour votre code. Votre code ne compile pas parce que votre fonctionnalité n’est pas implémentée. Ensuite vous réalisez le code le plus petit possible pour que votre code compile. Le test ne passe toujours pas mais votre programme compile! Ensuite vous réalisez votre code pour que le test passe. Réalisez ce dernier avec le moins de lignes possibles, c’est important ! La dernière étape est une étape de refactoring ou l’on va chercher à améliorer son code (mise en place des commentaires, suppression des duplicatas, etc). Vous avez donc à suivre ce cheminement tout au long du développement d’une application, et vous obtiendrez ce que vous souhaitez réellement. Un test après l’autre, en rajoutant toujours plus de tests à la suite.
Si on résume, vous réaliser un test qui anticipe ce que vous voulez coder. Vous vérifiez que le test échoue (et oui votre fonctionnalité n’est pas réalisée) et vous réalisez votre code pour que votre test devienne vert. Vous améliorez votre test une fois cette étape finie, pour le rendre plus élégant.
Pourquoi le TDD ?
Là où c’est génial c’est que votre logiciel fait exactement ce que vous voulez qu’il fasse. L’architecture est volontairement plus petite, les objets ne font que ce qu’ils doivent faire. C’est l’essence même des designs patterns simples. Votre code est précis, élégant et on évite souvent des effets pervers comme la régression de code, et des effets transverses comme les problèmes de maintenance, les effets de surcharge, la dette de code. J’aime bien cette métaphore qui dit que votre code n’est pas plaqué-or mais bien en or massif.
L’architecture logicielle dans tout ça ?
Beaucoup pense qu’un logiciel développé avec TDD n’a pas besoin d’architecture. Ceci est faux et complètement idiot. L’intérêt du TDD vient du fait que l’on a besoin d’une architecture, complexe ou non, où la modularité est le maître mot. Les classes doivent comporter le moins d’interaction avec les autres. Et le TDD permet de faire évoluer son code en sûreté. Beaucoup de personnes s’entendent pour dire que l’architecture apparaît d’elle-même, il faut juste poser des bases simples et évolutives.
Le Test Driven Development (TDD) est le principal outil de l’artisan logiciel !
L’agile tour 2010 revient !
Pour la troisième année consécutive l’Agile Tour revient en France durant tout le mois d’Octobre. Le principal objectif de ses manifestations est de promouvoir massivement l’Agilité en France, de discuter sur différents concepts de développement logiciel et de fédérer les acteurs de l’Agilité autour d’une même synergie.
L’agilité qu’est ce que c’est?
Je reviendrai plus en détails sur ses concepts d’Agilité dans d’autres articles. Mais pour vulgariser l’Agilité représente une méthode de développement logiciel. Les méthodes Agile répondent à des problématiques concernant l’amélioration des processus de développement d’un logiciel informatique.
Quel est le public concerné par ses manifestations?
En premier lieu, les développeurs et les chefs de projet en développement logiciel sont les principales cibles de ces manifestations. C’est en effet eux qui vont être amenés à utiliser ses méthodes. Mais les chefs d’entreprises, les équipes Marketing, ou les responsables des ressources humaines sont aussi concernés. De multiples ateliers ou conférences sont présentés et il y en a pour tout les gouts.
Je mettrai en avant différentes conférences ou ateliers à ne pas manquer s’ils sont programmés dans votre ville.
Compléments d’informations, inscriptions:
Pour tout complément d’informations, retour d’expériences, inscriptions un seul site:
Je précise que les manifestations sont gratuites et que 11 dates sont prévues en France.
