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 :

La refactorisation est-elle réellement utile ?


Sujet :

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

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2014
    Messages
    194
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : septembre 2014
    Messages : 194
    Points : 12 274
    Points
    12 274
    Par défaut La refactorisation est-elle réellement utile ?
    La refactorisation est-elle réellement utile ?
    Selon une récente étude, il n’y a pas assez de preuves empiriques pour justifier son utilisation

    Dans une récente étude publiée dans l’ « International Journal of Software Engineering & Applications », deux chercheurs sri lankais ont tenté de mesurer l’impact de la refactorisation sur le code.

    Selon la définition de Wikipédia, la refactorisation « consiste à retravailler le code source d'un code informatique sans ajouter de fonctionnalités au logiciel ni corriger de bogues, mais en améliorant sa lisibilité pour simplifier sa maintenance, ou le rendre plus générique ». Toutefois, ceci n’est pas forcément garanti selon les deux chercheurs sri lankais. Dans le rapport qu’ils ont publié en janvier dernier, ils déclarent que les preuves empiriques sont limitées pour soutenir l’hypothèse qui dit que le remaniement du code améliore sa qualité, son intelligibilité, sa flexibilité ou sa réutilisabilité.

    Dans cette étude, plusieurs techniques de refactoring ont été analysées par deux groupes de 10 étudiants chacun, en se basant sur des mesures internes telles que la cohésion, le couplage des classes, le nombre de lignes de codes, la complexité cyclomatique et l’indice de maintenabilité, ainsi que des mesures externes comme l’intelligibilité, l’analysabilité, le temps d’exécution moyen et l’utilisation des ressources. L’application utilisée dans l’expérience (développée au département de Management Industriel de l’Université de Kelaniya au Sri Lanka) représentait un mini système permettant au staff académique de planifier leurs évènements personnels et professionnels et gérer leurs documents en ligne. Le code du projet, écrit en C#.net, contenait environ 4 900 lignes de codes au départ.


    Figure : résultat des mesures internes avant et après le remaniement du code

    « Le résultat des mesures externes n'a pas montré d’améliorations dans la qualité de code après la refactorisation », déclarent les chercheurs après l’analyse des résultats. Cependant, dans les mesures internes, seul l'indice de maintenabilité a indiqué une amélioration dans la qualité du code remanié, « les autres mesures internes n'ont indiqué aucun effet positif sur le code ». Au contraire, les résultats des analyses ont montré que ces autres mesures ont présenté un effet négatif, ce qui ramène les chercheurs à conclure que « la maintenabilité du code remaniée est relativement faible par rapport au code non remanié si l'on considère la complexité cyclomatique, le couplage des classes et le nombre de lignes de code ».

    Toutefois, il faut noter que l’étude n’a tenu compte que de 10 techniques de refactorisation parmi les 72 cités dans le livre de référence intitulé « Refactoring: Improving the Design of Existing Code » publié en 1999.

    Source : Rapport de l’étude publiée

    Et vous ?

    Êtes-vous d’accord avec la conclusion donnée par les deux chercheurs ?

    D’habitude, la refactorisation vous permet-elle de mieux maintenir votre code après ?

  2. #2
    En attente de confirmation mail

    Profil pro
    Inscrit en
    septembre 2013
    Messages
    640
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2013
    Messages : 640
    Points : 2 337
    Points
    2 337
    Par défaut
    A quand une étude prouvant que le code "orienté objet" n'est pas plus réutilisable / maintenable / élégant que le code procédural ?

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 003
    Points : 27 670
    Points
    27 670
    Par défaut
    Sur un code de 5000 lignes environ, c'est peu significatif. Et, en plus, ça dépend du talent du refactoreur. Si il est moins bon que les programmeurs initiaux, le résultat final va être pourri.

    De toutes manières, ce qui coute cher, c'est la maintenance. Donc l'amélioration de la maintenabilité est quand même l'objectif, et il semble atteint. Mais la vrais question des de savoir si le code initial méritait réellement un refactoring. Si il a 2-3 erreurs de conception pas trop graves, franchement, refactoriser, c'est de la masturbation intellectuelle. Si, par contre, c'est une suite sans fin de :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    A12.
        MOVE 1 TO II.
    A113.
        IF ZZ(II) > 0 ADD ZZ(II) TO GG
        ADD 1 TO A113
        GO TO A113.
    A11.
        MOVE GG TO YY.
    alors là, une refactorisation est indispensable. (PS : le vrai code était pire que ça, mais je tiens à votre santé mentale, alors j'ai édulcoré; et non, il n'y a pas de boucle infinie, en cobol, le point sert aussi de end-if, pour les obfuscateurs professionels). La complexité Cyclomatique, en comparaison, je m'en fous.

    Dans le même langage, un exemple de refactorisation à peu près propre (même si il y a toujours moyen d'améliorer la sauce)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    A-CUMUL-TAXES.
        PERFORM VARYING COMPTEUR FROM 1 BY 1 UNTIL TAXE(COMPTEUR) <= 0
            ADD TAXE(COMPTEUR) TO CUMUL-TOTAL
        END-PERFORM
        MOVE CUMUL-TOTAL TO VARIABLE-AFFICHAGE
        .
    Je ne sais pas si j'ai augmenté la complexité cyclomatique ou si je l'ai réduite, et je m'en fous. Je n'ai évidemment pas touché au couplage de classes ou à la profondeur d'héritages(je suis resté dans mon paragraphe, et de toutes façons le cobol est rarement objet). Mais je suis sur que le gars(en fait, c'était une fille) qui est passé(e) après a eu moins de mal que moi à interpréter ce paragraphe. En plus, ça permet de faire sauter aux yeux les fragilités du codage(le cumul est-il bien initialisé au départ? le cumul a-t-il le bon format pour l'affichage? Que se passe-t-il si la dernière occurrence du tableau n'est pas à zéro?).

    Sur la structure, c'est toujours plus difficile à estimer. Ajouter de la maintenabilité, ça veut parfois dire encapsuler des choses(objets, fonctions, peu importe), ce qui augmente la complexité, et parfois réduit les performances. Mais si c'est ça le message de l'étude, ben, merci de l'enfonçage de portes ouvertes.
    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. #4
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Cyber sécurité
    Inscrit en
    mai 2004
    Messages
    9 743
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Cyber sécurité

    Informations forums :
    Inscription : mai 2004
    Messages : 9 743
    Points : 26 324
    Points
    26 324
    Par défaut
    Le refactoring du code par des étudiants, c'est un peu étrange, parce qu'ils n'ont justement pas le recul nécessaire pour savoir s'il est intéressant de refactorer ou non, ni quelle partie du code, ni pourquoi...

    Oui, un jeune est souvent plus volontaire pour refactorer, et est moteur pour le faire. MAIS la plupart du temps ça ne se passe pas aussi bien que prévu par manque d'expérience, par l'utilisation de nouveaux outils ou de nouvelles versions pas encore stables, et qui amènent donc des régressions.

    Et puis 4 900 lignes à refactorer... Je pense que ça serait plus parlant sur un code plus gros.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  5. #5
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    décembre 2008
    Messages
    474
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Rhône (Rhône Alpes)

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

    Informations forums :
    Inscription : décembre 2008
    Messages : 474
    Points : 1 381
    Points
    1 381
    Par défaut
    Je suis d'avis qu'il faut impérativement réfactorer lorsqu'on a le temps et lorsque cela semble nécessaire.

    En effet souvent les entreprises ne veulent prendre aucun risque et perdent de l'agent dans la maintenance d'un code qui à mal évolué.

    Il y'a pas longtemps sur un audit de code, on est passé de 110 000 lignes de code sur un projet à 85 000 tout en baissant drastiquement la complexité.

    Cela dit, pour refactorer il est intéressant de :

    - connaitre le projet utilisé et surtout le contexte métier pour le rendre parlant
    - connaitre le langage utilisé
    - documenter
    - ne pas vouloir compacter le code à tout prix
    - on peut optimiser celons le type de projet
    - il peut être intéressant de travailler un refactoring en binôme


    Les tests unitaires automatiques de non régression sont très importants afin d'éviter au maximum les effets de bords d'un reffactoring

    bref pour moi le reffactoring est nécessaire pour garder une qualité de code tout au long du cycle de vie d'un projet ( ce qui manque cruellement dans nombre de projets).
    On limite ainsi l'errosion applicative au fils des années et des devs.

  6. #6
    Membre actif
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2010
    Messages
    107
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : avril 2010
    Messages : 107
    Points : 239
    Points
    239
    Par défaut
    Citation Envoyé par dfiad77pro Voir le message
    - ne pas vouloir compacter le code à tout prix
    - il peut être intéressant de travailler un refactoring en binôme
    Tutafé ! Je suis bien d'accords avec ton post, mais je tiens à souligner les 2 remarques que j'ai cité.

    Refactoring ne veut pas forcément dire compactage, et surtout le refactoring en binôme (ou moins avoir une personne qui intervient de temps en temps) permet de garder le cap, de confronter des idées, et de discuter sur les implémentations possibles.
    Mais bon pour le boss, 2 ressources sur la même tâche on perds du fric et on va être obligé de fermer la boîte le mois suivant...

  7. #7
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    décembre 2008
    Messages
    474
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Rhône (Rhône Alpes)

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

    Informations forums :
    Inscription : décembre 2008
    Messages : 474
    Points : 1 381
    Points
    1 381
    Par défaut
    Citation Envoyé par Juda-Priest Voir le message
    Tutafé ! Je suis bien d'accords avec ton post, mais je tiens à souligner les 2 remarques que j'ai cité.

    Refactoring ne veut pas forcément dire compactage, et surtout le refactoring en binôme (ou moins avoir une personne qui intervient de temps en temps) permet de garder le cap, de confronter des idées, et de discuter sur les implémentations possibles.
    Mais bon pour le boss, 2 ressources sur la même tâche on perds du fric et on va être obligé de fermer la boîte le mois suivant...
    #MODE SARCASME
    Oui pas grave, le fric on va le perdre en maintenance
    En plus le travail en binôme permet souvent de faire monter en compétence, mais ça ça les intéresses pas, le dev risque de demander une augmentation

  8. #8
    Membre confirmé
    Profil pro
    Expert technique .NET
    Inscrit en
    août 2007
    Messages
    272
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Expert technique .NET

    Informations forums :
    Inscription : août 2007
    Messages : 272
    Points : 523
    Points
    523
    Par défaut
    il n'y a pas assez de preuves empiriques pour justifier son utilisation
    La bêtise, par contre a subie assez de tests, empiriques ou non, pour justifier son éradication. Commençons par les idiots qui ont pondu cette étude.

    par deux groupes de 10 étudiants chacun
    Un refactoring efficace nécessite un minimum d'expérience, donc ne prendre que des étudiants est une erreur (note : je ne dis pas que les étudiants sortant de l'école ne savent pas faire du code correct).

    se basant sur des mesures internes telles que la cohésion, le couplage des classes, le nombre de lignes de codes, la complexité cyclomatique et l’indice de maintenabilité, ainsi que des mesures externes comme l’intelligibilité, l’analysabilité, le temps d’exécution moyen et l’utilisation des ressources.
    Les métriques indiquées sont purement consultatives, et ne sont pas un gage absolu de qualité / non-qualité du code.

    Toutefois, il faut noter que l’étude n’a tenu compte que de 10 techniques de refactorisation parmi les 72 cités dans le livre de référence intitulé « Refactoring: Improving the Design of Existing Code » publié en 1999.
    Voilà tout le problème : on applique bêtement ce qui est écrit dans un livre, sans savoir prendre du recul. Etude finalement inutile et à jeter.

  9. #9
    Membre éprouvé
    Homme Profil pro
    Noob
    Inscrit en
    octobre 2009
    Messages
    358
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Noob

    Informations forums :
    Inscription : octobre 2009
    Messages : 358
    Points : 1 242
    Points
    1 242
    Par défaut
    Je dis peut être une bêtise, mais si le refactoring est censé améliorer la maintenabilité du code, est-ce que justement un des objectifs n'est pas de découpler les classes quand c'est possible? Je trouve étrange que cette stat augmente.

    Après on ne sait pas si des classes ont été créées durant le refactoring, si oui c'est complètement idiot de compter en valeur absolue pour au final annoncer "-7%".

  10. #10
    Membre du Club
    Profil pro
    Inscrit en
    août 2010
    Messages
    34
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : août 2010
    Messages : 34
    Points : 67
    Points
    67
    Par défaut
    Sérieusement, une étude sur 20 étudiants, 4900 lignes et un seul programme testé...

    se basant sur des mesures internes telles [...] le nombre de lignes de codes, [...], le temps d’exécution moyen et l’utilisation des ressources.
    Je ne pense pas que c'est avec ce genre de mesures qu'on peut déduire de la bonne qualité/maintenabilité d'un code. Dans mon cas, ça peut même être l'inverse en ce qui concerne le nombre de lignes de codes.

    Bref, je suis désolé d'être aussi direct, mais "bullshit" sur ce coup là...

    (mais j'vous aime bien developpez.com, hein )

  11. #11
    Membre habitué
    Homme Profil pro
    Développeur .NET
    Inscrit en
    juin 2012
    Messages
    78
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2012
    Messages : 78
    Points : 159
    Points
    159
    Par défaut
    Je me demande quelle est la connaissance d'étudiant sur le framework .NET. . . .

  12. #12
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    juillet 2013
    Messages
    1 218
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 218
    Points : 7 647
    Points
    7 647
    Billets dans le blog
    43
    Par défaut
    Déjà, comme cela a déjà été dit, l'échelle de l'expérience n'est pas significative.
    • Un code source de 4500 lignes n'est clairement pas suffisant pour juger d'un refactoring.
    • Deux groupe de 10 étudiants chacun venant d'un pays qui n'est pas renommé pour son industrie IT.


    De plus, au niveau de la méthodologie, l'étude a sélectionné 10 des techniques de refactoring de Martin Fowler qui datent des années 2000 (c'est-à-dire l'âge d'or de l'intégrisme POO).
    Et c'est surtout là que le bât blesse à mon avis.
    Certaines des 10 techniques considérées sont manifestement critiquables du point de vue des métriques analysées notamment le couplage.
    R1- Introduce Local Extension
    R2- Duplicate Observed Data
    R3- Replace Type Code with Subclasses
    R4- Replace Type Code with State/Strategy
    R5- Replace Conditional with Polymorphism
    R6- Introduce Null Object
    R7- Extract Subclass
    R8- Extract Interface
    R9- Form Template Method
    R10- Push Down Method

    R1, R3, R5 et R7 sont des techniques qui augmentent de fait le couplage.
    Par exemple, R1 préconise de créer des sous-classes clientes pour étendre le comportement de classes serveurs. Cela peut être le cas lorsqu'on utilise un framework externe. Or la tendance actuelle montre qu'il est souvent préférable de limiter l'héritage et de plutôt privilégier la composition pour justement éviter le couplage parent serveur / enfant client causé par l'héritage.
    R3 et R7 sont du même acabit. Quant à R5, en plus d'introduire des classes, de l'héritage et donc du couplage là où on pourrait s'en passer, l'emploi immodéré du polymorphisme (R5) peut conduire à du code incompréhensible.

    C'est donc une étude qui a selon moi une bonne décennie de retard.
    Tutoriels et FAQ TypeScript

  13. #13
    Membre expert Avatar de Zefling
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2007
    Messages
    1 063
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

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

    Informations forums :
    Inscription : avril 2007
    Messages : 1 063
    Points : 3 928
    Points
    3 928
    Par défaut
    Citation Envoyé par gangsoleil Voir le message
    Et puis 4 900 lignes à refactorer... Je pense que ça serait plus parlant sur un code plus gros.
    Pas forcement, une fois j'avais fait une refacto d'un code de 2500, qui est passé à environ 1000 lignes. Ça pris du temps, mais nécessaire car le code était devenu illisible. Généralement quand il y a refacto dans les boîtes où j'étais, c'est qu'on arrive à un point où ça devient une nécessité. Pour moi, je le fais quand je vois qu'il y a des choses qui ont tendance à se répéter (enfin, reproduire un schéma qui se ressemble). Il est sur que plus le code est gros, plus il peut y avoir de redondances ou de choses qui pourraient être plus claires.

  14. #14
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    novembre 2012
    Messages
    3 262
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2012
    Messages : 3 262
    Points : 9 551
    Points
    9 551
    Par défaut
    Après une récente étude sur mon velouté de courgettes ce midi, je pose la question: la fourchette est-elle réellement utile ?

    Stop aux pseudo-études qui voudraient apporter des réponses absolues à des questions qui sont à régler au cas par cas.
    One Web to rule them all

  15. #15
    Expert confirmé
    Avatar de Kropernic
    Homme Profil pro
    Analyste / Programmeur / DBA
    Inscrit en
    juillet 2006
    Messages
    3 901
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : Belgique

    Informations professionnelles :
    Activité : Analyste / Programmeur / DBA
    Secteur : Distribution

    Informations forums :
    Inscription : juillet 2006
    Messages : 3 901
    Points : 4 211
    Points
    4 211
    Par défaut
    Citation Envoyé par SylvainPV Voir le message
    Après une récente étude sur mon velouté de courgettes ce midi, je pose la question: la fourchette est-elle réellement utile ?
    La réponse est évidente ! Uniquement si on n'a pas de paille assez grosse à disposition.

    Kropernic

  16. #16
    Membre expérimenté Avatar de dfiad77pro
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    décembre 2008
    Messages
    474
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Rhône (Rhône Alpes)

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

    Informations forums :
    Inscription : décembre 2008
    Messages : 474
    Points : 1 381
    Points
    1 381
    Par défaut
    Citation Envoyé par SylvainPV Voir le message
    Après une récente étude sur mon velouté de courgettes ce midi, je pose la question: la fourchette est-elle réellement utile ?

    Pour moi la réponse serait : non la fourchette n'est pas utile car le velouté va partir dans l'évier, c'est infect !

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 003
    Points : 27 670
    Points
    27 670
    Par défaut
    Citation Envoyé par myNameIsFlo Voir le message
    Je me demande quelle est la connaissance d'étudiant sur le framework .NET. . . .
    A mon sens, c'est secondaire. J'ai pris +7 sur mon exemple en COBOL, et je suis sur qu'il n'y avait aucun coboliste parmi les votants. Ce n'est pas la connaissance technique spécifique qui fait un code propre (à 2 ou trois exceptions près, quand une astuce technique permet d'éviter un code emmerdant, genre split, ucase.....).

    Un personnel qui code proprement en Java, franchement, la probabilité qu'il fasse du code illisible en .NET(dont la philosophie est proche, sans être identique) est quasi-nulle. Non, l'expérience importante, c'est celle de la maintenance de gros projets. Quiconque a eu à maintenir un blob de millions de lignes de codes est beaucoup plus à même de faire du refactoring qu'un étudiant qui applique des méthodes certes louables, mais pas forcément adaptées. 20 étudiants à l'expertise non identifiée, ça ne fait pas une population test représentative.


    Pour le nombre de lignes, oui, ça dépend. Le code crade que j'ai pris en exemple, j'en avait 1100 lignes au début d'un programme de 4000(la suite était presque civilisée...), plus 2000 lignes dans un autre programme. Le refactoring a fortement réduit les couts de maintenance(ça a été mesuré sur 5 ans après mon départ). Mais ça valait le coup parce que c'était absolument crade. Si ça avait été acceptable(genre les 2900 lignes du premier programme qui étaient bof-bof mais lisibles quand même), eh bien ça aurait été un risque inutile, et un investissement peu avisé.

    Ne connaissant pas leur appli, il est difficile de savoir si c'était justifié. L'exercice est toujours intéressant à faire, mais il faut rester très prudent sur ses conclusions. Ce qui est vrai sur leur appli et avec leurs refactoriseurs peut être totalement différent sur d'autres applis ou avec d'autres refactoriseurs. et avec d'autres principes d'application. Quand on survole leur papier, on voit qu'ils sont obsédés par l'idée de faire des choses contrôlées. En particulier, ils parlent de "process" de refactoring, en bref, ils partent du principe que les gens suivent le petit manuel. Toujours. Et que ça en fait des professionnels compétents. Il se trouve que le talent permet souvent de faire mieux que la méthode standard, et ça, ils l'ont quasiment interdit à leurs étudiants-test. Donc on a plus une étude sur l'efficacité des principes de Martin Fowler quand ils sont appliqués bestialement, et la conclusion est mitigée. Pas très surprenant.



    Je note aussi la guerre des +- sur la remarque concernant l'orienté objet. C'est rigolo de voir à quel point les gens ont des opinions à la limite du religieux sur un sujet de ce genre. "Est-ce que l'objet est mieux que le procédural". Alors que, comme presque toujours, la seule réponse valide est "ça dépend". Et que l'ingénieur digne de ce nom analysera chaque cas sans a priori.
    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.

  18. #18
    Membre expert Avatar de Zefling
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2007
    Messages
    1 063
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

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

    Informations forums :
    Inscription : avril 2007
    Messages : 1 063
    Points : 3 928
    Points
    3 928
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    Je note aussi la guerre des +- sur la remarque concernant l'orienté objet. C'est rigolo de voir à quel point les gens ont des opinions à la limite du religieux sur un sujet de ce genre. "Est-ce que l'objet est mieux que le procédural". Alors que, comme presque toujours, la seule réponse valide est "ça dépend". Et que l'ingénieur digne de ce nom analysera chaque cas sans a priori.
    Tu peux ajouter à ça la programmation fonctionnelle. Maintenant ça ne se limite plus à procédural/objet. Surtout que les langages ont de plus en plus tendance à perdre toutes les approches ce qui permet de mieux s'adapter en fonction de la situation.

  19. #19
    Membre confirmé
    Inscrit en
    mai 2007
    Messages
    334
    Détails du profil
    Informations forums :
    Inscription : mai 2007
    Messages : 334
    Points : 492
    Points
    492
    Par défaut
    Se poser la question est intéressant, mais affirmer tout de go que ça ne sert jamais à rien, je trouve ça un peu trollesque.

    J'ai vécu des cas ou ça ne servait à rien, d'autre ou c'était indispensable, encore faut-il savoir ou on situe la limite entre nettoyage, refactor et refonte?

  20. #20
    Membre expérimenté Avatar de yann2
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mai 2004
    Messages
    896
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2004
    Messages : 896
    Points : 1 600
    Points
    1 600
    Par défaut
    Si hier c'était vendredi, aujourd'hui on est samedi ?


    Plus sérieusement, je pense que vous devriez arrêter de lire le web monsieur le chroniqueur d'actualités... au moins vous avez trouver la formule miracle pour attirer le clic mais, personnellement, je vais finir par arrêter de venir sur developpez.com si ce genre de vulgarités continuent de sortir !

    Ah quand les articles sous formes de tops ? (le 8ème point a sauvé mon projet)


Discussions similaires

  1. Réponses: 3
    Dernier message: 12/03/2014, 19h16
  2. connexion avec le reseau est-elle etablie ou pas? search api
    Par mehdi_swatch dans le forum Windows
    Réponses: 2
    Dernier message: 29/03/2005, 18h54
  3. Réponses: 9
    Dernier message: 12/12/2004, 12h55
  4. une interpolation de forme est elle possible
    Par tetsuo chima dans le forum Flash
    Réponses: 3
    Dernier message: 07/10/2003, 17h31
  5. Réponses: 5
    Dernier message: 25/03/2003, 18h27

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