Ceci dit le TDD est « indépendant » des méthodes Agile. Rien n’empêche de faire du TDD avec (Rational) Unified Process. (Même si le TDD viens de l’xP qui est Agile… mais bon :D) C’est une « méthode de programmation » qui s’intègre a n’importe quel autre type de méthodes, l’ayant moi même implémenté dans RUP avec succès. Et idem pour les langages, ai vu il n’y a pas longtemps un framwork TDD pour du C pure… oui il y a des malades. (Toutes personne ayant écrit une fois dans sa vie des unit test en C sait de quoi je parle)

Malheureusement les gens confondent souvent les différentes strates de méthodologies et TDD est considéré à tort comme une méthode « globale ». Beaucoup de petits dev(seul ou groupe de + de 5) ont tendance a adopter TDD qui est vendu comme une sorte de solution all in one alors qu’il n’y a rien sur les requirements, l’analyse et le design (pour reprendre la structure RUP) dans TDD. TDD ne touche que les couches Implémentation et Test. Et ne prend pas a compte l’évolution dans le temps non plus (Inception, Elaboration, Construction et Transition pour reprendre en RUP). Et même les méthodes XP ou Scrum qui sont plus globales, n’ont pas grand chose non plus sur ces sujets la par rapport à des methodo’s concurrentes.

C’est malheureusement le problème avec les méthodes dites « Agile », beaucoup de gens les « connaissent » et en font n’importe quoi. (Pour cela que j’aime ce vieux mammouth de RUP, au moins ceux qui parlent savent en générale ce qu’ils font)

Pour fini, merci, car cet article présent bien TDD tel qu’il est et non tel que certains voudraient le voir comme dans beaucoup d’articles, ça change

Concernant le deuxième point, je n’ai pas lu ce livre mais il m’a l’air bien. Est ce que ça te dérange si je le mets dans l’article ?

Absolument aucun problème, ce livre est génial et en faire sa publicité est presque un geste de bonté envers le monde du développement.

Par contre ce n’est pas un guide miracle, il faut vouloir jouer le jeux et cela prend du temps. Il m’a fallu une bonne années pour que 50% des concepts décrits deviennent des automatismes. C’est quasi un livre sur la philosophie du code. C’est un ouvrage comme cela qui prouve que le développement a tout de l’art. Mais du lecteur averti à celui qui zigzague, tout le monde en tirera quelque chose.

Voici la description de l’éditeur (qui pour l’avoir lu fait tout sauf jeter de la poudre aux yeux)

Si un code sale peut fonctionner, il peut également remettre en question la pérennité d’une entreprise de développement de logiciels. Chaque année, du temps et des ressources sont gaspillés à cause d’un code mal écrit. Cet ouvrage vous apprendra les meilleures pratiques de nettoyage du code « à la volée » et les valeurs d’un artisan du logiciel qui feront de vous un meilleur programmeur. La première partie de l’ouvrage décrit les principes, les motifs et les pratiques employés dans l’écriture d’un code propre. La deuxième partie est constituée de plusieurs études de cas de complexité croissante. Chaque étude de cas est un exercice de nettoyage : une base de code qui présente certains problèmes doit être convertie en une version saine et efficace. La troisième partie sera votre récompense. Son unique chapitre contient une liste d’heuristiques et d’intuitions collectées pendant la création des études de cas. Le résultat est une base de connaissances qui décrit notre manière de penser pendant que nous écrivons, lisons et nettoyons du code.Après avoir lu ce livre, vous saurez :

faire la différence entre bon et mauvais code ; écrire du code propre et transformer le mauvais code en bon code ; choisir des noms, des fonctions, des objets et des classes appropriés ; mettre en forme le code pour une lisibilité maximale ; implémenter le traitement des erreurs sans perturber la logique du code ; mener des tests unitaires et pratiquer le développement piloté par les tests. Cet ouvrage est indispensable à tout développeur, ingénieur logiciel, chef de projet, responsable d’équipe ou analyste des systèmes dont l’objectif est de produire un meilleur code.

En effet, je n’ai pas du tout abordé la partie créative du métier. Il est vrai qu’un autre aspect essentiel du métier est la curiosité. Il faut être un enfant : Attendre les nouvelles versions des produits comme on attendrait un nouveau jouet et essayer de tout comprendre en mitraillant à coup de « Pourquoi ? Pourquoi ? Pourquoi ? ». Peut-être que j’écrirai une suite à l’article la prochaine fois que je devrais repasser derrière un collègue bon techniquement mais avec un code immonde :p

Concernant le deuxième point, je n’ai pas lu ce livre mais il m’a l’air bien. Est ce que ça te dérange si je le mets dans l’article ?

En tout cas, merci pour tes conseils et tes idées !

Le premier, tu ne parles pas de la partie créative du développeur. Technique/Logique/Communication mais aussi Inventivité/Créativité sont nécessaire je pense. Un bon dev doit aussi être passioné et curieux je pense. Toujours se demander « mais comment ça marche » est pour moi le meilleur moyen d’apprendre une techno en profondeur. (Ce que beaucoups de dev’s ajourd’hui oublient, se contentant de bouffer les framework tous chaud qu’on leur met dans la bouche).
Donc je rajouterais Inventivité/Créativité/Curiosité/Passion
Pour un futur article : « Qu’est ce qu’un bon développeur ? La suite » ?

Enfin le second concerne la partie « art du code ». (Commentaires, noms de variables et cie).
Je recommande au lecteur de cet article le livre « Coder proprement » chez Pearson dans la collection « Référence » par Robert C. Martin.

Sinon, excellent article