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

 

Affichage des résultats du sondage: Que faites-vous le plus souvent ?

Votants
74. Vous ne pouvez pas participer à ce sondage.
  • J'essaie de comprendre le code puis je le fais évoluer

    20 27,03%
  • Je jette l'ancien code et je recommence tout à zéro

    0 0%
  • Ça dépend de la qualité du code à faire évoluer, parfois je le garde, parfois je le jette

    52 70,27%
  • Je refuse de travailler sur un autre code que ceux que j'ai créés de A à Z

    0 0%
  • Pas d'avis

    2 2,70%
  1. #1
    Expert confirmé
    Avatar de Blondelle Mélina
    Femme Profil pro
    Ingénieur systèmes et réseaux
    Inscrit en
    mars 2018
    Messages
    82
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 26
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Ingénieur systèmes et réseaux

    Informations forums :
    Inscription : mars 2018
    Messages : 82
    Points : 5 471
    Points
    5 471

    Par défaut Pourquoi réécrire un projet en partant de zéro ? Parce que l'ancien code est un fatras ?

    Pourquoi réécrire un projet en partant de zéro ? Parce que l'ancien code est un fatras ?
    Ou parce qu'il est plus facile d'écrire que de lire un code ?

    Pour un nouveau projet, certains développeurs préfèrent exploiter un code existant et l'adapter à de nouvelles fonctionnalités. D'autres par contre peuvent décider de partir de rien alors qu'il y a un code existant. Mais Joel Spolsky, un développeur de logiciels à New York, estime qu'écrire un programme à partir de zéro est la pire erreur stratégique qu'un développeur puisse commettre.

    Dans l'espoir de mieux se faire comprendre, Joel avait énuméré plusieurs cas, dans un billet datant de l'année 2000. Entre autres, le navigateur de Netscape qui n'existe plus aujourd'hui. Netscape 6.0 allait entrer dans sa première version beta publique à l'époque en sautant la version 5.0. La version 4.0 fut sa dernière version majeure et avait été publiée trois ans plus tôt. Trois ans, c'est terriblement long dans le monde de l'Internet, déclarait Joel. « Pendant ce temps, Netscape était assis, impuissant, alors que sa part de marché s'effondrait », ajoutait-il. La cause, selon Joel, est que ses développeurs ont décidé de réécrire la base de code à partir de zéro.

    Nom : cool-code.jpg
Affichages : 5102
Taille : 19,5 Ko

    D'après Joel Spolsky, les développeurs sont, dans leur for intérieur, des architectes. Et la première chose qu'un architecte veut faire quand il arrive sur un site est de le raser complètement pour construire quelque chose de grandiose. Ils sont un peu hostiles à la rénovation progressive qui consiste entre autres à bricoler et améliorer l'existant.

    Il y a une raison subtile pour laquelle les programmeurs veulent toujours jeter le code et recommencer. La raison en est qu'ils pensent que l'ancien code est un fatras. Ils ont probablement tort. La raison pour laquelle ils pensent que l'ancien code est un fatras est qu'il est plus difficile de lire le code que de l'écrire. C'est pourquoi la réutilisation du code devient si difficile.

    L'idée que le nouveau code est meilleur que l'ancien est manifestement absurde, déclarait Joel. L'ancien code a été utilisé. Il a été testé. Beaucoup de bogues ont été trouvés et ils ont été corrigés. Il n'y a rien de mal à ça. Chacun de ces bogues a pris des semaines d'utilisation dans le monde réel avant d'être trouvé. Le programmeur a peut-être passé quelques jours à reproduire le bogue dans un laboratoire et afin de le corriger. Même s'il s'agit de beaucoup de bogues, le correctif peut être une ligne de code, ou même quelques caractères. Mais, il ne faut pas perdre de vu que beaucoup de temps et de travail sont allés dans cette ligne de code ou ces quelques caractères.

    Quand vous jetez l'ancien code et recommencez à zéro, vous jetez toute cette connaissance, toutes ces corrections de bogues, des années de travail de programmation. Vous jetez votre leadership sur le marché. Vous donnez un cadeau de deux ou trois ans à vos concurrents. Vous gaspillez une quantité exorbitante d'argent en écrivant le code qui existe déjà.

    Même des changements architecturaux assez importants peuvent être faits sans jeter le code. Aussi, un ancien code jugé inefficace peut devenir très efficace avec des améliorations. Pour Netscape, l'opinion publique semble être que l'ancienne base de code était vraiment mauvaise et lente. Néanmoins, cela fonctionnait très bien sur un grand nombre de systèmes informatiques réels, et n'affectait qu'une petite partie du projet, qu'il était possible d'optimiser sans être obligé de réécrire tout le code.

    Pour clore ses propos, Joel dit qu'il « est important de se rappeler que, lorsqu'on part de zéro, il n'y a absolument aucune raison de croire que l'on va faire un meilleur travail que la première fois. Vous n'avez probablement pas la même équipe de programmation qui a travaillé sur la première version, donc vous n'avez « plus d'expérience ». Vous allez juste refaire la plupart des vieilles erreurs et introduire de nouveaux problèmes qui n'étaient pas dans la version originale ».

    Source : Joel Spolsky

    Et vous ?

    Qu'en pensez-vous ?
    Préférez-vous recommencer les projets en partant de rien plutôt que de faire évoluer un code existant ? Pourquoi ?
    Avez-vous déjà pris l'initiative de réécrire un projet en repartant à zéro ? Comment a été cette expérience ?

    Voir aussi :

    Trolldi : une brève histoire totalement exacte des langages de programmation, qui est complètement inspirée de faits
    Quel est l'effet du langage de programmation sur la qualité du logiciel ? Une étude tente de clarifier la situation
    Quelques points clés sur la programmation défensive, destinée à assurer la fonction continue d'un logiciel dans des circonstances imprévues
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre éclairé
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    mai 2016
    Messages
    221
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2016
    Messages : 221
    Points : 797
    Points
    797

    Par défaut

    En principe, dans une entreprise qui fonctionne normalement, ce ne sont pas les développeurs lambda qui devraient prendre la décision de réécrire un projet.
    Cela se décide au minimum au niveau du chef de projet. Et même plutôt au dessus, au niveau d'une direction technique et de la direction générale, parce qu'un simple chef de projet n'a en général pas tous les éléments pour juger du risque qu'il fait courir à sa société.

  3. #3
    Rédacteur/Modérateur

    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    5 376
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 5 376
    Points : 23 176
    Points
    23 176

    Par défaut

    Tous ses points sont valides, mais il ne faut pas non plus voir le code existant comme le graal et la perfection que l'on ne peut plus atteindre et tout nouveau code comme forcément moins bien.
    Je pense qu'un code trop vieux, s'il n'a pas été pensé parfaitement - et plus le code est vieux moins il l'aura été imo -, le faire évoluer devient très difficile voire quasi impossible sans remanier et réarchitecturer un sacré chantier.
    De plus ce remaniement aura le même genre d'effets : supprimer du vieux code, réécrire du nouveau, et les problèmes dont il parle peuvent tout autant arriver.
    Sans compter qu'un tel chantier sera rarement accepté par les supérieurs, et donc ça finira par du hack ci et là pour corriger le nouveau bug - et quand ils s'accumulent, l'historique des corrections devient de plus en plus un frein à l'évolution..
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  4. #4
    MikeRowSoft
    Invité(e)

    Par défaut

    J'ai voté "pas d'avis" car cela dépend de la tâche, du temps qui est accorder à la réaliser.
    Faire confiance au code source si c'est juste modifier une partie du code source ou encore ajouter une "petite" fonctionnalité à un projet interne ou qui a fait l'objet de sous-traitance.
    Vérifier les ajout "extérieur" en détail avant ou durant ou après en fonction du temps et charge de travail globale.

    P.S. : mais comme je veux arrêter le DEV, c'est déjà une vision abandonnée de ma part...
    P.S. 2 : modifier le code source ou remplacer du vieux code par du nouveau, cela dépend de la licence d'utilisation... L'algorithmique reste bien souvent, pas forcément les appels de méthodes et déclarations de class. A l'exception d'une mise à jour de fichier du même groupe d'auteurs extérieur au projet global je n'y toucherai pas...
    P.S. 3 : L'usage d'un RAD comme WinDev 22 Express ou C++ Builder ou NetBeans est lui très souvent le choix que je fais pour partir de zéro. Sauf si le projet n'est pas aussi dense ou complexe que cela et qu'une application console/terminal avec ouverture du port réseau pour accéder à une base de données, dans ce cas, VisualStudio ou GCC...
    P.S. 4 : Une application terminal/console avec une interface GUI accessible via un port quelconque et exploitant le protocole HTTP est plutôt intrigante à envisager, donc Eclipse...
    Dernière modification par MikeRowSoft ; 01/05/2018 à 09h54.

  5. #5
    Membre éclairé Avatar de onilink_
    Profil pro
    Inscrit en
    juillet 2010
    Messages
    231
    Détails du profil
    Informations personnelles :
    Âge : 26
    Localisation : France

    Informations forums :
    Inscription : juillet 2010
    Messages : 231
    Points : 887
    Points
    887

    Par défaut

    Je pense que ça dépend de deux facteurs importants:
    - la qualité de l'API de la codebase
    - la techno utilisée et les alternatives

    Une codebase bien structurée dès le début, avec une bonne API, sera simple a améliorer vu qu'il faudra modifier les implémentations, et pas l'architecture.
    Ce sera donc juste du refactoring et de la correction de bug (d'ou l’intérêt de voir plus loin que le bout de son nez quand on pense a l'architecture au début).

    Au niveau d'un changement de techno, je pense que ça peut en valoir la peine par contre.
    Imaginons que l'application est basé a 90% sur une vielle techno, qui fait mal son boulot, et que le passage vers une nouvelle techno réduirait énormément
    la codebase tout en la simplifiant... si les dev sont formés a cette nouvelle techno alors cela ne sera que bénéfique, si le projet est un projet a long terme.

    Mais dans tous les cas, une ré-écriture de zéro est toujours très risquée, même si cela dépend beaucoup de la complexité de l'application a la base.
    Personnellement, je suis plus partisan de gros refactorings, mais pas d'une ré-écriture complète d'un seul coup.
    Entre chaque refactor au moins, on peut vérifier que l'application fonctionne toujours bien sur les points liés aux modifications, et cela est bien plus simple a
    voir que si on devait tout refaire de zéro.
    Des tutos de pixel art: https://twitter.com/OniMille

  6. #6
    Membre régulier
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    mai 2011
    Messages
    38
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Industrie

    Informations forums :
    Inscription : mai 2011
    Messages : 38
    Points : 79
    Points
    79

    Par défaut

    La reécriture s'impose souvent , car la fonction du logiciel est connu, mais le code source a pu être perdu dans le temps .

    Cela arrive plus souvent que l'on pense.

    Après la reécriture permet de valoriser la nouvelle équipe, il faut bien qu'elle apporte un plus par rapport à l'ancienne équipe. Comment justifier le ROI sur le redéveloppement si on apporte pas de bonnes raisons même si tenant par les cheveux comme on dit...

  7. #7
    Membre actif Avatar de tpericard
    Homme Profil pro
    Ingénieur validation
    Inscrit en
    octobre 2006
    Messages
    69
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur validation
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : octobre 2006
    Messages : 69
    Points : 296
    Points
    296

    Par défaut

    Hello,

    Je pense qu'un certain nombre de critères impactent la décision, dont entre autres :
    - l'ampleur du projet,
    - la documentation technique et fonctionnelle existante,
    - la situation du code (ancien/récent, avec des tests ou pas),
    - réutilisation de certaines fonctionnalités ou pas,
    - le temps imparti,
    - la pérennisation de l'application à long terme (changement de techno par exemple)

    A titre personnel, il m'est arrivé de réécrire des programmes de 30k lignes car trop de codes "spaghettis" et morts dont le résultat était totalement incertain en cas de modifications profondes. Par contre, certains modules étaient très bien écrits, et donc facilement réutilisables. Résultat ? un code allégé de 70% qui répondait aux besoins nouveaux et qui en plus prenait moins de place mémoire.
    Dans certains cas restreints (en terme d'ampleur) j'ai totalement réécrit.
    Enfin, dans d'autres cas, j'ai juste modifié quelques lignes de codes et surtout modifié les tables de paramétrage. Mais là, le code était quasi totalement paramétré, ce qui facilitait la chose.

    Mais tout ça c'est du passé pour moi, je ne fais maintenant plus que tester le travail des développeurs

  8. #8
    Membre du Club
    Profil pro
    Inscrit en
    janvier 2012
    Messages
    24
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2012
    Messages : 24
    Points : 66
    Points
    66

    Par défaut

    Je ne suis pas vraiment d'accord avec ce qui est dit dans la news sur le fait que "L'idée que le nouveau code est meilleur que l'ancien est manifestement absurde, déclarait Joel. L'ancien code a été utilisé. Il a été testé.".

    Si on réécrit du code, ce n'est pas pour qu'il y ait moins de bugs, c'est pour le rendre plus évolutif, plus facile à maintenir. Un programme lorsqu'il est écrit, est concu pour arriver à un scope fonctionnel donné. Ensuite, lorsqu'on lui ajoute des fonctionnalités, sa conception originale peut révéler des limites. Il arrive aussi qu'a force de corrections, le code initialement propre, devient bordélique. Dans ces 2 cas, il arrive un point où il faut agir (Idéalement, même il faudrait agir au fur et à mesure, mais ce n'est pas toujours possible, pour des raisons de temps ou de vision incomplète).

    Lorsqu'on en arrive à un point où il faut agir, la solution de réécrire de zéro est rarement bonne. Parfois elle est inévitable (notamment si on change de langage...), mais souvent il est préférable d'agir en plusieurs phases. La première est de séparer la code base en modules. Cette séparation permettra ensuite de traiter chaque module indépendamment. L'intérêt de cette approche est surtout de diminuer le volume de code à traiter en une fois. Réécrire tout un programme de 0 est souvent une tâche trop grosse et risquée. Traiter un module réduit le risque.

    On pourrait se dire que ce serait encore mieux d'avoir cette approche dès le départ et parfois de nouvelles équipes critiquent le boulot de l'ancienne. Mais le fait est que le concepteur original du programme n'avait pas toutes les billes en mains, alors qu'une fois le logiciel écrit et stabilisé, il est plus simple de voir comment on aurait pu l'écrire différemment.

  9. #9
    Modérateur

    Avatar de Vincent PETIT
    Homme Profil pro
    Ancien développeur matériel électronique (Hard/Soft)
    Inscrit en
    avril 2002
    Messages
    2 106
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ancien développeur matériel électronique (Hard/Soft)
    Secteur : Service public

    Informations forums :
    Inscription : avril 2002
    Messages : 2 106
    Points : 6 734
    Points
    6 734

    Par défaut

    Salut,
    Citation Envoyé par Joel Spolsky
    Joel Spolsky [...] estime qu'écrire un programme à partir de zéro est la pire erreur stratégique qu'un développeur puisse commettre. [...] L'idée que le nouveau code est meilleur que l'ancien est manifestement absurde, déclarait Joel. [...] L'ancien code a été utilisé. Il a été testé. Beaucoup de bogues ont été trouvés et ils ont été corrigés. [...] Pour clore ses propos, Joel dit qu'il « est important de se rappeler que, lorsqu'on part de zéro, il n'y a absolument aucune raison de croire que l'on va faire un meilleur travail que la première fois.
    Je renvoie les propos de M. Joel Spolsky à ce qu'a écrit un jour Thomas Edison : "Ce n'est pas en améliorant sans cesse la bougie qu'on a inventé l'ampoule"

    Même si il est vrai que :
    - c'est risqué de redémarrer de zéro,
    - qu'on va repasser par une longue période de débuggage,
    - qu'on risque de découvrir un problème qu'on avait pas anticipé,
    - etc
    Pour moi repartir de zéro, c'est le chemin de l'innovation.


    Je pense que le point de vu de M. Spolsky est plus celui d'un employeur "ne pas réinventer le fil a couper le beurre car.... ça fait perdre du temps et ça peut coûter plus cher". Bien évidemment, moi même je ne suis pas toujours repartie de zéro lorsque je développais du matériel électronique mais à chaque fois que je l'ai fait j'ai innové et ce n'était pas moins fiable que lorsque je réutilisais.
    La science ne nous apprend rien : c'est l'expérience qui nous apprend quelque chose.
    Richard Feynman

  10. #10
    Membre averti
    Inscrit en
    juin 2010
    Messages
    475
    Détails du profil
    Informations forums :
    Inscription : juin 2010
    Messages : 475
    Points : 395
    Points
    395

    Par défaut

    Citation Envoyé par Bousk Voir le message
    Tous ses points sont valides, mais il ne faut pas non plus voir le code existant comme le graal et la perfection que l'on ne peut plus atteindre et tout nouveau code comme forcément moins bien.
    Je pense qu'un code trop vieux, s'il n'a pas été pensé parfaitement - et plus le code est vieux moins il l'aura été imo -, le faire évoluer devient très difficile voire quasi impossible sans remanier et réarchitecturer un sacré chantier.
    De plus ce remaniement aura le même genre d'effets : supprimer du vieux code, réécrire du nouveau, et les problèmes dont il parle peuvent tout autant arriver.
    Sans compter qu'un tel chantier sera rarement accepté par les supérieurs, et donc ça finira par du hack ci et là pour corriger le nouveau bug - et quand ils s'accumulent, l'historique des corrections devient de plus en plus un frein à l'évolution..
    J'ai déjà vu des applications que je qualifie personnellement d'amas de hacks, plein de hacks peuvent donner un soft

  11. #11
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 859
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 859
    Points : 39 584
    Points
    39 584

    Par défaut

    Joel Spolsky, un développeur de logiciels à New York
    A lire ça on pourrait croire que Joel Spolsky est un développeur lambda, ce qui est loin d'être le cas... Son blog était très suivi à une époque (mais il n'écrit plus beaucoup aujourd'hui), et c'est un des fondateurs de StackOverflow. Il a même son article Wikipedia

    Sinon j'aime bien le concept de faire une news à partir d'un article qui date d'il y a 18 ans (même si l'article est toujours d'actualité)

    Pour revenir au sujet, je suis moins catégorique que Joel Spolsky. Parfois le code existant est une sombre m***e, et on perd moins de temps à repartir de zéro qu'à essayer de régler tous les problèmes du code existant. En d'autres termes, et pour reprendre l'analogie avec l'architecture : si les fondations sont pourries, impossible de construire un immeuble solide dessus. Et si l'immeuble est déjà construit sur des fondations pourries, toucher aux fondations est délicat, voire impossible, sans faire écrouler l'immeuble.

  12. #12
    Membre éclairé
    Homme Profil pro
    chomeur
    Inscrit en
    avril 2015
    Messages
    451
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 73
    Localisation : France, Seine Maritime (Haute Normandie)

    Informations professionnelles :
    Activité : chomeur
    Secteur : Distribution

    Informations forums :
    Inscription : avril 2015
    Messages : 451
    Points : 866
    Points
    866

    Par défaut

    l'histoire de netscape me semble peut viable car entre netscape 4 et 6 la vision n'était plus la même netscape 4 utilisait le système de layer qui fut un mauvais choix et fort possible qu'il fallait soit faire des modification de façon profonde ou repartir de zero de plus il me semble que firefox a été fondé a partir du code de netscape 6.

  13. #13
    Membre expert
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    700
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 700
    Points : 3 114
    Points
    3 114

    Par défaut

    Je cite un passage important de l'article original :
    As a corollary of this axiom, you can ask almost any programmer today about the code they are working on. “It’s a big hairy mess,” they will tell you. “I’d like nothing better than to throw it out and start over.”

    Why is it a mess?

    “Well,” they say, “look at this function. It is two pages long! None of this stuff belongs in there! I don’t know what half of these API calls are for.”

    [...]

    Back to that two page function. Yes, I know, it’s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I’ll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn’t have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.

    Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it’s like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.

    When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.
    À mon avis, le problème de fond de l'exemple ci-dessus, c'est le manque de commentaires dans le code.
    Quand les API nous obligent à écrire du code bizarre et contre-intuitif pour que ça marche dans les cas limites, il faut commenter pourquoi on a écrit telle bizarrerie et quel cas particulier cela prend en compte.

    De manière générale, chaque fois que l'on écrit un code qui ressemble à du mauvais code, mais qui est justifié si on connaît la raison, alors cette raison doit apparaître dans le code, par exemple sous la forme d'un commentaire. Sinon, le code que l'on écrit est effectivement mauvais et, parmi les développeurs qui reprendront le code et se plaindront de la mauvaise qualité du code, certains auront raison de se plaindre. (D'autres auront tort de se plaindre, car ils feront pareil.)

  14. #14
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Architecte Web / Android
    Inscrit en
    août 2003
    Messages
    5 182
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Architecte Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 5 182
    Points : 13 667
    Points
    13 667

    Par défaut

    La problématique avec du code existant c'est qu'au moment de sa création il répondait à un besoin précis.
    Puis au fil du temps de la vie du projet , il est surement refactoré plusieurs fois - toujours en urgence, et jamais comme il faudrait - pour finalement au bout de 10 ans ne plus faire du tout ce pour quoi il était prévu à la base (j'exagère à peine). Du coup le code n'est pas forcément mauvais mais la conception initiale n'est plus adapté au nouveau besoin.
    C'est dans ces cas là que je juge pertinent de réecrire.
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  15. #15
    Membre du Club
    Profil pro
    Inscrit en
    juin 2009
    Messages
    19
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 19
    Points : 46
    Points
    46

    Par défaut

    Parfois, c'est l'équipe initiale qui préfère réécrire : évolution du contexte technique (outils) ou recentrage (changement de spécifications larvé : apparaitre à un point B tout en disparaissant du point A, c'est un déplacement).
    Il faut des retours utilisateur très précis (qu'est-ce qui est utile, qu'est ce qui sert peu, qu'est-ce qui est gênant/inutile) de sorte à associer une évolution technique à une évolution des spécifications : il faut solidariser la demande, laquelle n'est souvent pas assez forte sur ce genre de projet.
    Au niveau maitrise d'ouvrage, une fois n'est pas coutume, il faut des gens compétents sachant demander (et comprendre) des documents de conception justifiant l'effort (à la fois les nouveaux et les anciens ...).
    Parfois, un peu de demande de rétro-ingénierie suffit à mettre une nouvelle équipe dans le code d'un ancien projet ...
    Je pourrais citer d'autres écueils, mais avec ceux-là, on a déjà 90% des échecs.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 210
    Points : 22 827
    Points
    22 827

    Par défaut

    J'ai sans doute cité cet article de Joel Spolsky des dizaines de fois en dix ans, et il n'était pas nouveau quand je l'ai personnellement découvert. C'est donc très rigolo de le voir en actualité ce jour.

    Ce qu'il dit d'ailleurs, ce n'est pas qu'il ne faut jamais réécrire. C'est qu'il ne faut pas réécrire en oubliant les leçons du passé. J'ai appris à la dure :aie: qu'il avait raison. Une bonne partie des horribles verrues qu'on trouve dans un code ancien sont des réponses à des expériences douloureuses, et qu'il ne faut ps perdre. repartir d'une page blanche en se disant "c'étaient tous des nuls", c'est aller droit dans le mur. Repartir d'une page blanche en se disant "bon, c'est horrible, mais il doit bien avoir une raison pour laquelle ils se sont fait chier à faire ça", par contre, ça marche. Je l'ai fait. Dans la douleur, mais je n'ai perdu aucune des fonctionnalités de ce code de 36 ans d'âge que j'ai entièrement refait depuis zéro.

    (Bon, soyons honnête, il y a deux algos, j'ai rien compris, j'ai repris tel quel, et vérifié que le résultat ne changeait jamais, sur une volumétrie de 2 millions de cas de prod, soit un an de traitements. Tout le reste, propre et maintenable. Et le client a mesuré qu'il a économisé plus d'un équivalent temps plein en maintenance, sur les 4 premières années. Pour un projet de 172 jours).
    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.

  17. #17
    Membre du Club
    Profil pro
    Inscrit en
    septembre 2005
    Messages
    26
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2005
    Messages : 26
    Points : 58
    Points
    58

    Par défaut Vieux stack = vieux developpeurs

    Le problème qui peut se poser aussi c'est qu'un vieux code est écrit avec de vieilles technos et qu'il est dur de recruter de jeunes talents sur des technos obsoletes (on peut les comprendre). Avec un marché de l'emploi des développeurs comme il est aujourd'hui, et les nouveaux langages ou framework qui attirent les jeunes tous les 4 matins, avoir du code "frais" c'est aussi faciliter le recrutement et donc la survie du projet.

  18. #18
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 066
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 066
    Points : 7 485
    Points
    7 485

    Par défaut

    Citation Envoyé par persi Voir le message
    Le problème qui peut se poser aussi c'est qu'un vieux code est écrit avec de vieilles technos et qu'il est dur de recruter de jeunes talents sur des technos obsoletes (on peut les comprendre). Avec un marché de l'emploi des développeurs comme il est aujourd'hui, et les nouveaux langages ou framework qui attirent les jeunes tous les 4 matins, avoir du code "frais" c'est aussi faciliter le recrutement et donc la survie du projet.
    Certaines applications sur lesquelles je travaille sont encore en Cobol.
    Curieusement, je n'ai pas trop de mal à trouver des dev (y compris des jeunes) mais j'ai surtout un gros problème de TJM et de turn over.

    Si je prends quelqu'un de déjà formé, le TJM explose et j'ai mon contrôleur de gestion qui bloque.
    Et lorsque je prends un jeune que je fais former, j'ai besoin qu'il reste au moins 20 mois sur le poste pour amortir le coût de la formation mais assez souvent, trop souvent, ils partent avant ou en tout cas, beaucoup trop rapidement car une fois formé et avec un peu d'expérience, leur valeur sur le marché grimpe et ils vont au plus offrant.
    Je ne peux pas leur en vouloir car j'ai fait de même à mes débuts (après 3 ans dans ma première SSII, je suis parti ailleurs en augmentant mon salaire de 30% d'un coup).

  19. #19
    MikeRowSoft
    Invité(e)

    Par défaut

    Citation Envoyé par persi Voir le message
    Le problème qui peut se poser aussi c'est qu'un vieux code est écrit avec de vieilles technos et qu'il est dur de recruter de jeunes talents sur des technos obsoletes (on peut les comprendre).
    Sachant que l'esprit est modelé par son environnement, cela arrive. Mais il a un instant il c'est plongé dans l'histoire technique, il y a effectivement des chances que les vielles techno aient réussi à séduire comme elles l'ont fait avec les "pionniers".

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 210
    Points : 22 827
    Points
    22 827

    Par défaut

    Citation Envoyé par persi Voir le message
    Le problème qui peut se poser aussi c'est qu'un vieux code est écrit avec de vieilles technos et qu'il est dur de recruter de jeunes talents sur des technos obsolètes (on peut les comprendre). Avec un marché de l'emploi des développeurs comme il est aujourd'hui, et les nouveaux langages ou framework qui attirent les jeunes tous les 4 matins, avoir du code "frais" c'est aussi faciliter le recrutement et donc la survie du projet.
    (1) oui, mais si tu fais un code "frais" qui ignore tout l'historique des vieux nanards, tu vas te retaper tooooooous les bugs qui avaient tant fait souffrir tes prédécesseurs. Pas glop. Une refonte de code, ça se fait avec des outillages systématiques de test automatique. C'est ce que dit l'article. C'est ce que j'ai fait.

    (2) On peut former des cobolistes, hein. Moi, je n'avais pas d'informatique sur mon CV, on m'a lançé dans le grand bain, et on m'a tutoré. Et j'ai fini par être productif. ce qui nous amène à :

    Citation Envoyé par Saverok Voir le message
    Certaines applications sur lesquelles je travaille sont encore en Cobol.
    Curieusement, je n'ai pas trop de mal à trouver des dev (y compris des jeunes) mais j'ai surtout un gros problème de TJM et de turn over.

    Si je prends quelqu'un de déjà formé, le TJM explose et j'ai mon contrôleur de gestion qui bloque.
    Et lorsque je prends un jeune que je fais former, j'ai besoin qu'il reste au moins 20 mois sur le poste pour amortir le coût de la formation mais assez souvent, trop souvent, ils partent avant ou en tout cas, beaucoup trop rapidement car une fois formé et avec un peu d'expérience, leur valeur sur le marché grimpe et ils vont au plus offrant.
    Je ne peux pas leur en vouloir car j'ai fait de même à mes débuts (après 3 ans dans ma première SSII, je suis parti ailleurs en augmentant mon salaire de 30% d'un coup).
    Pour le turn-over, ben, de toutes façons, il y a le même problème sur les nouvelles technos. On a beaucoup de mal à retenir nos devs, ici. Spécialement les jeunots.

    Pour les anciens, c'est le problème des grands comptes, ils sont incapables de s'adapter aux réalités du marché. Ils ont contrôlé les couts pendant 15 ans, et ça leur revient dans la gueule maintenant. si j'étais totalement cynique, je dirais que le marché a attendu que je ne sois plus dans le pool disponible pour exploser niveau tarif(ben oui, je ne tire plus la moyenne vers le bas...). Un vieux qui a vingt ans de bouteille, et qui est capable de corriger un problème avant même que sa hiérarchie ne s'en rende compte, ça a un cout. et il n'y a quasiment plus que ça sur le marché, en effet. J'ai vu entre 2000 et 2014 la qualité moyenne du coboliste moyen croitre radicalement. En 2000, j'étais nul, débutant, et la plupart ne m'arrivaient pas à la cheville. En 2010, j'étais un vétéran efficace, proactif, et apprécié, et il était difficile de trouver moins bon que moi sur le marché.

    Fatalement, le TJM augmente, dans ces conditions. Mais tant que l'acheteur moyen ne comprend pas la valeur ajoutée qu'on les cobolistes du jour par rapport à ceux de 2000(une productivité multipliée par 10, au bas mot), ben il ne voit pas pourquoi il devrait ne serait-ce qu'ajuster les tarifs de 2000 par rapport à l'inflation.
    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.

Discussions similaires

  1. Réponses: 3
    Dernier message: 18/12/2017, 15h43
  2. [AC-2010] Forcer 'assistant de création à faire du code vba plutôt que des macros
    Par lololebricoleur dans le forum Access
    Réponses: 2
    Dernier message: 20/11/2013, 17h30
  3. Réponses: 7
    Dernier message: 01/09/2009, 20h24
  4. Réponses: 2
    Dernier message: 13/07/2008, 14h57

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