CDD: Une nouvelle méthode pour travailler

Cet article a été précédemment publié a cette adresse http://dev.af83.io/2011/04/01/cdd-une-nouvelle-mthode-pour-travailler.html.

Les méthodes agiles font fureur dans toutes les compagnies. Le but est toujours le même, délivrer de la valeur rapidement au client et avoir le meileur produit techniquement.

Le TDD est plébicité par de nombreux développeurs. Écrire des tests avant le code permet de se focaliser sur le code minimal a écrire pour réussir. Le refactoring est simplifié et le code concis. Le BDD est une alternative intéressante qui décrit le comportement.

Le RDD, méthode plus récente se met encore plus à la place du client/dévelopeur. Le but est déliver un README riche et presque exhaustif.

La documentation avant le test, lui même avant le code a été introduit par Tom Preston-Werner, dans un article Readme Driven Development.

af83 a toujours poussé ses développeurs a utiliser ces pratiques toujours plus innovantes. Aujourd’hui, af83 dans sa volonté de dresser un panorama complet du développement, nous avons découvert le CDD.

Le CDD est l’abbréviation de Clone Driven Development.

Quand utiliser le CDD ?

CDD n’est pas une pratique pertinente pour tous les projets. Elle devient applicable si :

  • vous avez du code non testé
  • pas d’architecture
  • un framework moisi
  • des dévelopeurs qui ne comprennent rien

L’ensemble de ces conditions d’acceptions crée un code horrible où la moindre modification entraîne des effets de bords parfois incroyables et hilarantes.

Si vous devez faire évoluez votre produit, la situation peut devenir délicate. Votre client/actionnaire n’est pas content des régressions incessantes.

Vous pouvez le rassurer en rajoutant deux personnes supplémentaire dans le projet pour rattraper le retard. Au pire, une présentation powerpoint suffira pour calmer le jeu.

CDD permet de décupler la vélocité lors de l’écriture de documentation, test, code et commentaires. Le CDD est la seule méthodologie connue permettant de multiplier le nombre de tests sur une application sans modifier le taux de couverture.

CDD, la solution

Si de grosse évolutions sont prévues, CDD vous invite à cloner le code, ainsi l’ancien code fonctionnera toujours aussi mal !

Le clone est différent de la duplication seulement par la différence de connotation négative dans l’esprit du client/actionnaire.

SI le CDD est globalement une bonne pratique il faut savoir qu’un développeur qui n’a a pas été formé peut la devoyer même sans le savoir, ainsi l’utlisation d’un SCM (voir note 2) moderne risque d’en réduire à néant les bénéfices.

Si le développeur comprends par exemple le verbe “cloner” comme l’utilisation de la commande “clone” de GIT, la duplication peut être uniquement apparente et de surface. Un vrai clone CDD doit forcement annihiler toute possiblité de merge. Ainsi il est considéré bon pour chaque fichier ou repertoire “cloné” d’avoir au moins une différence en terme de whitespace ou d’indentation (le mix espace/tabulation est judicieux).

Voici un exemple de script qui pourra vous aider à automatiser cette tâche (même si l’automatisation est considérée comme un anti-pattern dans le cadre du CDD):

find . -type f -exec perl -pi2 -anle'$_=join"", reverse @F' "{}" \;

Pour aller plus loin

CDD est d’abord une méthodologie d’écriture de code, mais elle est aussi applicable à la gestion de projet.

Si malgré l’application scrupuleuse de la pratique vous constatez que l’unique test écrit et dupliqué de multiples fois passe toujours, il faut probablement appliquer le CDD aux autres instances du projet. Il vous faut ajouter une ou deux personnes aux instances de gestion de projet et quatre à dix-huit aux instances de décision.

Il est très important à ce moment de s’assurer que les responsabilités ne soient pas determinées avec précision, et que l’intégralité des clones ajoutés sont capable de donner des ordres par téléphone directement aux développeurs.

Note : Il ne faut pas confondre le CDD, d’une autre pratique toute aussi universelle et efficace, le ZDD (Zombie Driven Development) qui consiste à augmenter la productivité et la qualité du projet par l’allongement de la durée de travail des développeurs. Bien que souvent le ZDD est une pratique complémentaire aux effets salutaires.

Note 2 : le CDD se comporte bien avec l’outil de révision de code cpold.

Have a comment? Contact me by email.