Cette problématique n'est pas triviale. En effet, l'intéret d'une pratique comme le TDD est que le code est construit pour être testé ce qui permet de faire évoluer en toute sécurité le design du système.
Que trouve-t-on quand on doit faire évoluer l'héritage (legacy) de plusieurs années développement en SSII :
- de grosses classes / fichiers ;
- de grosses fonctions ;
- un couplage fort entre les composants, comme du code métier appelant directement une base de données (merci le Pro*C !).
Les techniques proposées dans le livre visent à réduire le couplage pour permettre d'écrire une couverture suffisantede TU.
Le point fort d'après moi est d'adopter un point de vue très pragmatique : bien souvent, on intervient sur du vieux code pour faire une corerction ou une simple évolution. Le budget est rarement propice à une refonte globale du design du système. M. Feathers ne propose pas de changer du code critiquable en code parfait mais bien de se donner les moyen d'intervenir efficacement de manière sécurisée. Ainsi, plusieurs solutions proposées présentent des entorses au principe d'encapsulation*.
Pour moi, ce livre est un must read pour tout développeur professionnel tant les situations décrites font partie de notre auotidien. On le vaincra, ce mauvais code !
* Je conseillerais aux puristes de l'encapsulation d'essayer Python, ça les détendra (ou le contraire).
