par kawanet

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?