« DetteTechnique » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 25 : | Ligne 25 : | ||
<br/> | <br/> | ||
Le fait de penser que l'on paie des intérêts plutôt que le principal peut aider à décider quel est le code mal conçu à traiter. Si j'ai une partie du code base qui est déplorable, un véritable cauchemar à modifier, ce n'est pas un problème si je n'ai pas à la modifier. Je ne déclenche un paiement d'intérêts que lorsque je dois travailler avec cette partie du logiciel (c'est un endroit où la métaphore s'effondre, puisque les paiements d'intérêts financiers sont déclenchés par le temps qui passe). On peut donc laisser les parties du code qui sont mal conçues mais stables. En revanche, les parties du code souvent modifiées nécessitent une tolérance zéro vis-à-vis du code mal conçu, car les paiements d'intérêts sont extrêmement élevés. Ceci est particulièrement important car le code mal conçu s'accumule lorsque les développeurs apportent des modifications sans se soucier de la qualité interne ; plus les modifications sont nombreuses, plus le risque de mal concevoir le code est grand.<br/> | Le fait de penser que l'on paie des intérêts plutôt que le principal peut aider à décider quel est le code mal conçu à traiter. Si j'ai une partie du code base qui est déplorable, un véritable cauchemar à modifier, ce n'est pas un problème si je n'ai pas à la modifier. Je ne déclenche un paiement d'intérêts que lorsque je dois travailler avec cette partie du logiciel (c'est un endroit où la métaphore s'effondre, puisque les paiements d'intérêts financiers sont déclenchés par le temps qui passe). On peut donc laisser les parties du code qui sont mal conçues mais stables. En revanche, les parties du code souvent modifiées nécessitent une tolérance zéro vis-à-vis du code mal conçu, car les paiements d'intérêts sont extrêmement élevés. Ceci est particulièrement important car le code mal conçu s'accumule lorsque les développeurs apportent des modifications sans se soucier de la qualité interne ; plus les modifications sont nombreuses, plus le risque de mal concevoir le code est grand.<br/> | ||
<br/> | |||
La métaphore de la dette est parfois utilisée pour justifier le fait de ne pas tenir compte de la qualité interne. L'argument est qu'il faut du temps et des efforts pour empêcher l'accumulation de la dette. Si de nouvelles fonctionnalités sont nécessaires de toute urgence, il est peut-être préférable d'assumer la dette, en acceptant que cette dette doive être gérée ultérieurement.<br/> | |||
<br/> | <br/> | ||
==Notes== | ==Notes== | ||
<references /> | <references /> | ||
