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

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

Affichage des résultats du sondage: Quelle stratégie préférez-vous adopter ?

Votants
73. Vous ne pouvez pas participer à ce sondage.
  • Ça dépend de la qualité du code à faire évoluer, je peux le garder ou le supprimer

    53 72,60%
  • J'essaie de comprendre le code puis je le fais évoluer

    14 19,18%
  • Je préfère repartir de zéro

    11 15,07%
  • Ça dépend de la techno utilisée et des besoins actuels des clients

    20 27,40%
  • Je n'ai pas d'avis sur la question

    2 2,74%
Sondage à choix multiple
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. #21
    Membre extrêmement actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2017
    Messages
    844
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : octobre 2017
    Messages : 844
    Points : 3 099
    Points
    3 099
    Par défaut
    Citation Envoyé par abriotde Voir le message
    Ca revient au même a condition que le financier est une vision globale a long terme.
    Un financier qui a une vision globale à long terme??????????????

    Il faudrait voir pour revenir sur terre!

    Dans ce bas monde, il y a autant de "financier avec une vision à long terme" que de poule avec des dents!

  2. #22
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    7 359
    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 : 7 359
    Points : 16 971
    Points
    16 971
    Par défaut
    je suis bien d'accord avec toutes les réponses précédentes mais au fait le refactoring ça consiste en quoi ?
    Avec un langage objet, à recréer tout un ensemble de classe qui héritent les uns des autres et aussi avec des classes abstraites ?
    Bref à être à fond dans le paradigme objet?
    Qu'est ce qui est petit et marron ? Un marron ( Kaamelott)

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 451
    Points : 30 181
    Points
    30 181
    Par défaut
    Citation Envoyé par Mat.M Voir le message
    je suis bien d'accord avec toutes les réponses précédentes mais au fait le refactoring ça consiste en quoi ?
    Avec un langage objet, à recréer tout un ensemble de classe qui héritent les uns des autres et aussi avec des classes abstraites ?
    Bref à être à fond dans le paradigme objet?
    Je te renvoie à un autre vieil article de Joel Spolsky, dont j'ai pu constater sur le terrain(dont je parle ci-dessus) la pertinence. : https://www.joelonsoftware.com/2002/...rub-a-dub-dub/

    Citation Envoyé par Joel spolsky
    No New Features, not even small ones, would be added.
    At any time, with any check in, the code would still work perfectly.
    All I would do is logical transformations — the kinds of things that are almost mechanical and which you can convince yourself immediately will not change the behavior of the code.
    Exactement ce que j'ai fait dans mon premier exemple - à part le module de pilotage qui permettait de tout centraliser. Plus loin dans l'article, Joel Spolsky parle de classes, mais je n'en avait aucune (le COBOL objet est une rare curiosité), et j'ai appliqué sa méthode avec succès. D'ailleurs, je m'aperçois que mon module de pilotage faisait écho à ça (la mise en gras est de moi) :

    Citation Envoyé par Joel Spolsky
    Restructured the ASP site so there is a single entry point instead of lots of different files. This makes it very easy to do things that used to be hard, for example, now we can display input error messages in the very form where the invalid input occurred, something which should be easy if you lay things out right, but I hadn’t laid things out right when I was learning ASP programming way back when.
    Dit autrement, j'ai expérimenté. Quand tu as un code qui marche comme il faut que tu dois refactorer, la méthode Spolsky marche, objet ou pas.
    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.

  4. #24
    Membre chevronné Avatar de mfoxy
    Homme Profil pro
    Automation VBA
    Inscrit en
    février 2018
    Messages
    744
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Belgique

    Informations professionnelles :
    Activité : Automation VBA
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : février 2018
    Messages : 744
    Points : 1 925
    Points
    1 925
    Par défaut
    Bonjour,

    À ma petite hauteur, je dirais que le refactoring de ses propres "logiciels" peut-être intéressant, on en apprends tout les jours et se perfectionne dans sa manière de travailler/coder/appréhender les besoins actuels et futurs.

    Pour ce qu'y est de faire du refactoring de programme que d'autres ont développé , c'est souvent loin d'être évident, surtout quand les bonnes pratiques ne se sont pas mise en place, et le code non documenté (l'exemple du stagiaire chapeauté par un stagiaire de niveau 2 donné par Pierre F.) .
    Dans ce cas s'il s'agit de petit soft, je préfère reprendre de 0, à ma sauce, le reverse engineering, refactoring, debogage prenant souvent plus de temps ( et le temps c'est de l'argent pour mon boss).

    Pour les "gros" logiciels, la société a pris la décision d'externaliser le développement et la gestion des programmes ( système de leasing) ce qui nous met à l'abri de devoir reprendre des projets essentiels au bon fonctionnement de l'entreprise , et dont les rouages, si fait en interne, ne seraient connus uniquement de celui/celle qui aurait mis en place le programme.

    Bav,
    Michaël

    Si mon aide/avis vous a été profitable , n'hésitez pas à cliquer sur , ça fait toujours plaisir...
    _________________________________________________________________________________________________________________

    "Tout le monde est un génie. Mais si on juge un poisson sur sa capacité à grimper à un arbre, il passera sa vie à croire qu'il est stupide..."
    Albert Einstein

  5. #25
    Membre confirmé

    Profil pro
    Inscrit en
    mai 2003
    Messages
    233
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2003
    Messages : 233
    Points : 507
    Points
    507
    Billets dans le blog
    1
    Par défaut
    Réécrire un module oui.
    Réécrire un logiciel non.
    Développer un nouveau logiciel oui.
    Refactorise tout ce que tu veux.

  6. #26
    Membre éclairé

    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2007
    Messages
    722
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2007
    Messages : 722
    Points : 754
    Points
    754
    Par défaut
    Ce qui m'étonne, avec la quantité d'adeptes du refactoring, c'est qu'on dirait que personne n'a jamais bossé dans une boite où les deadlines sont déjà trop courtes ne serait-ce que pour juste faire en sorte que ça marche.

    Dans ce genre de boites, les devs n'ont pas le temps de faire les choses proprement, en respectant les bonnes pratiques, en suivant tous les standards (ni même de les apprendre), etc. et c'est remis à plus tard, quand on aura le temps... les années passent et on se retrouve avec une dette technique d'au moins autant d'années, à force d'empiler rustines sur rustines.

    À un moment, ça devient intenable et si, par chance, les décideurs admettent qu'il est temps de de reprendre ça en main, il est souvent bien plus simple de tout reprendre de zéro.

    Alors, oui, je suis vraiment étonné, car en plus de 15 ans d'entraide, sur différents sites, l'excuse du "pas le temps" représente 99.999% de celles invoquées pour ne pas faire les choses comme il faudrait.
    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)

  7. #27
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    7 359
    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 : 7 359
    Points : 16 971
    Points
    16 971
    Par défaut
    Citation Envoyé par Lcf.vs Voir le message
    Ce qui m'étonne, avec la quantité d'adeptes du refactoring, c'est qu'on dirait que personne n'a jamais bossé dans une boite où les deadlines sont déjà trop courtes ne serait-ce que pour juste faire en sorte que ça marche.
    il n'y a pas vraiment d'adeptes du refactoring,il faut être pragmatique ; au besoin le refactoring peut être utile sinon le logiciel est très coûteux à maintenir.
    On parle de dette technique un concept déjà mentionné sur ce forum
    Ensuite je suis bien d'accord qu'il y ait des entreprises où les deadlines sont trop courtes mais ce sont des entreprises qui n'ont pas toujours les moyens en ressources humaines pour constituer des équipes conséquentes.
    D'une manière ou d'une autre développer un logiciel cela représente tout un coût en entreprise.
    Qu'est ce qui est petit et marron ? Un marron ( Kaamelott)

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 451
    Points : 30 181
    Points
    30 181
    Par défaut
    Citation Envoyé par Lcf.vs Voir le message
    Ce qui m'étonne, avec la quantité d'adeptes du refactoring, c'est qu'on dirait que personne n'a jamais bossé dans une boite où les deadlines sont déjà trop courtes ne serait-ce que pour juste faire en sorte que ça marche.
    pro-tip : quand on travaille plus proprement on est plus productif. Souvent dès la première itération. Le simple fait d'avoir pris le temps de penser correctement son architecture fait gagner un temps fou.

    Citation Envoyé par Lcf.vs Voir le message
    Dans ce genre de boites, les devs n'ont pas le temps de faire les choses proprement, en respectant les bonnes pratiques, en suivant tous les standards (ni même de les apprendre), etc. et c'est remis à plus tard, quand on aura le temps... les années passent et on se retrouve avec une dette technique d'au moins autant d'années, à force d'empiler rustines sur rustines.
    en effet, beaucoup de gens n'ont pas écouté on pro-tip. Il m'est arrivé, dans les exemples que je donne ci-dessus, que des chefs techniques prennent l’occasion d'un changement fonctionnel pour faire faire une refonte complète. Ce n'est pas fréquent, mais il se trouve que je me suis retrouvé plusieurs fois dans ce cas-là. Et là, se pose la question : "refactoriser ou repartir d'une feuille blanche?" Question intéressante et complexe.

    Citation Envoyé par Lcf.vs Voir le message
    À un moment, ça devient intenable et si, par chance, les décideurs admettent qu'il est temps de de reprendre ça en main, il est souvent bien plus simple de tout reprendre de zéro.
    Ben pas forcément, justement. Parfois, tu vas repartir de zéro pour un petit changement en fin de chaîne. Parfois tu vas juste refactoriser un monstre illisible. J'ai fait les deux. Dans les deux cas, il fallait considérer l'ensemble des contraintes pesant sur le projet, pas seulement de l'état du code. Un des trucs importants dits par Joel Spolsky, c'est que le vieux code pourri contient un tas d'astuces fonctionnelles dont la mémoire a pu se perdre par ailleurs. C'était mon cas quand j'ai fait un simple refactoring. Ca aurait été simple de tout reprendre à zéro, mais sans specs, tu fais comment? Alors qu'un refactoring systématique a permis de garder isofonctionnalité sur tous les éléments. Le code aussi atroce soit-il était la seule trace qui restait d'années de peaufinages. Ca a sans doute coûté plus cher...au départ. Le nombre de bugs au final était dérisoire.

    Citation Envoyé par Lcf.vs Voir le message
    Alors, oui, je suis vraiment étonné, car en plus de 15 ans d'entraide, sur différents sites, l'excuse du "pas le temps" représente 99.999% de celles invoquées pour ne pas faire les choses comme il faudrait.
    Et c'est une mauvaise excuse. Quand on fait les choses bien, on finit plus vite. Cela étant, faire vite n'est pas la seule cause de dette technique. Les maintenances qui s'empilent pendant des années sont une autre cause de dette technique, parfaitement acceptable, et qu'il faut pourtant parfois traiter.
    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.

  9. #29
    Membre éclairé

    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2007
    Messages
    722
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2007
    Messages : 722
    Points : 754
    Points
    754
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    pro-tip : quand on travaille plus proprement on est plus productif. Souvent dès la première itération. Le simple fait d'avoir pris le temps de penser correctement son architecture fait gagner un temps fou.
    Assurément mais encore faut-il qu'on te laisse ce temps de correctement le penser, analyser les besoins, les approches possibles, ce que ça peut impliquer dans l'existant, ... surtout alors que tu débarques déjà sur un monstre illisible.

    Citation Envoyé par el_slapper Voir le message
    Ben pas forcément, justement. Parfois, tu vas repartir de zéro pour un petit changement en fin de chaîne. Parfois tu vas juste refactoriser un monstre illisible. J'ai fait les deux. Dans les deux cas, il fallait considérer l'ensemble des contraintes pesant sur le projet, pas seulement de l'état du code. Un des trucs importants dits par Joel Spolsky, c'est que le vieux code pourri contient un tas d'astuces fonctionnelles dont la mémoire a pu se perdre par ailleurs. C'était mon cas quand j'ai fait un simple refactoring. Ca aurait été simple de tout reprendre à zéro, mais sans specs, tu fais comment? Alors qu'un refactoring systématique a permis de garder isofonctionnalité sur tous les éléments. Le code aussi atroce soit-il était la seule trace qui restait d'années de peaufinages. Ca a sans doute coûté plus cher...au départ. Le nombre de bugs au final était dérisoire.
    Oui, là, je parlais vraiment d'un cas que j'ai connu où par-dessus un monstre illisible, tout ce qu'on te faisait faire, c'était ajouter des fonctionnalités reposant sur un truc déjà impossible à maintenir, j'avais averti, avant d'engager d'autres

    Citation Envoyé par el_slapper Voir le message
    Et c'est une mauvaise excuse. Quand on fait les choses bien, on finit plus vite. Cela étant, faire vite n'est pas la seule cause de dette technique. Les maintenances qui s'empilent pendant des années sont une autre cause de dette technique, parfaitement acceptable, et qu'il faut pourtant parfois traiter.
    Là aussi, je te rejoins mais essaie de leur dire , dans ce genre de cas, les réactions des interlocuteurs sont souvent assez étonnantes :
    • on te dit qu'osef, ça marche quand même
    • on te cherche plein d'exemples sur le net de gens qui font comme eux
    • on te fait comprendre que la spécification est subjective
    • on te dit que ça demanderait trop de taff et/ou de maîtriser trop de choses
    • on te prétend que les best practices ne sont pas possibles à mettre en oeuvre
    • on invoque que ça coûterait trop cher pour le client
    • on fait un max pour tenter de te décrédibiliser
    • ...


    Les gens ont une inventivité folle pour ne pas devoir mieux faire ou pour ne simplement pas changer d'habitudes.
    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)

  10. #30
    Membre expérimenté
    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2007
    Messages
    841
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : février 2007
    Messages : 841
    Points : 1 456
    Points
    1 456
    Par défaut
    Réécrire un projet entièrement ne garanti pas les bonne pratiques, ni que le suivi sera correct...

    Désole de vous choquer, mais réécrire une application demande de comprendre le fonctionnement de l'application existante, y compris de ses bugs. Plus d'une fois un client m'a demande de reproduire les anciens bugs, car cela permettait une 'certaine' utilisation du produit.

    Donc il faudra écrire des tests de non régressions, pour comparer les applicatifs, et au final on se retrouve avec les moyens de faire un refactoring efficace.

  11. #31
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    7 359
    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 : 7 359
    Points : 16 971
    Points
    16 971
    Par défaut
    Citation Envoyé par mermich Voir le message
    Plus d'une fois un client m'a demande de reproduire les anciens bugs, car cela permettait une 'certaine' utilisation du produit.
    merci pour l'info mais ça c'est un problème de conception c.a.d que l'analyse conceptuelle du projet est défaillante ou insuffisante.
    Sans faire des spécifications, de l'analyse métier le projet risque de mal tourner.
    Qu'est ce qui est petit et marron ? Un marron ( Kaamelott)

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 451
    Points : 30 181
    Points
    30 181
    Par défaut
    Citation Envoyé par Mat.M Voir le message
    merci pour l'info mais ça c'est un problème de conception c.a.d que l'analyse conceptuelle du projet est défaillante ou insuffisante.
    Sans faire des spécifications, de l'analyse métier le projet risque de mal tourner.
    C'est le cœur du sujet, encore une fois. Repartir d'une feuille blanche, ça n'est possible que si on a toutes les fonctionnalités documentées. Il est fréquent (mais pas systématique) que le vieux code soit la seule source de documentation à ce sujet. D’où l’intérêt du refactoring : on ne perd pas de savoir faire qu'on ignore avoir. Après, si on a un nouveau set de specs qui ne colle pas à l'existant, la situation est tout à fait différente. Mais il faut savoir ou on se situe.
    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.

  13. #33
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    avril 2014
    Messages
    2 323
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : avril 2014
    Messages : 2 323
    Points : 1 931
    Points
    1 931
    Billets dans le blog
    1
    Par défaut
    S'ils n'avaient pas de chemin pour une mise à jour de la version d'Angular... bah c'est qu'ils faisaient de l'AngularJS, pas de l'Angular.

  14. #34
    Membre confirmé

    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    février 2005
    Messages
    451
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : Industrie

    Informations forums :
    Inscription : février 2005
    Messages : 451
    Points : 558
    Points
    558
    Par défaut
    Dans tous cela on discute de la pertinence d'un point de vue technique et effectivement tout dépend. En tout cas si c'est pour tout refaire parce que l'on n'a pas de spec mais que l'on n'en crée pas au passage c'est un peu comme proposer l'aile ou la cuisse au client.
    J'ai des connaissances pour qui corriger un bug d'une ligne coutent 3 semaines de doc à justifier les modifications, proposer les tests à réaliser, etc...
    Moi-même j'ai du faire face a certaines incompréhensions : le CdP qui me demandait de ne pas intégrer l'usine à gaz existante, et le commercial qui me demandait des fonctionnalités basées sur un existant pour lequel il n'y avait aucune spec de donnée, que j'ai zappées. Heureusement que la reprise avait donné de meilleurs résultats.

    Il faut que la direction soit ouverte à la discussion sur le coût d'une reprise complète, et souvent on nous tiendra le discours : "Ca marche pas mais tout est fait alors tu n'en as pas pour longtemps..."
    Selso.
    Ingénieur/CdP développement systèmes embarqués &

  15. #35
    Expert éminent sénior
    Avatar de Glutinus
    Homme Profil pro
    Freelance EURL / Business Intelligence ETL
    Inscrit en
    avril 2005
    Messages
    5 264
    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 : 5 264
    Points : 24 907
    Points
    24 907
    Billets dans le blog
    3
    Par défaut
    Je crois que la réponse la plus simple, qui est la plus évidente, a été donnée par el_slapper : ça dépend.
    Actuellement sur mon projet, en posant le stylo et en s'assurant que tout le monde a bien compris, on aurait pu mettre un focus sur les points importants mais peu onéreux (la fameuse loi de Pareto, 20% de cause pour 80% de conséquences... donc 20% de code pour 80% de performance minable sur nos temps de traitement).

    Bon heureusement on met le point dessus alors qu'on est sur la fin de la première itération de dev. Du coup j'ai réussi à vendre des optimisations qui ne sont plus ni moins que des bonnes pratiques.
    Le truc aberrant qui aurait dû être présent au début du projet (rajouter une tâche de datacleansing pour toutes les tables en entrée... j'imagine que l'argument c'était qu'on pouvait rajouter des tables à traiter... Bah tu automatises ta tâche pour qu'ils tapent sur une table de paramètres et tu rajoutes à chaque fois une nouvelle table...).

    Bref c'est hallucinant et évidemment, ça ne va pas en s'arrangeant. Je veux bien que "la meilleure doc soit le code", encore faut-il qu'il soit commenté. J'ai l'impression d'être il y a 10 ans quand j'avais deux ans d'expérience et que je chapotais un junior :
    - T'as testé ?
    - CA compile.
    - Oui mais le résultat ?
    - J'ai une ligne en entrée et une ligne en sortie.
    - Oui mais le contenu ?
    - On verra en recette.
    - Et les commentaires avec la règle de gestion complexes qu'on a vu avec la MOA pour le calcule de la date fin, t'as commenté ?
    - Oui.
    J'ouvre dans le framework l'objet impacté : "Cette fonction calcule la DATE_FIN".
    - Heu, c'est pas un commentaire pour moi.
    - Roh, je ferai une doc quand je partirai !
    - 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

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 451
    Points : 30 181
    Points
    30 181
    Par défaut
    Glutinus, ton stagiaire me fait penser à une réflexion de notre administrative. Elle m'a dit hier qu'au lieu d'envoyer un mail au gens pour dire "ton colis arrivera dans trois jours à 14h00", elle se met un rappel à 14h00 trois jours plus tard, et là seulement elle envoie la notification. C'est un tout petit peu plus de travail pour elle...mais ça lui évite d'avoir à courir après les gens et les colis pendant des jours parce-que les gens ont oublié d'aller chercher leur colis. Et au final, ça lui fait bien moins de boulot (et du boulot particulièrement canulant, en plus).

    Ce petit travail en plus au départ qui fait en fait gagner plein de temps, la plupart des gens ont la flemme de le faire. Ca se retourne contre eux, et ils ne retiennent pas la leçon. Je dois avouer que deux ou trois fois dans ma carrière, j'ai eu la flemme aussi. A chaque fois, ça s'est retourné contre moi. De manière brutale, rapide et sanguinolente. J'ai retenu la leçon. Elle aussi. Ton stagiaire, de toute évidence, non. Le problème, c'est qu'on croise plus de gens comme ton stagiaire que comme mon administrative.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  17. #37
    Expert éminent sénior
    Avatar de Glutinus
    Homme Profil pro
    Freelance EURL / Business Intelligence ETL
    Inscrit en
    avril 2005
    Messages
    5 264
    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 : 5 264
    Points : 24 907
    Points
    24 907
    Billets dans le blog
    3
    Par défaut
    Pour être précis c'était un jeune diplômé, qui plus est sorti d'une école de commerce et reformé par Choupa-Stevia. Il cherchait très activement un taf dans un autre domaine pour démissionner, donc développer ne l'intéressait pas. Il n'était pas mauvais, mais il ne voulait pas apprendre des bonnes pratiques, capitaliser de ses erreurs. Et surtout, que ça fonctionne ou pas derrière, il s'en battait les ballons. Par contre, des choses comme commenter ou mettre une info pertinente dans le gestionnaire de conf, ça aurait pu l'aider par la suite.

    C'est une chose que j'ai tendance à remarquer sur l'ensemble des projets que je fais - malheureusement, j'arrive toujours dans le second round, quand les premiers ont fait bien de la merde pendant deux ans. Enfin, quand on regarde la quantité / qualité (ou équivalent avec les ETL pour moi) produit en deux ans il y a eu beaucoup de tournage de pouces. Il y a peu de réunion de cadrage, a minima entre les développeurs, et au mieux entre développeur et MOA / AMOA /Business Analysts voire utilisateurs. Limite, les deux premières semaines d'un projet from scratch de 6 mois devraient être des ateliers sur à peu près tous problématiques qu'on a. Mais au final je vois toujours des rajouts de dernière minute depuis des dernières années, et ce sur des problématiques communes à tous les projets décisionnels (rajout d'index, passage de stats, audit...)

    Nom : Automatisation_commitstrip.jpg
Affichages : 156
Taille : 213,5 Ko

    Source : commitstrip

    Je suis toujours adepte d'à défaut d'une optimisation, d'une boite à outils (éventuellement transportable de client en client quitte à être un peu repensée) pour automatiser des choses. Et toujours friand d'une petite anecdote (toujours sur cette mission il y a dix ans où j'ai beaucoup appris) où j'avais pris du retard pour le début des devs, tous mes collègues avaient fait un headstart et j'ai passé mon temps à tout checké, vérifier minutieusement que source et cible ont les mêmes datatypes, les produits cartésiens, un générateur de fichier de paramètres etc. au final à l'issue de ma conception j'ai fini mes devs avant les autres et les retours sur anomalies étaient bien meilleurs ^^

    Après, pour revenir sur le début du refactoring, la meilleure optique est de se remettre autour d'une table. En général, l'idée du refactoring n'est pas un projet en soi, puisque le produit est en run. Il apparaît généralement pendant une migration, une évolution très forte qui fait changer le paradigme. C'est l'occasion de faire un tour de table pour savoir 1/ quelles ont été les embûches (mais généralement, l'équipe de base est partie à la cloche de bois et ne pourront fournir de REX...) 2/ quels sont les actuels problèmes (performances ? Source ? Cible ? Tels traitements).

    Sur mon projet actuel j'ai identifié quelques points clés :
    - Le modèle source est merdique, mais je sais qu'avec les idiots de MOA en face ça va être quasi impossible de faire fléchir. Tant pis...
    - On change le sourcing de SQL Server à Oracle, en changeant de paradigme de lecture. Je vais en profiter pour rajouter ma fameuse fonction de datacleansing, rajouter des index pour déporter la logique de l'ETL vers le SGBD (et virer les objets qui prennent trop de cache dans l'ETL).

    Bref, Expérience + simple constat de ce qui va pas + on va se concentrer et faire un effort poussé mais sur des tâches minimales, et le tour sera joué
    - 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

  18. #38
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    septembre 2007
    Messages
    7 220
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2007
    Messages : 7 220
    Points : 23 207
    Points
    23 207
    Par défaut
    J'arrive un peu après la fête mais pour le coup, je suis agréablement surpris des options proposées par le sondage. Effectivement, « ça dépend du code à refactorer ».

    C'est toujours très tentant de réécrire quelque chose à sa sauce, et ça marche généralement bien pour les petits scripts ou modules. Par contre, on sous-estime toujours le temps que l'on va prendre à ré-écrire une chose de taille moyenne et surtout, la qualité qu'on va être soi-même capable de maintenir dès que la tâche va commencer à durer un peu… Il faut vraiment l'avoir fait sur plusieurs projets pour se rendre compte que ça peut être l'un comme l'autre et que ça se décide vraiment au cas par cas.

    La véritable plaie, par contre, c'est quand on a un chef bienveillant mais « par nature plus expérimenté » qui vient prendre la décision pour nous et qui fait systématiquement l'inverse de ce que l'on aurait choisi. Ça m'est arrivé une fois. « We have no time to rewrite what has already been done » martelé en boucle par mail puis, quatre semaines plus tard, lorsqu'on a fini par produire quelque chose de propre et qu'il se décide enfin à mettre le nez dans le code source original, déclare que « oh la la, c'est vraiment trop mauvais, on ne va pas perdre de temps là-dessus, on jette tout. ».

    Une autre chose très importante est qu'il est vital, aujourd'hui, de maîtriser un bon outil de versioning (Git au hasard) quand on s'attèle à cette tâche. Et ça, ça change vraiment toute l'activité. Certes les SCM existent depuis les années 70 mais ce n'est vraiment que mi-2005 que les gens se les sont vraiment appropriés. Quand on les maîtrise bien, ça permet déjà de faire du ménage facilement (sinon, on rechigne souvent à effacer des lignes qui ont demandé du travail et c'est compréhensible) mais également d'avancer pas à pas et même de revenir en arrière. Si le projet a été versionné dès le départ, ça permet également de faire des recherches par dichotomie pour isoler des bugs, et bien d'autres merveilles.

    C'est déjà devenu indispensable dans le cycle normal de développement d'un produit logiciel, et ça change tout le décisionnel lorsqu'il s'agit de démarrer un chantier de réhabilitation d'une application.

    Il faut aussi se souvenir que dès lors qu'une application est vendue (et pas simplement développée en interne pour les besoins du personnel), il arrive fréquemment qu'elle soit « quick and dirty » pour la vendre rapidement et qu'elle soit encore vendue quinze ans plus tard (ça commence à être vieux mais c'est le cas du projet sur lequel je travaille en ce moment-même).

    Enfin, il y a un effet de masse critique : quand un projet est devenu vraiment trop gros, les ressources en années-hommes deviennent trop importantes pour envisager de le ré-écrire entièrement. C'est le cas du projet Linux ou de Windows, par exemple. Dans cette situation, une « migration continue » est quasiment inévitable et c'est pour cela qu'il est d'autant plus important de la gérer proprement.

  19. #39
    Expert éminent sénior
    Avatar de Glutinus
    Homme Profil pro
    Freelance EURL / Business Intelligence ETL
    Inscrit en
    avril 2005
    Messages
    5 264
    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 : 5 264
    Points : 24 907
    Points
    24 907
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par Obsidian Voir le message
    Une autre chose très importante est qu'il est vital, aujourd'hui, de maîtriser un bon outil de versioning (Git au hasard) quand on s'attèle à cette tâche. Et ça, ça change vraiment toute l'activité. Certes les SCM existent depuis les années 70 mais ce n'est vraiment que mi-2005 que les gens se les sont vraiment appropriés.
    C'était la date de mes premiers stages, 2005, et effectivement on m'en parlait comme d'un sujet neuf, j'en ai déduit que ce n'était pas les pratiques habituelles.
    Fin 2008 je quittais un client où j'étais seul sur l'appli, donc je jonglais entre des fichiers SQL que je versionnais moi-même... Dernier échange avec ma chef de projet tant détestée dont l'incompétence et la cheffailonnerie fut en partie raison de mon départ.

    Moi (à toute la boite) : ce fut un plaisir de bosser blablabla au revoir.
    Tout le monde sauf cheffe : merci pour tout ce que tu as fait.
    Cheffe : t'as mis toute ton application sur Clearcase ?
    (comme j'étais seul, donc, elle avait estimé que ce n'était pas urgent de l'intégrer dans ce projet de l'année qui apparemment a pris 6 mois pour toute le reste de l'appli. Je juge pas, je sais pas.)
    Moi : Non.
    Cheffe : tu me la mets ?

    Franchement, j'aurai dû me forwarder ce dernier mail pour le garder... dans les annales...
    - 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

  20. #40
    Responsable
    Office & Excel


    Homme Profil pro
    Formateur et développeur informatique indépendant
    Inscrit en
    novembre 2003
    Messages
    16 589
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Belgique

    Informations professionnelles :
    Activité : Formateur et développeur informatique indépendant
    Secteur : Enseignement

    Informations forums :
    Inscription : novembre 2003
    Messages : 16 589
    Points : 47 771
    Points
    47 771
    Billets dans le blog
    88
    Par défaut
    Citation Envoyé par Glutinus Voir le message
    [...]
    Cheffe : tu me la mets ?

    Franchement, j'aurai dû me forwarder ce dernier mail pour le garder... dans les annales...
    je m'suis pissé dessus ^^ Ca me fait penser au boucher de ma mère qui, lorsqu'elle achetait de la saucisse, lui disait toujours (ça le faisait rire et ça faisait rougir ma mère): Il y en a un peu plus, je vous la mets quand même? (ok, je sors...).
    "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...
    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...
    ---------------

Discussions similaires

  1. Réponses: 80
    Dernier message: 17/05/2020, 06h55
  2. Êtes-vous pour ou contre le fait de divulguer des failles ?
    Par Stéphane le calme dans le forum Sécurité
    Réponses: 10
    Dernier message: 02/09/2018, 17h06
  3. Réponses: 23
    Dernier message: 10/11/2017, 11h28
  4. Êtes-vous pour ou contre les "strict type hints" ?
    Par RideKick dans le forum Langage
    Réponses: 44
    Dernier message: 21/03/2012, 22h18
  5. Outil d'aide pour le refactoring de code
    Par progfou dans le forum Autres éditeurs
    Réponses: 2
    Dernier message: 14/03/2008, 15h04

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