« DetteTechnique » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 23 : | Ligne 23 : | ||
<br/> | <br/> | ||
Dans ces conditions, la meilleure solution est généralement de faire ce que nous faisons habituellement avec les dettes financières, à savoir rembourser le principal progressivement. Pour la première fonctionnalité, je vais passer quelques jours de plus pour enlever une partie du code mal conçu. Cela peut être suffisant pour réduire le taux d'intérêt sur les futures améliorations à un seul jour. Cela prendra encore plus de temps, mais en supprimant le code mal conçu, je réduis le coût des futures modifications de ce code. Le plus gros avantage d'une amélioration progressive comme celle-ci est que cela signifie naturellement que nous passons plus de temps à retirer le code mal conçu dans les parties que nous modifions fréquemment, qui sont exactement les parties du code base où nous avons le plus besoin que le code mal conçu soit supprimé.<br/> | Dans ces conditions, la meilleure solution est généralement de faire ce que nous faisons habituellement avec les dettes financières, à savoir rembourser le principal progressivement. Pour la première fonctionnalité, je vais passer quelques jours de plus pour enlever une partie du code mal conçu. Cela peut être suffisant pour réduire le taux d'intérêt sur les futures améliorations à un seul jour. Cela prendra encore plus de temps, mais en supprimant le code mal conçu, je réduis le coût des futures modifications de ce code. Le plus gros avantage d'une amélioration progressive comme celle-ci est que cela signifie naturellement que nous passons plus de temps à retirer le code mal conçu dans les parties que nous modifions fréquemment, qui sont exactement les parties du code base où nous avons le plus besoin que le code mal conçu soit supprimé.<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/> | |||
<br/> | <br/> | ||
==Notes== | ==Notes== | ||
<references /> | <references /> | ||
