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

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

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

    20 26,67%
  • 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

    53 70,67%
  • 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,67%
  1. #21
    Membre à l'essai
    Inscrit en
    juillet 2008
    Messages
    3
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 3
    Points : 20
    Points
    20

    Par défaut 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
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    5 369
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 369
    Points : 23 771
    Points
    23 771

    Par défaut

    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
    Avatar de Glutinus
    Homme Profil pro
    Freelance EURL / Business Intelligence ETL
    Inscrit en
    avril 2005
    Messages
    4 560
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Freelance EURL / Business Intelligence ETL
    Secteur : Finance

    Informations forums :
    Inscription : avril 2005
    Messages : 4 560
    Points : 20 566
    Points
    20 566
    Billets dans le blog
    3

    Par défaut

    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 !!
    ****
    On dit "le jeu" / "un jeu" / "ce jeu", pourquoi mettre un x à ce mot au singulier ?
    ****
    "The longer he lived, the more he realized that nothing was simple and little was true" A clash of Kings, George R. R. Martin.

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 369
    Points : 23 771
    Points
    23 771

    Par défaut

    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
    Membre expert
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    801
    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 : 801
    Points : 3 513
    Points
    3 513

    Par défaut

    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
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    5 369
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 369
    Points : 23 771
    Points
    23 771

    Par défaut

    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 chevronné Avatar de ddoumeche
    Homme Profil pro
    Ingénieur recherche et développement
    Inscrit en
    octobre 2007
    Messages
    922
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Singapour

    Informations professionnelles :
    Activité : Ingénieur recherche et développement

    Informations forums :
    Inscription : octobre 2007
    Messages : 922
    Points : 2 000
    Points
    2 000

    Par défaut

    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.

  8. #28
    Membre averti
    Homme Profil pro
    Programmeur du dimanche
    Inscrit en
    août 2017
    Messages
    136
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Programmeur du dimanche
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2017
    Messages : 136
    Points : 449
    Points
    449

    Par défaut

    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 !"

  9. #29
    Membre extrêmement actif
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mars 2015
    Messages
    1 105
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2015
    Messages : 1 105
    Points : 2 632
    Points
    2 632

    Par défaut

    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 chevronné Avatar de ddoumeche
    Homme Profil pro
    Ingénieur recherche et développement
    Inscrit en
    octobre 2007
    Messages
    922
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Singapour

    Informations professionnelles :
    Activité : Ingénieur recherche et développement

    Informations forums :
    Inscription : octobre 2007
    Messages : 922
    Points : 2 000
    Points
    2 000

    Par défaut

    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é.

  11. #31
    Membre émérite
    Homme Profil pro
    Ingénieur Exploitation Mainframe
    Inscrit en
    octobre 2005
    Messages
    1 336
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Ingénieur Exploitation Mainframe
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 336
    Points : 2 749
    Points
    2 749

    Par défaut

    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 chevronné
    Avatar de badaze
    Homme Profil pro
    Chef de projets info
    Inscrit en
    septembre 2002
    Messages
    1 160
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets info
    Secteur : Transports

    Informations forums :
    Inscription : septembre 2002
    Messages : 1 160
    Points : 1 983
    Points
    1 983

    Par défaut

    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

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 700
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 700
    Points : 13 836
    Points
    13 836

    Par défaut

    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
    Et en rentrant dans un magasin de meubles, Protagoras se dit : "l'Homme est la juste mesure des chaises"

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

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

    Informations forums :
    Inscription : février 2010
    Messages : 1 576
    Points : 4 134
    Points
    4 134

    Par défaut

    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
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mars 2015
    Messages
    1 105
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mars 2015
    Messages : 1 105
    Points : 2 632
    Points
    2 632

    Par défaut

    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 chevronné
    Avatar de badaze
    Homme Profil pro
    Chef de projets info
    Inscrit en
    septembre 2002
    Messages
    1 160
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets info
    Secteur : Transports

    Informations forums :
    Inscription : septembre 2002
    Messages : 1 160
    Points : 1 983
    Points
    1 983

    Par défaut

    @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.

Discussions similaires

  1. Réponses: 3
    Dernier message: 18/12/2017, 16h43
  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, 18h30
  3. Réponses: 7
    Dernier message: 01/09/2009, 21h24
  4. Réponses: 2
    Dernier message: 13/07/2008, 15h57

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