TDD, BDD, DIRTI, quelle méthode de programmation adopter?

Ces dernières années, de nouvelles méthodologies révolutionnent notre manière de penser l'architecture de nos programmes (java, php etc).

Pour en citer quelque uns, nous avons vu apparaître:
- le développement piloté par les tests (Test Driven Development), introduit par les tests unitaires (phpUnit, Atoum...).
- le développement piloté par le comportement (Behavior Driven Development) avec entre autres Behat.

Sans ré-expliquer ces concepts, ce que d'autres ont excellement déja fait, le premier nous incite à développer nos tests avant nos méthodes, ce qui implique une excellente compréhension de l'architecture finale de l'application, quand le second nous permet de générer du code à travers les spécifications (comportement) de l'application, ce qui a pour avantage de faciliter le dialogue entre tous les intervenants du projet (les stakeholders).

Toutes ces méthodes sont aujourd'hui reconnues comme de bonnes pratiques de développement, mais, elles ont pour inconvénient de se concentrer plus sur la valeur du code (code value), que sur la valeur métier (business value).
Traduction, avec ces méthodes, mon code sera propre, standard, mais il ne fait pas encore ce pourquoi je le crée.

Vous l'aurez compris, dans certaines situations, notamment lors de short deadlines, ce qui arrive ne nous mentons pas, très souvent, ces méthodes peuvent devenir contre productives, ou, il peut simplement arriver que l'architecture de notre application soit si complexe que nous ne savons pas quelles fonctionnalités, méthodes exactes devront être utilisées dans notre application.

Pour pâlier à ce problème, je vais vous présenter la méthode DIRTI, (introduite par Anthony Ferrara) prononcer comme dirty.

D pour develop.
I pour isolate.
R pour refactor.
T pour test.
I pour integrate.

La méthode dirti, signifie littéralement s'entraîner comme un cowboy pour tirer comme un sniper... on code d'abord, on pose les questions ensuite.

Dans la pratique cela se traduit ainsi:
1. On code ce que l'on peut coder du moment qu'on a quelque chose de fonctionnel rapidement (la valeur métier).
2. On relit notre code, pour isoler les points d'abstractions.
3. On refactorise notre code en séparant les différentes couches isolées précédemment.
4. On refait ce process autant que nécessaire jusqu'à compréhension parfaite de l'architecture de l'application.
5. Une fois, les couches d'abstraction isolées, on écrit nos tests unitaires.
6. Une fois les abstractions testées, on les intègre dans notre application.

Vous l'aurez donc bien compris, la méthode dirti ne remplace ni les tdd, ni les bdd, mais vient en complément dans certains cas de figure.
Elle a pour avantage de produire du code fonctionnel d'abord, pour mieux affiner sa vision de l'application, avant de correctement refactoriser et normaliser son code.

Edouard kombo.