IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

ALM Discussion :

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


Sujet :

ALM

  1. #1
    Nouveau Candidat au Club
    Inscrit en
    Juillet 2012
    Messages
    1
    Détails du profil
    Informations forums :
    Inscription : Juillet 2012
    Messages : 1
    Points : 1
    Points
    1
    Par défaut 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 .
    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 !

  2. #2
    Expert confirmé Avatar de ManusDei
    Homme Profil pro
    vilain troll de l'UE
    Inscrit en
    Février 2010
    Messages
    1 619
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : vilain troll de l'UE

    Informations forums :
    Inscription : Février 2010
    Messages : 1 619
    Points : 4 350
    Points
    4 350
    Par défaut
    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.
    http://www.traducteur-sms.com/ On ne sait jamais quand il va servir, donc il faut toujours le garder sous la main

  3. #3
    Provisoirement toléré
    Homme Profil pro
    Inscrit en
    Août 2002
    Messages
    143
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Août 2002
    Messages : 143
    Points : 261
    Points
    261
    Par défaut
    Citation Envoyé par clm-nt Voir le message
    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é.

  4. #4
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par clm-nt Voir le message
    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"..
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  5. #5
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  6. #6
    Expert éminent sénior

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    10 603
    Détails du profil
    Informations personnelles :
    Âge : 66
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 603
    Points : 17 913
    Points
    17 913
    Billets dans le blog
    2
    Par défaut
    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...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  7. #7
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 237
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 237
    Points : 36 687
    Points
    36 687
    Par défaut
    Autre idée à explorer: les mécanismes d'injection de code style AspectJ (pour Java).

    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:
    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?

    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
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

Discussions similaires

  1. Réponses: 4
    Dernier message: 19/11/2014, 17h44
  2. Réponses: 3
    Dernier message: 14/08/2012, 11h24
  3. Mettre une référence web au lieu d'une référence de service ?
    Par chinoismasque dans le forum Windows Phone
    Réponses: 20
    Dernier message: 10/08/2011, 16h20
  4. comment lancer automatiquement 1 script au lieu d'une action sur un boutton
    Par winnie82 dans le forum Général JavaScript
    Réponses: 16
    Dernier message: 13/07/2006, 18h13
  5. [Experience] Comment justifier une refonte architecturale ?
    Par ludovic.fernandez dans le forum Qualité
    Réponses: 10
    Dernier message: 23/10/2005, 23h28

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo