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

Débats sur le développement - Le Best Of Discussion :

Êtes-vous pour le refactoring de code ou la réécriture d'un projet de zéro ?


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Chroniqueur Actualités

    Êtes-vous pour le refactoring de code ou la réécriture d'un projet de zéro ?
    Êtes-vous pour la réécriture d'un projet de zéro ou le refactoring de code ?
    Remesh a opté pour la première façon de faire et partage son expérience

    Lorsqu’il faut aborder de nouveaux projets, deux écoles s’affrontent chez les développeurs : certains préfèrent exploiter un code existant et l’adapter à de nouvelles fonctionnalités, tandis que d’autres préfèrent partir de rien bien qu’il y ait un code existant.

    Joel Spolsky, un développeur et écrivain américain, fait partie de la première école. Pour lui, écrire un programme à partir de zéro est la pire erreur stratégique qu'un développeur puisse commettre. Dans un billet, il a énuméré plusieurs cas pour mieux se faire comprendre entre autres, le navigateur de Netscape qui n'existe plus aujourd'hui. Netscape 6.0 allait entrer dans sa première version bêta 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.

    Vingt ans plus tard, Nicholas Tietz-Sokolsky a publié un billet sur le blog d’ingénierie de Remesh où il vient remettre en cause cette philosophie ne serait-ce que par l’expérience même de Remesh :

    « Notre histoire commence en janvier 2019. Remesh était alors une entreprise beaucoup plus petite. Nous avions récemment embauché quelques ingénieurs et nous avions 5 ingénieurs focalisés sur le produit, et une poignée d'ingénieurs focalisés sur l'apprentissage automatique (ML) ou DevOps. Malgré l'embauche récente de ces ingénieurs, notre vitesse était toujours douloureusement basse. L'ajout de fonctionnalités simples a pris du temps. Nous avons eu beaucoup de bogues dans le produit que nous avons simplement reconnu comme étant ‘connus’ et que nous n'avons pas corrigés. Et le produit dans son ensemble semblait n'avoir pas changé de manière significative depuis un certain temps.

    « Il est important de comprendre pourquoi nous avons eu ces problèmes. Nous avons supposé (et après la réécriture, validé) que le problème ne venait pas de notre côté : après tout, nous avions embauché des ingénieurs talentueux. Le problème venait en grande partie notre base de code et notre processus. La base de code héritée dans laquelle nous travaillions n'était pas adaptée à la fois aux compétences de notre équipe et aux problèmes que nous résolvions, et notre processus encourageait et s'appuyait sur des connaissances cloisonnées: il n'y avait pas de ‘stack full’ à Remesh ».

    L'état de la base de code de Remesh en janvier 2019

    L’ancienne application de Remesh a été conçue à l'origine pour quelque chose de très différent de ce à quoi elle sert actuellement. Au départ, Remesh permettait aux utilisateurs de tenir des conversations bidirectionnelles entre des groupes entiers ou un individu et un groupe. Nicholas a illustré le premier cas d’utilisation (conversations bidirectionnelles entre groupes) en parlant des démocrates et des républicains qui se parlent pour trouver un terrain d’entente, le second (conversations bidirectionnelles entre des groupes et un individu) en parlant du maire d’une ville qui s’adresse à ses citoyens pour mieux comprendre leurs besoins.

    « Cependant, comme nous avons trouvé l'adéquation au marché des produits, le cas d'utilisation a changé. Nous nous sommes penchés sur un modérateur singulier parlant à un groupe de personnes », a-t-il noté.

    À la suite de ce changement, certaines anciennes décisions de conception n'avaient plus de sens et le schéma nécessitait des changements majeurs. Au-delà des problèmes de base de données, il reconnait que la base de code elle-même était assez difficile à comprendre, car les fonctionnalités avaient été boulonnées sans beaucoup de refactoring majeur : « nous avions une couverture de test très médiocre dans les zones qui avaient le plus besoin de refactoring car il s'agissait du code le plus ancien, écrit avant d'établir de bonnes pratiques de test ».

    Au-delà de tout cela, les langages et frameworks utilisés ne marchaient pas avec leur équipe. La base de code backend a été écrite dans Elixir, que peu de leurs développeurs connaissaient très bien. L'une des bases de code frontend a été écrite dans une version très ancienne d'Angular et ils avaient deux autres frontend qui étaient en React : « peu de nos ingénieurs étaient à l'aise sur l’un d’eux, sans parler des trois. Les langages et les frameworks utilisés ne convenaient ni à notre équipe ni à notre problème, ce qui nous a un peu ralentis ».


    Quelles étaient les options ?

    À ce stade, Remesh a réalisé que sa base de code avait besoin d'un changement majeur. Dans ce cas de figure, trois options se posent à vous :
    • Le refactoriser jusqu'à ce que le problème soit résolu
    • Le réécrire d'une traite
    • Le réécrire au coup par coup

    « Pour le frontend, le refactoring n'était pas vraiment une option. Notre version d'Angular était suffisamment ancienne pour que, malheureusement, nous n'ayons pas vraiment de chemin de mise à niveau clair vers une version moderne d'Angular (de toute façon nous ne voulions pas être sur une version d'Angular). Et puisque nous anticipions des changements majeurs dans l'interface utilisateur et l'API, un refactoring ne serait pas réalisable. Donc, sur le frontend, nous devions décider entre réécrire d'un seul coup ou réécrire au coup par coup.

    « Le back-end avait quelques problèmes que nous voulions résoudre - notre schéma, notre langage et notre base de code ne correspondaient plus au problème que nous résolvions. Nous avons utilisé Elixir pour son support massif de concurrence, pourtant nous n'en avons jamais eu besoin et cela a fini par nous porter préjudice : la façon dont la concurrence est gérée dans la machine virtuelle Erlang a rendu le profilage très difficile, car vous savez ce qui est calculé, mais pas d'où il est appelé - et bonne chance avec le réglage des performances. La base de code Elixir a également limité la contribution de nos ingénieurs ML à la base de code backend : ils travaillaient en Python tous les jours et n'avaient pas le temps de se plonger profondément dans Elixir. Pour faire court, nous voulions quitter Elixir et passer à Python, car alors toute notre équipe aurait pu contribuer, le langage prendrait en charge les problèmes et nous aurions plus de facilité à profiler le code ».

    Au bout du compte, l’argument en faveur de la réécriture se résumait vraiment à cette confluence de facteurs :
    • Remesh voulait que chaque membre de son équipe puisse contribuer à la base de code backend, et Python avait l’avantage d'avoir déjà une large adoption déjà au sein de l’équipe et d’être facile à apprendre
    • L’ancienne base de code était si fragile et si peu testée que sa refactorisation serait un processus ardu.
    • Remesh pouvait gagner en efficacité en passant à un framework « opinionated » comme Django, avec beaucoup de valeurs par défaut permettant de gagner du temps (comme Django Admin).
    • Remesh voulait avoir l'opportunité de créer une toute nouvelle version influencée par ce que l’entreprise avait appris des clients et pourrait ensuite gérer la transition vers la nouvelle version plutôt que de mener une bataille pendant 12 mois avec beaucoup de clients à chaque changement.

    « Pour arriver à cette décision, nous avons fait une planification assez approfondie », indique Nicholas qui note que l’équipe devait impérativement déterminer quel serait le niveau d'effort pour chacune de ces options. « Il est apparu assez rapidement que la réécriture de l'application en gros prendrait du temps, mais que sa refactorisation ou sa réécriture fragmentaire prendrait beaucoup plus de temps, il y avait beaucoup, beaucoup plus d'incertitude autour d'une telle approche. Si nous options pour la refactorisation, nous risquerions beaucoup plus ».

    Autant d’éléments qui les ont conduits à tout réécrire : « nous étions déterminés à réécrire, car cela nous permettrait de corriger les erreurs des années passées, et cela nous permettrait de faire avancer le produit en même temps ».

    Remesh a donc commencé à tout réécrire à partir de février 2019 « après avoir planifié les fonctionnalités que nous devrions inclure pour la parité des fonctionnalités avec la plateforme existante dans le cadre d'un effort de diligence raisonnable pour nous assurer que c'était la bonne voie ».

    « Le processus réel de construction de la nouvelle version s'est déroulé sans heurts après un démarrage cahoteux. C'était douloureux pour tout le monde de passer à une nouvelle pile technologique. Bien que nous ayons choisi Python pour l'accessibilité de toute l'équipe, il y avait encore ceux parmi nous qui avaient besoin de l'apprendre. Et aucun de nos ingénieurs backend ou fullstack ne connaissait Django au départ (alors que notre ingénieur frontend principal le connaissait bien). De même sur le frontend, beaucoup d'entre nous connaissaient React, mais peu d'entre nous avaient une expérience approfondie avec TypeScript, vers lequel nous avons également choisi de migrer. Cela dit, après avoir eu un temps d'apprentissage initial, nous sommes tous devenus assez productifs assez rapidement et nous avons pu apprendre ensemble. Ce fut notre première validation : même avec moins d'expérience dans cette nouvelle pile, nous avons pu créer des fonctionnalités beaucoup plus rapidement. Il faudrait plus de temps pour s’assurer que les gains de productivité provenaient de la nouvelle pile et de la nouvelle base de code, plutôt que du fait que le projet soit entièrement nouveau, néanmoins nous y sommes finalement arrivés ».

    Les leçons tirées de cette expérience

    Après cette expérience, il a noté des leçons qu’ils ont tirées de leurs échecs pendant le processus, mais aussi de leurs succès :

    « Nous avons réussi parce que nous avons commencé avec une vision claire de ce que nous construisions (un vrai MVP, où nous savions que l'ancien produit était «viable»), et nous y avons réduit la portée selon nos besoins afin de rester avec une vision claire. Bien que nous n'ayons pas livré « dans les temps » (d’ailleurs personne ne le fait), nous n’avons pas pris autant de temps que Netscape. La durée totale du projet était inférieure de deux fois au temps que nous avions prévu si nous avions fait une copie exacte (en termes de fonctionnalités) de l'ancien produit, mais nous nous sommes retrouvés avec quelque chose de bien meilleur et avec de nouvelles fonctionnalités très souhaitées, comme la possibilité de télécharger et d'envoyer des vidéos et la possibilité de télécharger un rapport PowerPoint généré automatiquement de votre conversation.

    « L'une des autres clés de notre succès a été d'obtenir des commentaires tôt et souvent. Pendant la réécriture, nous avons utilisé le produit en interne très souvent, découvrant des bogues critiques et des problèmes de performances. Nous avons également organisé des démonstrations régulières pour l'ensemble de l'entreprise afin d'obtenir rapidement des commentaires du service customer success, ventes, recherche et éventuellement des premiers clients qui pouvaient tolérer les échecs.

    Il a reconnu qu’ils se sont trompés parce qu’ils ont décidé de s’appuyer sur deux technologies que l’équipe n’avait pas beaucoup utilisées beaucoup : « nous avions déjà utilisé TypeScript dans un prototype, mais nous n'avions pas de connaissances approfondies à ce sujet. Tout s'est bien passé, mais nous ne sommes toujours pas convaincus que la productivité est plus élevée et le taux de défauts est plus faible; le temps nous le dira, et je pense que le jury est toujours sur le typage statique ».

    L'autre erreur était d'utiliser GraphQL. « Nous avions des niveaux d'expérience assez élevés avec REST et Redux, mais nous n'avions auparavant utilisé GraphQL que dans un prototype. Rétrospectivement, GraphQL a rendu le prototypage initial beaucoup plus rapide, mais à long terme, car il y a des décisions de conception critiques dans Apollo avec lesquelles nous ne sommes pas d'accord (comme ne pas exposer la capacité de détecter les déconnexions / reconnexions dans les abonnements sur le frontend) et notre expérience de la mise au point des performances sur le backend était ... disons simplement que ce fut un mois ou deux difficile de ma vie que j’espère ne plus revivre ». L’équipe est en train de se séparer progressivement de GraphQL.

    Réécrire ou ne pas réécrire ?

    « Sur la base de mon expérience ici, vous ne devriez probablement pas le faire si vous croyez dans le battage médiatique indiquant que la réécriture n'est jamais la bonne décision. Dans tous les cas, vous devez par défaut choisir la position ‘non’, puis travailler très dur pour la justifier si nécessaire. Voici quelques scénarios où une réécriture pourrait être justifiée :
    • Si votre architecture ou schéma est très loin de s’aligner avec ce dont vous avez besoin et qu'il n'y a pas de chemin de migration clair, car la mise à jour incrémentielle de l'architecture ou des schémas serait extrêmement difficile
    • Si ces problèmes ralentissent considérablement votre équipe
    • Si votre pile technologique actuelle empêche de nombreux ingénieurs de contribuer et les former à la pile technologique n'est pas une option.

    « Même si vous cochez toutes ces cases, vous devez tenir compte des réalités commerciales et savoir si cela a du sens pour votre entreprise, votre équipe. Il peut y avoir plus de scénarios où une réécriture est justifiée. Il est difficile de le justifier, mais cela en vaut la peine et peut être couronné de succès ».

    En définitive, une réécriture de code vous donne l'avantage de l'expérience : vous connaissez les faiblesses de l'ancien système, les défauts de conception, les exigences actuelles et la future feuille de route. Vous pouvez faire des planifications et concevoir un système qui surmontera les problèmes que vous avez anticipés. L'inconvénient est que vous devez maintenir deux systèmes pendant que vous écrivez le nouveau.

    En revanche, le refactoring vous permet de remplacer lentement les anciens morceaux de code de votre système par de nouveaux. Prenez une fonction, une classe ou un module, et vous le/la réécrivez dans le cadre de votre projet. Tous vos tests et intégrations sont là, il est facile de vérifier que vous n'avez rien cassé, pour vous assurer que la fonctionnalité reste la même. Mais vous ne pouvez pas faire des merveilles avec le refactoring de code, vous ne pouvez pas choisir un langage de programmation différent et la plupart du temps, vous ne pouvez même pas remplacer le framework principal de votre projet.

    Source : Remesh

    Et vous ?

    Êtes-vous pour le refactoring de code ou la réécriture d'un projet de zéro ? Dans quelle mesure ?
    Que pensez-vous du cas de Remesh ?
    Avez-vous déjà été amené à réécrire un code de zéro ? Pouvez-vous partager votre expérience ?
    Quels sont les éléments qui pourraient pousser une équipe à envisager de réécrire son code ?

    Voir aussi :

    L'Allemagne a proposé en open source tout le code de Corona-Warn-App, son application de contact tracing qui va lui coûter 3 millions d'euros tous les mois
    L'équipe du projet OpenZFS retire « les références inutiles à l'esclavage » de sa base de code en mettant de côté le terme « slave » qui fait remonter une expérience humaine douloureuse au souvenir
    L'équipe du langage Go retire les termes "whitelist", "blacklist", "master" et "slave" de sa documentation et de sa base de code parce qu'ils véhiculent des stéréotypes raciaux
    A-t-on besoin d'apprendre la programmation pendant 10 ans avant d'être un développeur accompli ? Partagez votre expérience
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Expert éminent sénior
    Parfois, il est plus simple de tout re-écrire, que de modifier / déboguer.
    "Parce que le diable est dans les détails, une vision sans nuance ne peut prétendre à la compréhension du monde."

    Mon ancienne page perso : https://neckara.developpez.com/

  3. #3
    Membre expérimenté
    C'est surtout une question de combien ça coûte. Le refactoring peut avoir tellement d'impacts que tout refaire reste moins cher ( je pense surtout au régression)
    Homer J. Simpson


  4. #4
    Expert éminent
    Citation Envoyé par Astraya Voir le message
    C'est surtout une question de combien sa coûte
    Le coût est je pense secondaire

    Ce que dit Joel Spolsky, c'est que le problème du refactoring c'est de ne pas rester coincé entre "1 vieux truc" et rien et attendre que le nouveau sorte.
    D'autant que les délais informatiques ne sont jamais précis/ toujours dépassés et comme tu le dis le temps de tester/ déboguer le nouveau, cela rajoute encore + de temps (<- qui peut prévoir le temps de maintenance à l'avance )

    Et donc 1 solution , c'est l'argent : soit de payer 1 grosse équipe pour mettre les bouchées doubles soit de maintenir 2 versions vieux/ nouveau (faire 1 fork) (<- c'est ce qu'à fait l'équipe Remesh)
    Si tu te demandes , 1 autre solution c'est de serrer les fesses et de prier le petit Jésus que tout se passe bien et vite (<- prendre sur soi)

  5. #5
    Membre habitué
    Le problème de la réécriture est qu'on perd souvent des fonctionnalités importantes pour les utilisateurs (et pas forcement très bien connu/documenté).

  6. #6
    Expert éminent sénior
    Citation Envoyé par Astraya Voir le message
    C'est surtout une question de combien sa coûte. Le refactoring peut avoir tellement d'impact que tout refaire reste moins cher ( je pense surtout au régression)
    D'accord sur le principe. C'est d'ailleurs le sens du billet de Joel Spolsky évoqué au début de l'article. Mais là, on est dans un cas différent : leur métier a tellement changé que les astuces métiers planquées dans le code sous forme de verrues n'ont plus vraiment de sens. Donc tout refaire coûte moins cher parce-qu’il s'agit de faire autre chose. C'est ce que dit axel584, aussi :

    Citation Envoyé par axel584 Voir le message
    Le problème de la réécriture est qu'on perd souvent des fonctionnalités importantes pour les utilisateurs (et pas forcement très bien connu/documenté).
    Si ton métier est toujours le même, alors je continue à penser que l'approche Joel Spolsky est la plus pertinente. J'ai fait 3 refontes complètes dans ma carrière, et à chaque fois, le métier restait à peu près le même - un refactoring complet était bien plus efficace que de repartir d'une feuille blanche. Mais eux ne sont pas dans ce cas là. J'a bien remplaçé certains programmes complets, voire des morceaux de chaine complets, mais en faisant toujours la quantité de tests automatiques nécéssaires pour garantir une isofonctionnalité totale.

    Remesh n'était pas du tout dans ce cas là. Quand tu as une base de code qui fait A et que tu vends B, ben, comment dire, refactoriser, c'est juste pérenniser ce dont tu n'as plus besoin.
    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.

  7. #7
    Membre actif
    Un inconvénient majeur de la réécriture c'est que pendant tout le temps qu'on réécrit, il n'y a pas d'ajout de nouvelle fonctionnalité.
    Et quand vous avez un gros logiciel, la réécriture peut-être trèèèès longue et ça à faire valider par le métier, c'est un autre combat...

  8. #8
    Membre régulier
    Ma boite a opté pour la troisième option : ne rien faire

  9. #9
    Expert éminent sénior
    Citation Envoyé par kbadache Voir le message
    Un inconvénient majeur de la réécriture c'est que pendant tout le temps qu'on réécrit, il n'y a pas d'ajout de nouvelle fonctionnalité.
    Et quand vous avez un gros logiciel, la réécriture peut-être trèèèès longue et ça à faire valider par le métier, c'est un autre combat...
    c'est bien pour cela que pour "faire du logiciel" il est préférable d'avoir les moyens en ressources humaines et financiers conséquents.
    Notamment comme les entreprises américaines en ont.
    Refactoriser tout un logiciel des entreprises comme Google,Microsoft, chez nous Dassault Systems peuvent le faire
    Pour la PME du coin c'est plus difficile.
    La théorie, c'est quand on sait tout et que rien ne fonctionne.
    La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.
    ( A Einstein)

  10. #10
    Membre éclairé
    Citation Envoyé par kbadache Voir le message
    Un inconvénient majeur de la réécriture c'est que pendant tout le temps qu'on réécrit, il n'y a pas d'ajout de nouvelle fonctionnalité.
    Et quand vous avez un gros logiciel, la réécriture peut-être trèèèès longue et ça à faire valider par le métier, c'est un autre combat...
    Hum, tout dépend de l'approche.

    Sachant qu'on ne réécrit/refactorise que dans le cas où le projet tourne (a donc un potentiel éprouvé) et donc que les moyens/investisseurs sont là...

    Je pense que l'idéal, pour l'entreprise, c'est de former une nouvelle équipe, qui ne fera que pondre une nouvelle solution, pour avoir un regard nouveau sur le projet, tout en partant des constats et expériences de l'équipe précédente.

    L'équipe précédent reste donc en place et maintient ce qu'elle connaît sur le bout des doigts et peut continuer de créer de nouvelles features, en attendant que le nouvel environnement soit au point.

    Une fois terminé, nul besoin de se séparer d'une équipe ou de l'autre, on détecte simplement, sur base de ce qui a été fait, les profils de R&D et les profils de production, pour en faire 2 pôles, afin d'éviter de revenir à la même situation.
    Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre code de carte bancaire

    Mon GitHub

    Une alternative à jQuery, Angular, Vue.js, React, ... ? Testez anticore, en quelques secondes à peine !
    (Contributions bienvenues)

  11. #11
    Membre éclairé
    Citation Envoyé par Astraya Voir le message
    C'est surtout une question de combien sa coûte. Le refactoring peut avoir tellement d'impact que tout refaire reste moins cher ( je pense surtout au régression)
    Comme toujours je pense que la réponse se situe plutôt autour de "ça dépend".

    Et pour répondre plus précisément, il faut faire une analyse risque/coût qui va faire pencher la balance d'un côté ou de l'autre :

    • Est-ce que l'on sait encore comment tourne chaque partie du logiciel précisément ?
    • Est ce qu'on a les compétences technique pour maintenir ou/et pour redévelopper avec les mêmes technos ou des plus récentes ?
    • Est-ce que l'on garde toutes les fonctionnalités ou est ce que certaines ne sont plus utilisés ?
    • Est-ce que l'on peut débloquer un budget ou il faudra plutôt compter sur un effort continue ?
    • Est ce que les technos sont anciennes et encore supportés ?
    • Est-ce que l'on sait déjà que certaines choses comme la sécurité, la prise en compte d'éléments tel que le RPGD ou autres laisse à désirer. Et quel serait la difficulté de les prendre en compte à un niveau acceptable.
    • Est ce qu'on peut donner une estimation grosses mailles de l'effort de refactoring vs l'effort de développement depuis le début.


    Liste non exhaustive

  12. #12
    Membre extrêmement actif
    Êtes-vous pour le refactoring de code ou la réécriture d'un projet de zéro ?
    A qui s'adresse cette magnifique question?

    Au développeur ou à celui qui le paye?

    L'un et l'autre auront évidemment une réponse différente!

  13. #13
    Membre expérimenté
    Refactoring
    - Ca limite les risques face a un réécriture complète ou l'on s'engage possiblement sur plusieurs années
    - Le techos moyen est bride, et c'est tant mieux car dans 6 mois il trouvera un autre prétexte pour refaire l'application et multiplier les coûts.
    - Les tests d’intégrations et de non régression sont plus faciles car comparables

    Réécrire l'app demande également de connaitre toutes les régles de gestions, et trop souvent celles-ci ne sont jamais formulées ailleurs que dans le code. Le dev est donc oblige de comprendre le code existant.

  14. #14
    Membre expérimenté
    Évolution progressive
    Il faut une évolution progressive pour de multiples raisons. Pour les utilisateurs mais aussi pour la stabilité du code et parce que tout réécrire c est souvent se tromper. Quand on écris du code parfois on pense que ca va être mieux mais souvent il y a des problèmes. Si tout est réécrit, il y a trop de problème et souvent c est l échec même si au forceps ça fini par passer.

    Cela ne ceux pas dire que parfois il ne faille pas réécrire une partie importante d un coup. Mais il vaut que cela reste une petite partie.

    L argument qu il serait plus économique de tout refaire est falacieux car il ne prends pas en compte les problèmes en prod le plus souvent.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  15. #15
    Membre expérimenté
    Citation Envoyé par Anselme45 Voir le message
    A qui s'adresse cette magnifique question?
    Au développeur ou à celui qui le paye?
    L'un et l'autre auront évidemment une réponse différente!
    Non je ne pense pas. L un veut minimiser les coûts l autre le temps passé, la prise de tête et les bugs en production. Ca revient au même a condition que le financier est une vision globale a long terme. Le mieux est un refactorindmg progressif.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  16. #16
    Expert éminent sénior
    Citation Envoyé par abriotde Voir le message
    L argument qu il serait plus économique de tout refaire est falacieux car il ne prends pas en compte les problèmes en prod le plus souvent.
    Toi t'as jamais repris le code d'un stagiaire.

    Tu lances, ça lance des erreurs, tu t'aperçois qu'il a tout codé ses chemins en dur, en chemin absolu... sauf que toi t'es pas sur son PC.

    Il a géré 2 langues... c'est un même dossier copié/collé avec le texte modifié (avec tout le code). Le code dans un foutoir pas possible, plein de code morts / inutiles. Franchement, j'ai pas cherché plus loin, et j'ai bien été content de ma décision.
    "Parce que le diable est dans les détails, une vision sans nuance ne peut prétendre à la compréhension du monde."

    Mon ancienne page perso : https://neckara.developpez.com/

  17. #17
    Membre expérimenté
    Le code d un stagiaire ne fait pas 100 000 lignes. Dans ce cas oui tu peux reprendre 1000 lignes. Mais parfois juste le modifier est plus simple.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  18. #18
    Expert éminent sénior
    Citation Envoyé par abriotde Voir le message
    Le code d un stagiaire ne fait pas 100 000 lignes.
    mmmmmmm... tu pourrais être surpris des fois.

    Après si son code de 100 000 lignes pouvaient être fait en uniquement 1 000.... c'est une autre question... et la réponse est oui.
    "Parce que le diable est dans les détails, une vision sans nuance ne peut prétendre à la compréhension du monde."

    Mon ancienne page perso : https://neckara.developpez.com/

  19. #19
    Responsable
    Office & Excel

    Ca me fait rire qu'on tape sur "le stagiaire"... Comme si il n'y avait que les stagiaires qui codaient mal...

    Un stagiaire, on l'épaule, on le forme, on vérifie son code, bref, on lui apprend son futur boulot. Si le stagiaire a pissé 100000 lignes, c'est que le gars qui le supervisait n'a pas fait son boulot. Peut-être qu'il aurait pondu les mêmes 100000 lignes...

    J'ai déjà dû me plonger dans du code "pissé" par un pro qui allait m'en apprendre, selon lui... J'ai refusé la mission de refactoring que l'on me proposait (lui n'avait "pas le temps" car il était appelé à de plus nobles fonctions) parce que cela sentait l'oignon. On est venu me rechercher, on a viré le spécialiste et je suis reparti de zéro...

    Donc, j'ai voté "Ca dépend du code à adapter"...
    "Plus les hommes seront éclairés, plus ils seront libres" (Voltaire)
    ---------------
    Mes remarques et critiques sont purement techniques. Ne les prenez jamais pour des attaques personnelles...
    Une fois pour toutes, je donne mon avis. Je ne vais pas le répéter à chaque message...
    Si je propose une solution générique sur votre solution spécifique, c'est parce que, fainéant de nature, je privilégie le réutilisable...
    Le VBA ne palliera jamais une mauvaise conception de classeur ou un manque de connaissances des outils natifs d'Excel...
    Ce ne sont pas des bonnes pratiques parce que ce sont les miennes, ce sont les miennes parce que ce sont des bonnes pratiques
    VBA pour Excel? Pensez D'ABORD en EXCEL avant de penser en VBA...
    ---------------

  20. #20
    Expert éminent sénior
    Citation Envoyé par Neckara Voir le message
    Toi t'as jamais repris le code d'un stagiaire.

    Tu lances, ça lance des erreurs, tu t'aperçois qu'il a tout codé ses chemins en dur, en chemin absolu... sauf que toi t'es pas sur son PC.

    Il a géré 2 langues... c'est un même dossier copié/collé avec le texte modifié (avec tout le code). Le code dans un foutoir pas possible, plein de code morts / inutiles. Franchement, j'ai pas cherché plus loin, et j'ai bien été content de ma décision.
    J'ai vu des gens avec 10 ans d'expérience ne pas coder aussi proprement que ça

    Citation Envoyé par abriotde Voir le message
    Le code d un stagiaire ne fait pas 100 000 lignes. Dans ce cas oui tu peux reprendre 1000 lignes. Mais parfois juste le modifier est plus simple.
    Citation Envoyé par Neckara Voir le message
    (.../...)si son code de 100 000 lignes pouvaient être fait en uniquement 1 000.... c'est une autre question... et la réponse est oui.
    Il fut une époque ou les développeurs étaient payés à la ligne de code. C'est depuis longtemps révolu, mais certains n'ont toujours pas reçu le message. Ou ne comprennent rien à ce qu'ils font, et ne fonctionnent que par copier-coller.

    Citation Envoyé par Pierre Fauconnier Voir le message
    J'ai déjà dû me plonger dans du code "pissé" par un pro qui allait m'en apprendre, selon lui... J'ai refusé la mission de refactoring que l'on me proposait (lui n'avait "pas le temps" car il était appelé à de plus nobles fonctions) parce que cela sentait l'oignon. On est venu me rechercher, on a viré le spécialiste et je suis reparti de zéro...

    Donc, j'ai voté "Ca dépend du code à adapter"...
    Je suis d'accord avec la conclusion. Il faut analyser la situation, et choisir en fonction. Mais le code n'est pas le seul élément à prendre en compte. La qualité de la doc et des specs aussi. Je suppose que tu avais sous la main des gens qui savaient ce qu'il fallait faire. Je n'ai pas toujours eu ce confort.

    Le pire code que j'ai eu à reprendre était un cas à part : il avait 36 ans d'âge, était du COBOL codé come si c'était de l'assembleur (alors que les bonnes pratiques de l'assembleur ne se prêtent pas du tout au COBOL), et surtout, il avait eu des centaines et des centaines de maintenances empilées. De la vraie archéologie logiciel. Le piège, c'est que les gens qui avaient écrit les spécifications étaient morts ou à la retraite, et qu'ils n'avaient laissé aucune trace écrite. La chaîne était une horreur à maintenir, mais tournait comme du papier à musique, et donnait entière satisfaction (à part de menus soucis de performances). Dans ces conditions précises, repartir de zéro était inconcevable - puisque la seul spec était le code existant. La seule page blanche, le module central qui pilotait tout ça, peut-être 4% de page blanche.

    J'ai pratiqué en deux phases. La première a consisté à ré-architecturer le tout pour éradiquer les doublons de code. Ca a aussi réduit le temps d'execution de 30%, sans même faire exprès. Ensuite, j'ai travaillé les algos, un par un, pour les rendre lisibles. Je n'ai fait que du nettoyage simple au sens de Joel Spolsky. 4 ans après, ils ont fait un calcul simple, l'ensemble leur a fait gagner plus d'un équivalent temps plein en maintenance. Pour 172 jours de boulot effectif(2/3 par moi, le reste par un collègue).

    Mais parfois on a des specs précises. un autre projet que j'ai fait était du genre "bon, il s'agit juste de transformer la sortie papier en sortie fichier plat que mangeront les gens du JAVA pour les afficher sur l'espace agent dans leur appli". Avec 17 pages de specs...et tout changeait subtilement par rapport à l'existant. La chaîne faisait 110 programmes (la plupart courts, mais quelques gros aussi). J'en ai gardé 4, dont 2 sévèrement tronçonnés. Tout le reste, mon collègue et moi avons refait de zéro (en simplifiant quand même, on est arrivé à une soixantaine de programmes). Les deux grosses différences? (1)on avait des specs complètes, et (2)l'existant ne répondait plus vraiment au besoin. Alors même que le code existant était bien plus civilisé, nous l'avons tronçonné de manière bien plus brutale que dans le cas précédent, parce-que nous pouvions nous le permettre, voir que c'était la chose à faire. 93% de page blanche environ.

    Donc voilà, les gens sérieux répondent "ça dépend", parce-que c'est effectivement le cas. Suivant la situation, l'une ou l'autre des méthodes sera à appliquer, plus ou moins partiellement. On est des ingénieurs, on est pas là pour appliquer des méthodes sans réfléchir, mais au contraire pour avoir le plus d'outils possibles dans notre boite à outils...et utiliser le bon outil dans la bonne situation. Je suppose que dans ton cas, le bon outil, c'était la page blanche (et les specs qui vont avec).
    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.