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 :

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


Sujet :

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

  1. #21
    Membre du Club
    3 déformations qui ont la vie dure
    Tout ça vient de 3 déformations :

    - La croyance dur comme fer dans le "progressisme" : on fait toujours mieux qu'avant, et avant c'était nul. C'est surtout vrai en France depuis la révolution (= on efface tout et on recommence).

    - La fausse analogie qu'on établit entre bâtiment et SI. Détruire un vieux bâtiment délabré pour reconstruire est justifié. Mais un SI n'est pas un bâtiment !

    - Le sophisme qui consiste à dire: on fait de l'informatique, et l'informatique c'est technique, or la technique évolue très vite, donc il faut que nos SI suivent la technique à la même vitesse. Or on ne fait pas d'informatique, on fait des systèmes d'information.

  2. #22
    Expert éminent sénior
    Citation Envoyé par rheracles Voir le message
    (.../...)on ne fait pas d'informatique, on fait des systèmes d'information.
    we have a winner.



    Je ne suis pas totalement convaincu par tes deux premiers points, mais celui-là me parait particulièrement pertinent, et balaye tout le reste. enfin, en informatique de gestion, en tous cas. En jeu vidéo, ton raisonnement, il peut poser problème. Mais quand on a la compta d'une banque qui tourne comme du papier à musique depuis 45 ans, quel besoin de se dire "on fout tout à la poubelle pour paraitre moderne" ? Le système d'information est fonctionnel, il répond au besoin. basta.
    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.

  3. #23
    Expert éminent sénior
    Citation Envoyé par Blondelle Mélina
    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à.
    Vous jetez aussi des verrues écrites par des juniors à qui on a demandé l'impossible alors qu'ils sont pas formés.
    Vous jetez des rajouts demandés de type INSERT puis UPDATE UPDATE UPDATE UPDATE UPDATE x 1000
    Vous jetez du faux code développé par des charlatans facturés 1000€ la journée qui doivent bien justifier quelque chose.

    Il faut faire la part des choses, avec de l'expérience on se rend compte à la première vue qu'une cheville rajoutée est nécessaire (indice, un commentaire du développeur qui dit qu'il a passé 6 semaines à se casser les dents sur une ano pour finalement rajouter cette solution crade, en général j'y touche pas).

    En général, quand une société accepte une réécriture complète du code, c'est qu'il est trop tard, et que les solutions qui seront mises pour réindustrialiser seront minimes. Travaillé pour plusieurs éditeurs qui voulaient faire une refonte complète de leur produit. L'ancien code était une plaie. Les leçons ont été prises sur l'architecture et la modélisation. Et pourtant la nouvelle est pire, très souvent pour cause politique (freelances chafouins ayant fleuré le projet chaotique pour facturer comme des malades, embauches de junior à tout va, chefs de projet qui passe plus de temps à faire des réunions que chapeauter leur équipe, bref, vous connaissez tout cela).
    - So.... what exactly is preventing us from doing this?
    - Geometry.
    - Just ignore it !!
    ****
    "The longer he lived, the more he realized that nothing was simple and little was true" A clash of Kings, George R. R. Martin.
    ***
    Quand arrivera l'apocalypse, il restera deux types d'entreprise : les pompes funèbres et les cabinets d'audit. - zecreator, 21/05/2019

  4. #24
    Expert éminent sénior
    Fait rarissimme, je ne suis pas 100% d'accord avec toi.

    Citation Envoyé par Glutinus Voir le message
    Vous jetez aussi des verrues écrites par des juniors à qui on a demandé l'impossible alors qu'ils sont pas formés.
    Vous jetez des rajouts demandés de type INSERT puis UPDATE UPDATE UPDATE UPDATE UPDATE x 1000
    Vous jetez du faux code développé par des charlatans facturés 1000€ la journée qui doivent bien justifier quelque chose.
    Je vais essayer de te faire prendre un autre point de vue : ce n'est pas parce que c'est techniquement atroce que c'est fonctionellement inutile. Exemple vécu de boucle avant et après refactorisation :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    A121.
        MOVE 1 TO II.
        MOVE 0 TO YY.
    A120.
        ADD ZZ(II) TO YY.
        ADD 1 TO II
        IF II > TT GO TO A139.
        GO TO A 121.
    A139.
        EXIT.
    refait correctement(bon, j'ai été bourrin en donnant un no signifiant à l'index, suivant les sites, ça sera encouragé ou découragé)(a noter aussi qu'il n'y a pas de passage de paramètres en cobol, donc la portée des données est niveau programme, pas niveau procédure - donc les variables que j'utilise ont été définies ailleures et passent par globalité - un de mes rares reproches au COBOL, mais un costaud) :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    CALCUL-TAXE-ASSURANCE.
        MOVE ZERO TO TOTAL-TAXE
        PERFORM VARYING POSITION-ELEMENT FROM 1 BY 1 UNTIL POSITION-ELEMENT > TOTAL-ELEMENTS-TAXE
            ADD ELEMENT-TAXE (POSITION-ELEMENT) TO TOTAL-TAXE
        END-PERFORM
        .
    Le code initial ne respecte rien, pas même la logique élémentaire dans le nommage des labels de destination des GO TO. Pourtant, il fait une tâche essentielle, à savoir cumuler les différents éléments comptables qui composent la taxe d'assurance(le vrai algo était bien plus relou, mais j'ai simplifié pour l'exemple. De toutes façons, j'ai oublié les détails).

    Le code final respecte à peu près tout les éléments qui faisaient un code COBOL propre il y a 10 ans(il y a peut-être eu des progrès depuis, et certains détails varient d'une boite à l'autre, comme le nommage des index ou la présence-absence d'un label de fin de paragraphe.). Il n'invente strictement rien au niveau fonctionnel, il se contente d'amener visuellement au mainteneur tout ce dont il a besoin pour comprendre rapidement ce qui se passe sur ce bout de code.

    les update horribles de tes escrocs sont peut-être des crimes contre l'humanité, mais ils ont été faits dans un but précis. Tout refaire autrement, soit, mais être bien sur de ne rien oublier.

    Citation Envoyé par Glutinus Voir le message
    Il faut faire la part des choses, avec de l'expérience on se rend compte à la première vue qu'une cheville rajoutée est nécessaire (indice, un commentaire du développeur qui dit qu'il a passé 6 semaines à se casser les dents sur une ano pour finalement rajouter cette solution crade, en général j'y touche pas).
    Mais les sagouins qui ont fait sans talent du cobol à la façon assembleur sale en 1972 n'avaient laissé aucun indice de ce genre. Pourtant, leur horreur tournait, et donnait des résultats fonctionellement justes. Il me fallait reprendre leur savoir fonctionnel, à la virgule près, tout en me débarrassant de leurs obsolescences vomitoires techniques. Le test a évidemment été essentiel. Il fallait comparer les résultats(je ne me suis pas fait chier, je passais un mois complet de production, avec 300,000 avis générés, ça permet de couvrir à peu près tous les cas).

    Citation Envoyé par Glutinus Voir le message
    En général, quand une société accepte une réécriture complète du code, c'est qu'il est trop tard, et que les solutions qui seront mises pour réindustrialiser seront minimes. Travaillé pour plusieurs éditeurs qui voulaient faire une refonte complète de leur produit. L'ancien code était une plaie. Les leçons ont été prises sur l'architecture et la modélisation. Et pourtant la nouvelle est pire, très souvent pour cause politique (freelances chafouins ayant fleuré le projet chaotique pour facturer comme des malades, embauches de junior à tout va, chefs de projet qui passe plus de temps à faire des réunions que chapeauter leur équipe, bref, vous connaissez tout cela).
    Mais ça, ce n'est pas lié à la discipline de la refonte. C'est lié au fait qu'on manque de gens talentueux à tous les niveaux(je ne m'appesantirais pas sur les causes, je n'ai pas la vérité absolue à ce sujet). Moi, j'ai mené plusieurs refontes complètes dans ma carrière, même si je cite toujours la même (la plus violente et la plus spectaculaire). Avec succès. Seul, ou en équipe. Avec l'aide du management, ou contre lui. Des gens de qualité en projet "feuille blanche" auront le même palmarès que moi, et des gnous auront le même taux de succès que ceux que tu as subi sur les refontes.

    Ce putain de code avait 36 ans. Ca faisait plus de 10 ans que les internes faisaient des pieds et des mains pour avoir le budget de la refonte, et que la direction les envoyait chier. Ils l'ont fait passer au prétexte d'un changement de format de sortie(au lieu de faire les impressions en mode texte, on envoyait désormais les données fonctionnelles à des moulinettes pour présentation moderne), et dit "ce n'est pas possible sans une refonte complète" (ils avaient raison, mais ils ne le savaient pas, ils ont juste sauté sur l'occasion avant même de faire l'analyse). Une fois le budget débloqué, aucun d'entre eux n'a voulu prendre le bébé, et j'ai débarqué avec un collègue. On a fait le boulot. On s'est cassés(et la chef a récolté tous les lauriers). Ils ont estimé, au bout de 4 ans, le gain en termes de maintenances à 1,2 équivalent temps plein.

    Donc ça peut marcher. Mais il faut trouver les bonnes personnes sur le marché. Et pour ça, il faut qu'elles y soient. Je n'y suis plus, et mon collègue non plus, ça fait déjà deux de moins. On peut avoir de la chance avec les petits jeunes, mais c'est toujours un risque.
    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.

  5. #25
    Expert confirmé
    Citation Envoyé par el_slapper Voir le message
    a noter aussi qu'il n'y a pas de passage de paramètres en cobol, donc la portée des données est niveau programme, pas niveau procédure - donc les variables que j'utilise ont été définies ailleures et passent par globalité - un de mes rares reproches au COBOL, mais un costaud
    Je n'y connais rien en COBOL, mais j'ai lu sur Wikipédia que, depuis COBOL 2002, on a les fonctions définies par l'utilisateur et on peut même faire de la programmation orientée objet. Si c'est vrai, alors cela devrait permettre d'améliorer significativement l'architecture du nouveau code.

    L'orienté objet, comme d'autres paradigmes de haut niveau, permet de faire de l'inversion de dépendance, ce qui permet de découper davantage le code en briques réutilisables. Par exemple, l'inversion de dépendance permet de mettre en place des mocks qui facilitent les tests unitaires.

  6. #26
    Expert éminent sénior
    Citation Envoyé par Pyramidev Voir le message
    Je n'y connais rien en COBOL, mais j'ai lu sur Wikipédia que, depuis COBOL 2002, on a les fonctions définies par l'utilisateur et on peut même faire de la programmation orientée objet. Si c'est vrai, alors cela devrait permettre d'améliorer significativement l'architecture du nouveau code.
    C'est vrai, mais c'est méga lourdingue, et ça ne vaut le coup que pour de très gros trucs. Faire 20 lignes de plomberie pour une fonction de 3 lignes, buerk. On est pas en LISP. Je préfèrais encore faire des modules séparés pour des gros codes répétables, comme ça on pouvait les réutiliser le cas échéant. Pour les petits trucs, une bête procédure avec juste un label(appelé proprement et pas par GO TO, évidemment) et des données malheureusement pas encapsulées, ça reste le meilleur compromis, et de loin. Évidemment, dans d'autres langages, il faut faire de manière plus traditionnelle(i.e. ne pas hésiter à faire des routines locales paramétrisées très courtes en grand nombre).

    Citation Envoyé par Pyramidev Voir le message
    L'orienté objet, comme d'autres paradigmes de haut niveau, permet de faire de l'inversion de dépendance, ce qui permet de découper davantage le code en briques réutilisables. Par exemple, l'inversion de dépendance permet de mettre en place des mocks qui facilitent les tests unitaires.
    La programmation orientée objet en COBOL, c'est encore pire. Je n'ai jamais réussi à en compiler. Et de toutes façons, les exemples que j'ai lu, c'est dans les 50 lignes de plomberie juste pour faire une classe avec une propriété.....

    Le truc aussi, c'est que la plupart des cobolistes ne sont pas de vrais informaticiens. J'ai bouffé beaucoup de théorie en ces lieux, mais la plupart des autres cobolistes non. Avec les années, il y a eu un écrémage terrible, et ne restent souvent que les meilleurs. Mais les meilleur avec la boite à outil de COBOL 77, pas 2002. Qui font des trucs hyper propres, avec les moyens de l'époque. "l'inversion de dépendance permet de mettre en place les mock", c'est typiquement le genre de phrase qui te met tous les cobolistes à dos. Je ne dis pas que tu as tort, je dis que dans ce monde-là, cette manière de penser ne passe pas. Et ça ne fait pas de mes ex-collègues des mauvais, loin s'en faut. Simplement, ils utilisent des outils plus anciens, qui ont fait leurs preuves, et vont éviter des surcouches de complexité.

    La vraie raison d'être de la surcouche objet en COBOL, c'est de pouvoir être appellé plus facilement par du JAVA, dans des architectures ou le JAVA fait toute l'interface(et, de plus en plus souvent, les couches intermédiaires), mais ou le COBOL reste maitre sur les couches basses d'accès aux données. Dans ce cas, on fait juste un objet chapeau, le reste ont le fait à l'ancienne. Parcequ'au vu des qualités, et aussi des défauts du COBOL(et aussi vu la sociologie des gens qui en font), multiplier les classes, c'est du suicide.

    Je viens de coder un petit truc dans mon boulot actuel dans un langage objet(un truc maison, je passe les détails). Une injection de fichier. J'ai fait 8 classes. En COBOL, c'eut été aberrant. J'aurais fait un programme principal, avec quelques sous-modules, et surtout pas de classes. Les manières de penser qui conviennent bien sur des langages type JAVA(et notre langage maison ressemble beaucoup) ne conviennent pas du tout au COBOL, et vice versa. C'est aussi pour ça que les reconversions des cobolistes se passent généralement très mal. Les formateurs connaissent parfaitement JAVA, et n'ont que mépris pour "ce langage de merde" (sans lequel ils ne seraient pas payés, ni personne d'autre), et inondent de grands professionnels, des gens qui ont fait leurs preuves dans des conditions difficilles, de théories qui ne leurs parlent pas.

    Si tu donnes à ces gens-là la définition classique de la classe "En programmation orientée objet, la déclaration d'une classe regroupe des membres, méthodes et propriétés (attributs) communs à un ensemble d'objets. La classe déclare, d'une part, des attributs représentant l'état des objets et, d'autre part, des méthodes représentant leur comportement. Une classe représente donc une catégorie d'objets. Elle apparaît aussi comme un moule ou une usine à partir de laquelle il est possible de créer des objets ; c'est en quelque sorte une « boîte à outils » qui permet de fabriquer un objet. On parle alors d'un objet en tant qu'instance d'une classe (création d'un objet ayant les propriétés de la classe)." , tu les a perdus irrémédiablement.

    Si tu leur parle leur langage, à savoir, "une classe, c'est une COPY de données, et les propriétés qui vont sur les données, des niveaux 88 sous stéroïdes, programmables", là, tu vas pouvoir les convaincre. Mais personne ne fait ça. Tu n'as pas fait ça. Moi, je suis entre deux, donc je vois parfaitement ou tu veux en venir. Mais par pitié, ne leur parle jamais comme ça.
    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. #27
    Membre extrêmement actif
    En entreprise, on passe son temps a refaire du code développé en externe ou par des stagiaires ou pire encore, du code que l'on a écrit il y a deux ans en entrant dans la boite.

    Refactoriser des blocks entiers de l'application pour éliminer les redondances, améliorer les performances, virer des dépendances vers des librairies fumeuses, faire de la place pour introduire de nouvelles fonctionnalités, est le quotidien des développeurs en entreprise. Refactoriser coûte à peine la fraction du coût de développement d'un soft complet.

    On ne devrait probablement jamais réécrire une application à partir de 0 sauf si
    1/ le coût est négligeable
    2/ la technologie est obsolète ou a atteint ses limites (exemple Twitter réécrivant son backend de ruby ou python en Java ou Scala mais en tout cas passant sur la JVM)
    3/ personne n'est capable de maintenir l'application sans sa forme actuelle, que cela soit à cause des limites du langage ou de la mauvaise architecture du système (cas le plus rare)

    Evidemment ce paradigme peut ne pas plaire aux SSII qui besoin de vendre de la presta par container entier, et qui donc vont tout faire pour envoyer un consultant faire son audit et annoncer que le code existant est trop vieux pour être maintenu.
    Pensez donc, il n'est pas écrit dans le langage hype du jour (qui sera obsolète dans 2 ans), et n'utilise pas le dernier design pattern machin (que le client final ne voit jamais). Heureusement la SSII en question a justement une armée de jeunes développeurs (pas chers) formés (la veille) sur cette technologie et expert (car jeunes).

    Ou alors ce sera le nouvel architecte/urbaniste/CEO qui veut tout casser pour faire une grosse refonte de tout l'existant. Forcément meilleure puisque c'est la sienne et que toute façon il est plus commode d'imaginer ce que sera l'avenir que de comprendre ce qu'est l'existant.

    Or sachant que 75% des projets informatiques échouent et continue d'échouer, la refactorisation apparait donc comme un choix beaucoup plus sur.

    D'ailleurs au final, quand je compare Netscape 4 avec ses successeurs, il n'y a pas photo : il était infiniment supérieur.
    La joie de l'âme est dans la planification -- Louis Hubert Liautey

  8. #28
    Membre éclairé
    Cela se passe dans l'entreprise que vous voulez. Une équipe nouvellement recrutée reprend un projet :

    "On a du tout refaire de zéro parce que le code était affreusement mal écrit."

    Quelques années plus tard, une autre nouvelle équipe reprend le projet à son tour :

    "On a du tout refaire de zéro parce que le code était affreusement mal écrit."

    L'employeur :

    "Putain mais virez-moi tous ces nuls !"
    Sur Youtube je suis "Le prof des cavernes"
    https://www.youtube.com/channel/UCSz...bYl_pSNMv_zerQ

  9. #29
    Membre extrêmement actif
    Citation Envoyé par ddoumeche Voir le message
    On ne devrait probablement jamais réécrire une application à partir de 0 sauf si
    1/ le coût est négligeable
    2/ la technologie est obsolète ou a atteint ses limites (exemple Twitter réécrivant son backend de ruby ou python en Java ou Scala mais en tout cas passant sur la JVM)
    3/ personne n'est capable de maintenir l'application sans sa forme actuelle, que cela soit à cause des limites du langage ou de la mauvaise architecture du système (cas le plus rare)
    Je ne sais pas si c'est si rare que ça. Des architectures monolithiques, qui ont grossi, grossi au fil des ans sans fil directeur, sans normes de développement, sans relecture de code, pas ou très peu de tests unitaires, pas ou très peu de documentation, des centaines de milliers de lignes de procédures stockées en PL/SQL que, parfois, personne ne comprends réellement, la connaissance métier qui s'évanouit avec le départ du presta. Tout ça, c'est un peu notre quotidien à tous, non ?

    Alors le besoin de repartir sur des bases propres, sur une architecture saine, maintenable, scalable, se conçoit.

    Le problème c'est qu'en pratique... combien de projets de refonte globale reproduisent les erreurs de l'existant, tout en ajoutant leurs propres erreurs de conception ?
    "If the revolution ain't gon' be televised
    Then fuck, I'll probably miss it" - Aesop Rock

  10. #30
    Membre extrêmement actif
    Citation Envoyé par Grogro Voir le message
    Je ne sais pas si c'est si rare que ça. Des architectures monolithiques, qui ont grossi, grossi au fil des ans sans fil directeur, sans normes de développement, sans relecture de code, pas ou très peu de tests unitaires, pas ou très peu de documentation, des centaines de milliers de lignes de procédures stockées en PL/SQL que, parfois, personne ne comprends réellement, la connaissance métier qui s'évanouit avec le départ du presta. Tout ça, c'est un peu notre quotidien à tous, non ?
    Non... car on ne fait pas beaucoup appel aux prestas

    Enfin nuançons, je n'ai pas la (mal)chance de faire du PL/SQL, même si SQL Server étant + ou - isofonctionnel, on peut aussi faire beaucoup de merde avec. Et j'en vois donc passer souvent, ce qui est inévitable avec un langage de script, donc sans versioning, compilation, typage "dynamique", tests unitaires et j'en passe.
    Pour d'autres projets, on fait au contraire le maximum de traitement coté business, quitte à ce que cela soit légèrement plus lent : rajouter des serveurs d'application n'est ni compliqué ni cher, alors la base de donnée n'est pas aussi scalable. Par contre, elle est versionnée.

    C'est pour cela que l'urbanisation est un challenge, et qu'on doit former des architectes, des dba, enseigner Merise.
    Et non pas faire de l'Agile sans plan d'architecture ou spécifications techniques voir fonctionnelles.

    D'ailleurs, la relecture de code est le boulot du chef d'équipe et de l'architecte, et si le code n'est pas documenté le presta n'est pas payé. On utilise souvent javadoc + un bête wiki pour la documentation, avant d'exporter cela dans un beau document tout propre grâce à un script fait par le devops

    Citation Envoyé par Grogro Voir le message
    Alors le besoin de repartir sur des bases propres, sur une architecture saine, maintenable, scalable, se conçoit.
    Oui, c'est le cas n°2 & 3 : technologie vieillissante (oracle) et difficile à maintenir, mauvaise réalisation. Est-ce une mauvaise architecture pour autant ?

    Mais on est pas obligé de refaire tout d'un coup, un système qui a pris 10 ans développement peux être refait par blocs, ou par district, ou par périmètre. Par exemple, juste l'IHM voir des bouts de l'IHM vu que tout est accessible par URL de nos jours. Ou juste des parties précises du backend. On a ainsi des projets sortant des livrables régulièrement et pouvant donc mieux survivre au départ d'un responsable.

    Quand Haussman refait Paris, il ne rase pas la ville, il procède par arrondissements même si cela prend 30 ans.

    Et puis on peut imaginer des passerelles : Par exemple, là lancer un crash program pour faire tourner du code Javascript dans nos serveurs Java via le runtime V8 de google. Cela marche plutôt bien, et résout les problèmes de Node.js à savoir le monoThreading, le rechargement des classes, la sécurité (nodejs donne accès à tout le filesystem), bref presque tout.

    En plus de donner accès (en théorie) à une grosse partie de notre API java aux développeurs Javascript, donc pas besoin de réécrire de SQL, HSQL ou PL/SQL.

    On pourra même déboguer expérimentalement le code javascript coté serveur dans Chrome .. ou dans Eclipse. Et à mon avis, c'est adaptable dans d'autres type de solution ou de projets.

    Bref, je suis sur que chacun d'entre nous face à son vieux SI est capable d'amélioration continue. Et donc de tirer les enseignements des erreurs du passé.

    Citation Envoyé par Grogro Voir le message
    Le problème c'est qu'en pratique... combien de projets de refonte globale reproduisent les erreurs de l'existant, tout en ajoutant leurs propres erreurs de conception ?
    Un projet sans bug, c'est un projet inutilisé.
    La joie de l'âme est dans la planification -- Louis Hubert Liautey

  11. #31
    Membre expert
    Citation Envoyé par el_slapper Voir le message
    ... Exemple vécu de boucle avant et après refactorisation :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    A121.
        MOVE 1 TO II.
        MOVE 0 TO YY.
    A120.
        ADD ZZ(II) TO YY.
        ADD 1 TO II
        IF II > TT GO TO A139.
        GO TO A 121.
    A139.
        EXIT.

    ... ce bout de code COBOL est non seulement " vieillot " mais en plus j'ai l'impression qu'il est faux ... ne serait ce pas plutôt ?

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    A121.
        MOVE 1 TO II.
        MOVE 0 TO YY.
    A120.
        ADD ZZ(II) TO YY.
        ADD 1 TO II
        IF II > TT GO TO A139.
        GO TO A120.
    A139.
        EXIT.

  12. #32
    Membre émérite
    Déjà on ne touche pas quelque chose qui fonctionne et donne satisfaction sans bonne raison. Par exemple j’ai écrit des programmes de facturation sur AS400 dans les années 90 et qui sont encore utilisés en 2018 bien que j’aie quitté la boîte il y a 15 ans et qu’il n’y ait plus de maintenance depuis des années.


    Dans ma carrière il m’est arrivé de devoir reprendre des développements faits par d’autres et pleins de bogues.
    Dans les cas où je ne connaissais pas spécialement le domaine fonctionnel je reprenais le code et essayais de le corriger et le plus marrant c’est que souvent la correction d’un bogue en débloquait d’autres qui n’étaient jamais apparus puisque masqués par le bogue inital !
    Par contre dans les cas où je connaissais le fonctionnel il m’est arrivé plus d’une fois de tout réécrire du moment que même le cas de test le plus simple ne fonctionnait pas ou bien parce que c’était tout bonnement très mal écrit et inmaintenable. Tant qu’à être responsable au final autant que ce soit avec son propre code ! Parce qu’il ne faut pas se leurrer du moment qu’on a mis un ongle dedans on devient le responsable surtout si c’est une partie critique.


    Comment vois-je que le code est mal écrit ? Tout simplement parce que le code n’est pas beau ! La beauté est subjective me direz-vous. Mais tout au long de ces années j’ai remarqué que le code qui est bien proportionné doté d’une certaine symétrie est moins sujet aux bogues et est plus facilement maintenable et évolutif qu’un code asymétrique qui part dans tous les sens. Car s’il est asymétrique c’est qu’il y a sûrement un cas fonctionnel qui n’a pas été traité.

    Cela ne sert à rien d'optimiser quelque chose qui ne fonctionne pas.

    Mon site : www.emmella.fr

    Je recherche le manuel de l'Olivetti Logos 80B.

  13. #33
    Expert éminent sénior
    Citation Envoyé par wolinn Voir le message
    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.
    ce n'est pas qu'un problème décisionnel c'est surtout un problème de financement oui !
    Ré-écrire un projet c'est tout un budget tout un investissement bien souvent il faut réecrire la doc technique et fonctionnelle.
    En plus c'est mettre des développeurs et architectes,analystes sur un projet x heures par jour donc tout cela coûte de l'argent
    Citation Envoyé par badaze Voir le message
    Déjà on ne touche pas quelque chose qui fonctionne et donne satisfaction sans bonne raison.
    c'est exact c'une des règles numéro un dans l'économie,la production et l'industrie.
    Cependant avec les évolutions de la technologie, les éditeurs de solutions poussent les utilisateurs de systèmes informatiques ( bref les entreprises ) à refaire les projets informatiques.
    Ce qui coûte de l'argent encore une fois
    Citation Envoyé par badaze Voir le message
    Comment vois-je que le code est mal écrit ? Tout simplement parce que le code n’est pas beau ! La beauté est subjective me direz-vous.
    ok mais du code informatique n'a tout de même pas vocation à ressembler à la Venus de Botticelli tout de même
    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)

  14. #34
    Expert confirmé
    Citation Envoyé par Mat.M Voir le message
    ok mais du code informatique n'a tout de même pas vocation à ressembler à la Venus de Botticelli tout de même
    Quel manque de sens artistique.

    Pour le moment pas eu besoin de réécrire tout de zéro, on réutilise, on modifie l'existant et on prévoit de migrer une partie du soft l'an prochain car le matériel qui devient obsolète.
    Et ça ne sera pas du luxe car je trouve qu'on s'approche un peu trop des limites du hardware.
    http://www.traducteur-sms.com/ On ne sait jamais quand il va servir, donc il faut toujours le garder sous la main

  15. #35
    Membre extrêmement actif
    Citation Envoyé par badaze Voir le message
    Comment vois-je que le code est mal écrit ? Tout simplement parce que le code n’est pas beau ! La beauté est subjective me direz-vous. Mais tout au long de ces années j’ai remarqué que le code qui est bien proportionné doté d’une certaine symétrie est moins sujet aux bogues et est plus facilement maintenable et évolutif qu’un code asymétrique qui part dans tous les sens. Car s’il est asymétrique c’est qu’il y a sûrement un cas fonctionnel qui n’a pas été traité.
    Qu'est-ce qu'un code "symétrique et bien proportionné" ?
    "If the revolution ain't gon' be televised
    Then fuck, I'll probably miss it" - Aesop Rock

  16. #36
    Membre émérite
    @Grogro

    J'ai énormément de mal à formaliser cette notion. C'est plus une impression comme quand on regarde une peinture dans sa globalité sans se focaliser sur les détails. Il y a une harmonie dans la structure comme une sinusoïdale, c'est apaisant. A contrario un source mal écrit part dans tous les sens.

    Ca m'est arrivé de reprendre un algorithme que j'étais en train d'écrire et qui (j'en suis sûr) aurait fonctionné seulement parce qu'il ne répondait pas à ce canon de beauté.
    Cela ne sert à rien d'optimiser quelque chose qui ne fonctionne pas.

    Mon site : www.emmella.fr

    Je recherche le manuel de l'Olivetti Logos 80B.

  17. #37
    Nouveau Candidat au Club
    Mouais…
    Je tombe par hasard sur cet article en cherchant totalement autre chose.

    L'argument pour dire de ne pas reprendre à zéro serait donc, que l'accumulation de code est également une accumulation d'expérience sur le code… ?
    Sauf que « l'expérience » impliquerait que le code ait été proprement fait (sans jamais aucune précipitation héhé), correctement commenté pour expliquer pourquoi telle ou telle chose a été faite (notamment sur les points qu'un développeur passant par là pourrait juger aberrant sans savoir), que la documentation (à laquelle beaucoup de développeur sont allergiques et cherchent souvent des excuses pour ne pas s'en occuper *triste*) est tenue à jour et qu'on peut s'y fier, etc…

    La réalité est qu'un projet qui n'a subit AUCUNE maintenance depuis un certains temps et qui n'a plus aucun collaborateur historique pour passer le savoir devient une couche sédimentaire qu'on ne peut plus faire évoluer et qui devient potentiellement une faille de sécurité monstrueuse. Le principe de l'amélioration continue d'un programme ne peut s'appliquer que si le projet n'a pas connu d'interruption sévère. Dès lors malheureusement, quand un product owner a perdu la maîtrise de son code, et qu'il souhaite évoluer, il n'y a souvent pas d'autre choix que de repartir de zéro…

    Non pas que ça soit nécessairement un plaisir pour le développeur qui s'y atèle.

    My two cents…

  18. #38
    Expert éminent sénior
    Pour répondre à el_slapper sur sa réponse vieille de deux ans, mais dont je me souviens un peu, la lecture fait partie de la maintenabilité du code, évidemment. Je n'ai rien contre un code un peu pourrave, pour peu qu'il est lisible et propre un minima. Mon credo serait un peu "First, make it work ; then, make it readable ; finally, make it quick". Parce que malgré toutes les pierres qu'on pourrait jeter aux gens, le but c'est quand même d'avoir des prémices de résultat...
    Après c'est tout un jugement de penser : ce que je fais est-il maintenable ?

    Evidemment que ton premier code est plus lisible, maintenant si le second faisait l'affaire il avait raison de rester là... sauf si bien sûr de nouvelles priorités apparaissent (comme par exemple un temps de traitement) prenait les devants.

    Pour répondre à la question de l'INSERT + UPDATE + UPDATE + UPDATE, qui est ce que j'ai subi chez un client, cela répondait à moitié à une demande utilisateur. Il y avait un "pas de commit", c'est à dire un commit tous les 10.000 insertions (donc du PL/SQL) pour que le client ait quand même une partie des données même si ça plantait. Quand j'ai vu ça, première question à la chef de projet : est-ce le besoin ? Sa réponse : Oui. Donc je n'ai pas touché à ce concept.
    Le problème est que toute évolution sous forme de nouvelle colonne, si j'en crois les cartouches de commentaires (le seul truc qui était vraiment bien fait chez ce client), a été faite par le même développeur qui a fait l'évolution en système source, avec comme consigne, quick and dirty. Il a donc copié-collé le code, transformé l'insert en update.
    Problème 1 : il y a donc un million instructions UPDATE, autant que de clés, multiplié par le nombre de colonnes rajoutées.
    Problème 2 : le temps de traitement de l'ensemble de l'Infocentre dépassa allègrement les 24h, provoquant le courroux des clients qui, pour une raison obscure, trouvent que le reporting est désormais inutilisable.

    Cela demanda évidemment un nouvel entretien client, du haut des mes un an d'expérience et de mon menton imberbe (< métaphore du jeune développeur) :
    Est-ce que le passage en moins de 24h est critique : réponse oui.
    Voulez-vous garder ce système de "si ça plante, je veux quand même les données jusque là". Réponse : oui.
    Voulez-vous que je réécrive le code avec un seul INSERT en jointure, avec recette en TNR et temps de traitement réduit : m'en fiche, c'est vous l'expert.

    (A noter que mon client pour qui j'étais presta, éditeur, est étonnamment contre toute forme de travail non facturée au client, donc le plus gros de mon travail est de négocier ce temps de correction que j'imputais évidemment sur de l'anomalie bloquante, puisque c'est moins fatigant pour lui que de négocier avec ses propres clients).

    Résultat : beaucoup moins de temps de traitement, avec une fragilité robustesse identique au différent (taux d'échec de chargement, dû généralement à l'ETL merdique qui nous donnait aucune log du plantage).

    Bon derrière tout ce charabia technique qui ne passionne que qui voudra (et étant donné que ça a plus de dix ans et que j'étais jeune, est tout à fait critiquable et débattable, et ce même entre mon moi 2020 et mon moi 2006), la performance a été corrigée, les résultats sont les mêmes, la robustesse identique, et AMHA était un peu plus lisible.

    Dans un monde idéal évidemment, on travaille sous forme d'audit pour identifier les pieds d'argile du code et prioriser les besoins clients, ce qui est selon moi de plus en plus difficile aujourd'hui car on ne les accompagne plus du tout dans ce genre de travail (ie on supprime beaucoup de poste de ces parasites de Business Analyst, malheureusement les bons qui savent travailler et qui font parfaitement l'interface-tampon entre technique et utilisateurs en pâtissent grave).
    - So.... what exactly is preventing us from doing this?
    - Geometry.
    - Just ignore it !!
    ****
    "The longer he lived, the more he realized that nothing was simple and little was true" A clash of Kings, George R. R. Martin.
    ***
    Quand arrivera l'apocalypse, il restera deux types d'entreprise : les pompes funèbres et les cabinets d'audit. - zecreator, 21/05/2019

  19. #39
    Expert éminent sénior
    Citation Envoyé par badaze Voir le message
    C'est plus une impression comme quand on regarde une peinture dans sa globalité sans se focaliser sur les détails. Il y a une harmonie dans la structure comme une sinusoïdale, c'est apaisant. A contrario un source mal écrit part dans tous les sens.
    +1 bien vu.
    C'est à quoi sert la compression jpeg puisque le principe c'est la transformée en cosinus discret.

    Maintenant que la vérité du monde réside dans les décimales de Pi 3.14 comme le suggèrait Pythagore je vous laisse débattre dessus
    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)

  20. #40
    Membre chevronné
    Cela me rassure de lire que personne n'a choisi l'option "Je refuse de travailler sur un autre code que ceux que j'ai créés de A à Z".
    Alexandre Tranchant
    Chef de projet MOA pour le Cerema.
    Modélisation des déplacements, système d'aides à la gestion du trafic, ITS (Intelligent Transport Services)