Calculer les coûts d'un mauvais code

Je cherche des arguments pour convaincre la direction d'investir des efforts dans la refactorisation.

Nous enregistrons le travail à l'aide de Jira et relions chaque svn-commit à un appel jira.

Mon idée est de faire ce qui suit:

• repérer manuellement une zone de code qui est extrêmement mal implémentée, mais souvent utilisée: à la fois de User-POV et de Developer-POV (corrections de bugs)
• obtenir les svn-commits qui contiennent les problèmes JIRA
• filtrer les problèmes selon certains critères (type de problème, version, prio. etc ...)
• calculer le temps / effort consacré à ces bogues
• estimer les efforts et les risques de refactoring
• présenter les chiffres et demander des efforts pour le corriger.

Que pensez-vous de cela? Une telle mesure serait-elle utile et / ou convaincante? Quels sont les avantages et les inconvénients?

J'ai constaté que si vous pouvez fournir des chiffres valides, les gestionnaires sont plus susceptibles d'agir. (S'ils peuvent comprendre la logique et le rapport coût / bénéfice.)

À mon humble avis, pour faire un cas convaincant, vous auriez besoin des éléments suivants pour montrer à quel point c'est mauvais:

• nombre d'incidents de support enregistrés pour les problèmes
• le temps passé en heures à entretenir / aider le mauvais code / à corriger les problèmes de support
• Coût du temps basé sur le taux horaire des personnes faisant la maintenance / les pansements / le support
• un moyen de démontrer à quel point ces éléments sont critiques pour l'entreprise

Et pour justifier la refactorisation, vous aurez besoin de:

• estimation du temps pour refactoriser et mettre en œuvre chacun des 3 premiers de ces mauvaises choses
• estimation des coûts de mise en œuvre (mêmes taux horaires que ceux utilisés ci-dessus)

Avec ceux-ci, vous pouvez faire des économies de temps si le refactoring prend beaucoup moins de temps que le support pour 3 incidents pour chacun de ces 3 meilleurs articles. Vous pouvez faire valoir que cette durée plus courte passera

• moins de n incidents de support supplémentaires
• il n'y aura plus de ces incidents pour ces choses (ENCORE MIEUX!)

Cependant, la partie la plus difficile de cette vente répondra à la question suivante, car beaucoup de gens ne prévoient pas de temps dans les horaires pour tout le support que vous faites:

Combien de temps devrai-je encore attendre que le projet en cours Y soit terminé pendant que vous passez du temps à travailler sur ces problèmes avec X ????? (malgré les délais de prise en charge actuels, qui ne peuvent pas être prévus et planifiés dans les diagrammes de Gantt)

Cela dépend beaucoup de la façon dont vous communiquez avec les décideurs et de la façon dont ils comprennent la situation.

Je pense définitivement que cela vaut la peine de le faire, vous obtenez donc la pratique de construire le cas avec les métriques et de vous faire gagner du temps, même si elles ne le font pas. Malheureusement, tout le monde n'est pas facile à convaincre, malgré les données. BONNE CHANCE!

Gardez à l'esprit que la refactorisation introduit également des bogues (que vous remarquerez dans vos tests, mais qui sont néanmoins des bogues et doivent être corrigés). Ne tirez pas un Netscape par accident. Cela dépend de votre définition personnelle de «refactoring». Pour certains, cela signifie «réécrire tout le code» pour d'autres, cela signifie «changer certains éléments internes». Comment dites-vous quel genre vous êtes? Posez-vous la question suivante:

Suis-je en train de changer l'interface publique?

Si la réponse est oui, vous effectuez une refonte. Si la réponse est non, vous effectuez une refactorisation et pouvez probablement le faire tout au long de vos activités quotidiennes sans approbation spéciale. Ceci est pertinent pour votre question car une refonte générera beaucoup plus de bugs, tandis qu'un refactoring est généralement plus facile à réaliser (puisque vos tests exerceront déjà l'interface publique et n'auront pas eux-mêmes besoin d'être modifiés).

C'est un cas difficile à faire, car personne ne sait jamais combien X aurait coûté avec ou sans le refactor qui a été fait il y a un an. D'après mon expérience, les gestionnaires pragmatiques abattent toujours ce genre de choses parce que:

1. Aucun flux de revenus directs ne provient de l'effort (coût financier, non facturable)
2. Un code de travail laid fonctionne toujours, vous risquez de créer des problèmes au lieu de les résoudre (coût potentiel de qualité)
3. D'autres projets seront retardés pendant que vous refactorisez (coût en temps)

Tous ces chiffres sont finalement basés sur des suppositions, dans votre cas, comparant le montant que vous pensez qu'il en coûterait de ne pas refactoriser à ce que vous pensez qu'il en coûterait pour refactoriser. Le mieux que vous puissiez faire est de montrer que vous avez une sorte de base factuelle numérique pour les suppositions, et que vous en avez une assez bonne.

Les avantages sont qu'il sera probablement efficace pour les convaincre de vous laisser refactoriser, et cela pourrait bien se passer et réduire le nombre de bugs.

Les inconvénients sont que si le temps passé à corriger les bogues ne diminue pas au moins autant que le temps passé à la refactorisation, vous ne serez probablement plus autorisé à refactoriser et vous serez probablement blâmé pour le temps "perdu" .

Les économies de temps de débogage obtenues en réduisant la complexité du projet global ou en facilitant l'ajout de fonctionnalités peuvent être trop difficiles à mesurer pour vous aider beaucoup, mais vous pouvez mentionner qu'elles existent.