Je viens de prendre connaissance d’un superbe billet sur le blogue de Coding Horror qui s’intitule “Paying Down Your Technical Debt“. La dette technique (Technical Debt) est un concept qui a été lancé par Ward Cunningham. Lorsqu’on développe ou maintient une application sur une longue période de temps, ça arrive souvent qu’on prenne des chemins discutables pour arriver à nos fins. Cela se justifie par des échéances trop serrées, une ignorance de la technologie ou un manque de familiarisation avec le patrimoine bâti (ce qui a été fait avant nous).

Lorsqu’on décide de ne pas revisiter ces erreurs et de constamment les éviter, c’est qu’on produit un déficit qu’on rajoutera à la dette technique. Éventuellement, l’application deviendra un gros spaghetti incompréhensible composé d’innombrables passes passes de cowboy. On vient alors à la conclusion qu’elle doit être refaite et mise au rancart. On fait faillite en sorte!

Le billet nous conseille de prendre une pause du développement de nouvelles fonctionnalités et dédier un peu de temps à réécrire des portions de l’application (refactorisation). Il existe des techniques pour faire de la refactorisation sans déstabiliser l’application.

Aussi la refactorisation devrait être encouragée pendant le projet et devrait être une priorité pour une application en maintenance. L’amélioration d’une application qui compte déjà ses adeptes fera du programmeur une mégavedette sans trop d’efforts de sa part. C’est une parfaite application de la loi de Pareto (loi du 80/20).

Avez-vous des exemples où vous avez réduit ou accumulé une dette dans un projet?

Billet précédent: Pourquoi un seul mot de passe pour Metallica?

Billet suivant: J’assiste à Webcom mai 2009

Mots clés: déficit technique, maintenance, refactorisation, spaghetti

Ce billet a été publié le 4 mai 2009 à 22:14. Il est classé sous Agile, Développement informatique. Vous pouvez suivre les commentaires à ce billet à l'aide de son fils fils RSS. Les commentaires sont présentement désactivés