Comment justifier d'une réécriture technique au lieu d'une duplication du code ?

Bonjour,

Notre client souhaite faire évoluer son application et demande d'appliquer quelques règles de gestion spécifiques à certains objets du système.
95% des règles sont identiques pour tous les objets et 5% changent pour des objets très particuliers.

L'idée de l'équipe de développement est d'expédier le code commun, 95%, dans des classes et composants génériques, puis d'étendre ces composants pour les 5% de spécifique.

Mais cela demande un temps non négligeable pour réaliser cette (re)factorisation du code.
Pour faire baisser les coûts et les risques de régression, je sais que notre client va nous demander de dupliquer le code source avant de modifier les 5% de spécifiques 8O.
Nous aurons donc 2 classes avec 95% de code copié collé. Inacceptable pour nous bien évidemment.

Comment justifier auprès du client cette réécriture technique du code ? Ça prend du temps, ça ne lui apporte rien (l'application est identique vu de l'extérieur) et ça introduit fatalement des risques de régressions. Tout ceci peut en effet être évité par une duplication pur et simple des classes.
Existe-t-il des arguments techniques très précis et mesurables que nous pourrions lui présenter ? Car évidemment le "c'est plus long maintenant mais on gagne du temps en maintenance dans l'avenir" ne passera jamais, c'est un client après tout :).


Merci !

Passer par le portefeuille et insister sur les coûts.

"C'est pas beaucoup plus long et ça vous allez économiser plein d'argent dans l'avenir" Le temps de maintenant il s'en fout, l'argent que lui coûte la maintenance, ça c'est intéressant.

En plus si le code est dupliqué, ça va lui coûter X fois plus cher à maintenir.

Citation:

---

Envoyé par clm-nt

Car évidemment le "c'est plus long maintenant mais on gagne du temps en maintenance dans l'avenir" ne passera jamais

---

Pas forcément.. Si tu prends le temps de bien leur expliquer, de leur montrer qui si le système évolue, tu recopieras du code au lieu de simplement le réutiliser et que donc ça coûteras moins cher.

Un client peut avoir envie de faire de la qualité.

Citation:

---

Envoyé par clm-nt

Comment justifier auprès du client cette réécriture technique du code ?

---

Très difficile, car la réponse qui me vient l'esprit en tant que client c'est "vous avez mal conçu votre truc"..

Citation:

---

Envoyé par souviron34

Très difficile, car la réponse qui me vient l'esprit en tant que client c'est "vous avez mal conçu votre truc"..

---

La duplication de code est quand même l'alpha et l'oméga de la mauvaise conception.

Par contre, si je comprends bien, le code actuel est standard. On veut coder des exceptions. Serait-il si couteux d'encapsuler le standard, pour forcer des exceptions dans les cas exceptionnels? Je n'ai pas la réponse, ça dépend du système. Mais c'est parfois une solution. Il m'est arrivé de l'appliquer. Il est tout à fait possible que ça soit une mauvaise idée aussi, à étudier.

ce que je veux dire, c'est que alors que je demande une petite modif (5%, c'est pas grand'chose) de régles de gestion (on n'a pas dit de fonctionalité !!!!), si on me répond "on a 2 choix : dupliquer le code et faire une vrrue, ou tout repenser", ma réponse est "vous avez mal conçu", ce qui ne me donne pas une bonne opinion du prestataire, car il a conçu au plus juste / en dur, sans penser à justement une factorisation, un fichier de config, ou...

Autre idée à explorer: les mécanismes d'injection de code style AspectJ (pour Java).

Citation:

---

Comment justifier auprès du client cette réécriture technique du code ? Ça prend du temps, ça ne lui apporte rien (l'application est identique vu de l'extérieur)

---

Mettez vous à la place du client!
Si tout le monde est d'accord pour dire:

Citation:

---

Notre client souhaite faire évoluer son application et demande d'appliquer quelques règles de gestion spécifiques à certains objetsdu système

---

C'est une évolution mineure. Le client a déjà justifié auprès de sa direction un petit budget avec un budget risque au cas où.

Si pour cette évolution mineure, vous proposez un chantier de re-factoring de l'ensemble du code, il va falloir que le client explique que la petite modification demandée coûtera 2, 5, 10, x fois plus que prévu.

En plus cette approche est proposée pour réduire des "risques".

Si vous ne pouvez pas établir que pour 5 à 10% du budget initial cela va permettre de réduire ces risques "probables" d'un facteur 10 ou 100 (et fiabiliser la date de livraison), comment voulez vous qu'il "achète"?
Si lui demandez de dépenser une partie de son budget risque maintenant, il faut le convaincre que de toutes façons il l'aurait de toutes façons dépensé "plus tard"...

=> Ces gros changements passent mieux pour la livraison d'une nouvelle version "majeure" de l'application (ou mieux à la version initiale).

Il faut aussi faire attention fausses/bonnes intuitions.

Les seules garanties de non régression sont:

• les tests de non régression - ils sont rarement assez "fins",
• n semaines de bon fonctionnement après mise en production

La seule façon de limiter les risques de régression sont de maîtriser les dépendances fonctionnelles entre ce qui devra être modifié et le reste.
=> Au plus vous limitez les modifications, au plus vous réduirez ce risque.

En fait, vous demandez au client de dépenser plus pour réduire un risque alors qu'intuitivement augmenter le code modifié ne fait qu'accroître les risques de régression?

Citation:

---

L'idée de l'équipe de développement est d'expédier le code commun, 95%, dans des classes et composants génériques, puis d'étendre ces composants pour les 5% de spécifique.

---

C'est une idée discutable dans le cadre d'une nouvelle version "majeure" (et pourquoi pas la version initiale?).
Pour une évolution mineure, c'est trop lourd: il faut oublier...

- W