Comment expliquez-vous la refactorisation à une personne non technique?

52

Comment expliquez-vous le refactoring (et la dette technique) à une personne non technique (généralement un PHB ou un client)? ("Quoi, ça va me coûter un mois de votre travail sans différence visible ?!")

MISE À JOUR Merci pour toutes les réponses jusqu’à présent, je pense que cette liste fournira plusieurs analogies utiles vers lesquelles nous pouvons indiquer les personnes appropriées (bien qu’il soit sage de modifier les références aux PHB!)

Benjol
la source
Je ne me souviens pas comment Apple a convaincu tant de gens de passer de Leopard à Snow Leopard. Probablement le prix: 100 $ de moins que d'habitude à l'époque.
mouviciel
Cette question pourrait apporter des réponses étonnamment utiles à quiconque travaille avec du code dans l'industrie. Faites attention les gens.
joshin4colours
pourquoi serait-il sage?
Louis Rhys

Réponses:

53

Lorsque vous avez un grand cinéma maison et que vous ajoutez des objets, lentement mais sûrement, un grand nid de rats se forme dans le dos.

Si vous remplacez souvent des pièces, cela vaut parfois la peine de tout arranger.

Bien sûr, si vous faisiez cela, cela fonctionnait auparavant, et cela ne fonctionnera pas mieux que lorsque vous avez commencé, mais lorsque vous devrez recommencer, les choses seront beaucoup plus faciles.

Dans tous les cas, il est probablement préférable de faire une comparaison similaire avec un domaine que le PHB ou le client connaît déjà, à savoir la voiture ou la construction ou quelque chose comme ça ...

whatsisname
la source
1
Cette analogie n’est pas la meilleure, car elle donne l’impression que de mauvaises choses s’introduisent spontanément dans votre théâtre, par opposition à celles qui résultent directement de la construction continue de votre théâtre.
Doppelgreener
21
@Axidos: "rats nest" est un idiome anglais qui signifie "un enchevêtrement apparemment impossible" (dans ce cas, des cordons et des câbles derrière le centre de divertissement)
HedgeMage
8
Conceptuellement, c'est plutôt bon - besoins "de câbles" après "rats nid"
Murph
2
@ Peter: Je pense que nous avons tous dû passer derrière la télé au moins une fois. Expliquez-le simplement comme cent fois pire et filez un fil de câbles partout et tirez ceci et tirez-le et découvrez une civilisation morte quelque part dans le désordre.
doppelgreener
3
Si quelqu'un ne peut pas vous identifier, montrez-lui ceci: google.com/images?q=do+not+touch+anyany+of+these+wires
Steve S
41

La refactorisation est comme le processus de remballage d'une valise jusqu'à ce que tout soit parfaitement en ordre. Parfois, dans le processus, vous vous demandez pourquoi vous avez essayé de mettre autant de bric-à-brac pour commencer.

Tim Post
la source
1
J'allais publier une analogie avec un garage ou une remise, mais c'est mieux.
Matt Ellen
Ou parfois, vous allez acheter quelques valises de plus et vous vous rendez compte que payer les frais de surpoids n’a rien de grave, car les coûts logiciels ne sont pas égaux à ceux du monde physique. Ensuite, vous pouvez vraiment tout ranger et la contrainte d’une seule valise s’est révélée arbitraire et absurde.
Dan Rosenstark
+1 c'est génial. En plus de rendre moins volumineux, vous réalisez que vous n’avez même pas besoin du tout et que vous pouvez donc vous en passer.
Robbie Dee
21

Je n'expliquerais pas le concept de dette technique, car ce n'est pas nécessaire. Concentrez-vous plutôt sur la refactorisation: vous modifiez la conception de votre programme, pas nécessairement pour qu'il soit "meilleur" ou "amélioré", vous le modifiez pour qu'il puisse accepter un changement que vous devez effectuer.

Une analogie avec une voiture peut s’adapter: vous devez ajouter un climatiseur à une voiture, mais il n’a pas été conçu à l’origine pour un climatiseur. Non seulement vous devez fabriquer un climatiseur en forme de L bizarre, mais vous devez également déplacer d’abord d’autres éléments et modifier le système de ventilation.

Je pense également que la refactorisation est une meilleure stratégie lorsque vous intégrez de nouvelles fonctionnalités: sinon, vous pourriez transformer le design en quelque chose qui ne fait que paraître "meilleur", mais qui pourrait en fait être mal adapté aux circonstances entourant l’ajout de votre prochaine fonctionnalité.

Macneil
la source
Déplacer les pièces dans une voiture pour obtenir de meilleures performances ou un entretien plus facile - convient à toute personne qui a soulevé le couvercle de sa voiture, mais combien de PHB l'ont déjà fait?
Peter Boughton
3
J'aime celui-ci parce qu'il souligne que la refactorisation est en cours pour faciliter (ou rendre possible) le changement requis. La refactorisation ne devrait généralement pas être faite pour elle-même, mais pour atteindre un objectif spécifique.
Kristopher Johnson
La réponse courte devient alors: ne leur dis pas! Intégrez simplement le temps dans les nouvelles fonctionnalités et refactorisez en conséquence.
Jonathan van de Veen
12

J'utilise le terme dette technique et le relie directement à quelque chose qu'ils comprennent - la dette d'entreprise. La dette technique, c'est comme contracter un emprunt. Vous payez des intérêts dessus. Par exemple, vous pouvez construire une nouvelle usine et la payer directement ou obtenir un prêt. Si vous contractez un prêt, vous en paierez davantage à long terme, mais cela a du sens financièrement si les conditions sont bonnes .

Cependant, si vous payez un intérêt de 25% sur un tel prêt, vous vous placez dans une position non viable. C'est la même chose avec la dette technique. Parfois, il est logique de contracter une dette technique. Cependant, il arrive un moment où l’intérêt est trop élevé et qu’il doit être payé. Certaines dettes techniques sont comme un prêt immobilier et d’autres comme des dettes de carte de crédit. En cas d'urgence, la dette de carte de crédit est un atout important et précieux. Cependant, il peut aussi faire sauter la banque (ou le ménage si vous le souhaitez) s'il est utilisé imprudemment.

Autre exemple: vous pouvez payer 10 000 USD pour un dépôt de courrier marketing afin de collecter davantage de prospects pour les ventes à venir. Vous payez "dette de vente". Il s’agit d’une dépense à long terme. Évaluez cela à la raison pour laquelle vous voudriez "dépenser" de l'argent maintenant pour refactoriser un morceau de code. Dans les deux cas, il n'y a pas de résultat immédiat, mais vous vous préparez pour de meilleures performances dans le futur.

J'ai tendance à utiliser le terme "dette xxxx" comme une analogie lorsque je parle à n'importe quel public cible. Par exemple, la dette opérationnelle - La presse à imprimer que nous avons maintenant fonctionne bien, mais en arrêtant la production pendant un jour (ou une semaine) et en passant à une nouvelle machine, nous pouvons augmenter la production de 25%.

EDIT - Voici un autre point de vue sur cette

Nemi
la source
1
+1 pour une réponse bien motivée démontrant une économie réaliste. La dette est parfois rationnelle et les puristes manquent trop d’occasions s’ils ne peuvent pas la tolérer.
Macneil
1
Et les gens comprennent que contracter des emprunts pour payer les intérêts des emprunts plus anciens n’est pas viable.
Christopher Mahan
1
C'est ma préférence pour l'explication, parce que j'aime parler de tout mettre au rebut et de réécrire (qui est souvent la seule option laissée à cause de tant de dettes techniques) comme faillite technique
Wayne Molina
4
C'est une réponse terrible. (1) Ceci est plus compliqué que l'explication technique de la refactorisation. (2) Cela n’explique pas le "pourquoi" de la refactorisation; il explique les "quand" de la refactorisation (c'est-à-dire: quand c'est rentable). Ou peut-être que je ne comprends vraiment pas ce post, et donc le point (1).
Thomas Eding
2
@ThomasEding (1) Ce n'est pas une explication de la refactorisation, c'est une explication de la dette technique. (2) Cela explique le pourquoi du moment de procéder à la refactorisation - à un homme d’affaires. Honnêtement, ils ne se soucient pas de la raison technique, vous le faites. Ils veulent une raison valable pour laquelle vous travaillez sur autre chose que la prochaine fonctionnalité qui va générer des ventes. C'est pourquoi la plupart des programmeurs ne peuvent pas parler à leur patron et se plaindre que ce dernier soit stupide. Ils ne sont pas stupides, ils ont juste des pilotes différents de vous.
Nemi
8

Nettoyage de printemps.

Vous ne faites aucune modification à la maison. Vous ne faites que déplacer des éléments et vous débarrasser de la poussière. Peut-être jeter des choses que vous n'utilisez plus et dont vous n'avez plus besoin. mais vous n'ajoutez rien.

Mark Canlas
la source
1
+1: C'est la meilleure réponse imo: et à peu près tout le monde peut le comprendre. "Vous vivez chez vous, les choses deviennent sales / poussiéreuses / modeuses - vous devez périodiquement faire un nettoyage en profondeur."
Steven Evers
7

"Avez-vous déjà joué à Mouse Trap ? Au fur et à mesure que nous intégrons de nouvelles fonctionnalités, modifions des interfaces et corrigeons des bogues, le code peut commencer à ressembler beaucoup à cela. Il arrive un moment où nous devons soit dépenser beaucoup d'argent (temps et efforts Cela revient à s’assurer que toutes les pièces mobiles fonctionnent correctement avec chaque nouvelle modification ou ajout, ou nous pouvons plutôt réserver du temps pour remanier la conception, ce qui réduira le nombre de pièces mobiles que nous devons gérer chaque fois que nous apportons un changement. Du point de vue de l'utilisateur final, il peut sembler que le refactor n'apporte aucun avantage, mais cet avantage apparaît chaque fois qu'une nouvelle fonctionnalité est ajoutée après le refactor. Le processus est plus rapide, introduit moins de bugs et coûte moins cher par la suite, sans oublier que le code refactorisé est souvent plus efficace en général.

Vous vous demandez peut-être pourquoi nous commençons par ressembler à Mouse Trap:

  • Parfois, faire quelque chose à l' heure actuelle signifie que nous devons sacrifier l'élégance et l'efficacité pour simplement "le faire fonctionner".
  • Les fonctionnalités du langage et les autres technologies à notre disposition en tant que programmeurs changent souvent. Parfois, de nouvelles fonctionnalités nous permettent de remplacer un enchevêtrement de six pièces mobiles par une seule.
  • Souvent, lorsque nous ajoutons la fonctionnalité C aux fonctionnalités A et B, nous ne savons pas que B finira par être supprimé et D ajouté. Une façon d'accomplir C peut très bien fonctionner avec B, mais pas très bien avec D.

Afin de continuer à construire un meilleur piège à souris, nous devons constamment revenir en arrière et trouver des endroits pour réduire la complexité et rationaliser ce que nous avons. C'est la différence entre un logiciel doté de nombreuses fonctionnalités et un logiciel de haute qualité. "

HedgeMage
la source
6

texte alternatif

Ceci est une version légèrement plus graphique de l'analogie avec le cinéma à domicile.

Si vous souhaitez ajouter un nouveau nouvel appareil [ou nouvelle fonctionnalité], vous pouvez probablement l'adapter quelque part.

Si vous souhaitez ajouter encore un autre appareil, vous pouvez acheter une rallonge, qui vous fera gagner du temps.

Mais à chaque ajout, il devient plus difficile de trouver une solution. Et vous vous exposez à un risque d'incendie 1 [bogues], et vous devrez en tirer beaucoup d'argent pour payer quelqu'un pour mettre de nouvelles prises dans le mur, ce qui pourrait très bien dégénérer jusqu'au niveau principal circuit imprimé, ou même plus loin.

1 Une autre chose que les PHB ne parlent pas très bien: "Eh bien, si cela pouvait arriver, de quoi vous inquiétez-vous?"

Benjol
la source
5

Refactoring - c'est comme organiser votre armoire à vêtements / tiroir à outils.

  • Vous ne jetez pas vos vêtements / outils juste parce qu'ils sont partout.

  • Vous pourriez argumenter qu'ils ne devraient jamais se désorganiser. Mais ils le font.

Tout comme le code. Surtout que ça grandit avec le temps.

Et si vous ne le nettoyez pas, vous continuerez à vous demander ce qui est arrivé à ce t-shirt que vous avez aimé ou à cette clé que vous avez toujours besoin mais que vous ne pouvez jamais trouver!

Jagmag
la source
4

Je dirais "maintenance du code" . Il est important d'utiliser des mots familiers à la personne non technique et utiles pour une vision du monde non technique. Si un utilisateur non technique (client) est familiarisé avec la maintenance des applications, il est facile de faire en parallèle la maintenance du code et la maintenance des applications. Même s’ils ne sont pas identiques, vous pouvez expliquer au client final que ce sont les développeurs ou ceux qui assurent la maintenance du système.

Amir Rezaei
la source
1
Les personnes non techniques connaissent la maintenance des applications? J'ai demandé à ma grand-mère: elle n'est pas ans, c'est la personne la moins technique que j'ai trouvée. De plus: comme une personne non technique ne connaît pas la différence entre code et application ("Si le code est l'application, l'application est le code"), votre analogie ne fonctionnera pas.
Martin
2
Aux endroits où j'ai travaillé, les types marketing et projman ont compris que «maintenance» signifiait «corrections de bogues après publication», et il serait fallacieux de prétendre que le refactoring corrige des bogues.
Pour moi, la personne non technique est le client. Si le client sait en quoi consiste la maintenance des applications, il doit également comprendre la maintenance du code.
Amir Rezaei
La "maintenance du code" sonne comme si votre code était soumis à une usure ou s'usait. Une voiture doit être entretenue, car une utilisation normale contraint ses composants, consomme beaucoup de liquide, etc. Une application n'est pas comme ça: un code assis sur un disque dur ne "vieillit" ni ne "se détériore" tout seul.
Dan Ray
Je vais vous donner un exemple en matière de maintenance: problèmes de performances. Votre composant, tout votre système ou votre application est écrit en VB et Microsoft cesse de le prendre en charge. Le système d'exploitation ne prend pas en charge la technologie sur laquelle votre code est basé. Problèmes de sécurité. La maintenance de ces problèmes n’ajoute aucune nouvelle fonctionnalité susceptible d’être remarquée par l’utilisateur final, mais ils sont essentiels à la préservation de «l’application».
Amir Rezaei
4

Supposons que vous soyez un mécanicien spécialisé dans la personnalisation de voitures, même à partir de zéro, si le client le souhaite. Il y a ce client qui revient dans votre magasin de temps en temps pour mettre toujours quelque chose de brillant dans sa limousine géante.

Une fois, il vient pour faire installer un bon système de son. Vous effectuez avec diligence la tâche en passant les câbles et en les connectant correctement. Il sort un jour plus tard, il est heureux et paie généreusement, comme d'habitude.

Le mois suivant, il revient, mais cette fois, il souhaite installer un cinéma maison complet. Encore une fois, vous prenez la limousine. En tant que professionnel, vous revisitez le système audio et vous en simplifiez la maintenance en installant un système de tubes pour passer les câbles autour de la voiture. De cette façon, les fils sont protégés et plus faciles à retirer. Si vous devez en ajouter d'autres, ils seront également faciles à faire. Donc, vous déchirez les vieux fils, installez le tube et transmettez le système audio et les fils supplémentaires pour le cinéma, fermez le tout et vous avez terminé.

En réalisant que le client ne vous a pas demandé de remplacer l’ancien système audio, vous effacez une partie du coût des remplacements et des tubes. Cependant, vous gagnez encore de l'argent grâce à cet accord, mais pas autant que si vous aviez simplement jeté le système ensemble, comme vous l'avez fait la première fois.

Un mois plus tard, il revient, cette fois, il veut un système d'éclairage et il veut que les nouveaux haut-parleurs aient endommagé les anciens plus tôt dans la semaine.

Parce que tout est bien rangé, vous pouvez rapidement passer les nouveaux câbles d'éclairage dans votre tube, installer le système et remplacer le haut-parleur. Cependant, cette fois, vous avez terminé beaucoup plus rapidement, la reconfiguration a porté ses fruits en vous permettant de rester au top de votre forme.

Votre concurrent qui se moquait de vous pour avoir déchiré parfaitement les fils et pour installer tous ces tubes supplémentaires a toujours du mal à satisfaire son client. Il a certes été fait plus vite que vous la plupart du temps, mais avec le temps, ses clients se plaignent de la multiplication des retards et de la dégradation de la qualité globale du travail.

En regardant cela, vous réalisez que votre objectif, non seulement de rester dans l'entreprise, mais d'être le meilleur des armes à feu, est de trouver un équilibre entre ce que vous faites pour satisfaire les demandes de vos clients et ce que vous faites pour vous simplifier la vie. Très rarement, un client paiera les deux, vous devez donc gérer de près. Vous faites le pari que si vous agissez de manière proactive même si vous doublez les coûts, vous maintenez les coûts de maintenance à un pourcentage stable et contrôlé de votre productivité.

Le logiciel est identique, sauf que les programmeurs peuvent jouer avec le ruban adhésif numérique pendant TRES longtemps avant que les effets ne soient réellement ressentis par les clients et les gestionnaires. Malheureusement, à ce moment-là, le coût d'une nouvelle manipulation augmente de manière exponentielle en fonction de la quantité de ruban adhésif en place et de l'âge moyen dudit ruban.

C'est pourquoi il est important de continuer à restructurer le système. Très souvent, l'expérience nous montrera un nouveau moyen plus efficace de faire la même chose ou nous pouvons combiner des fonctionnalités similaires et exploiter les redondances au lieu de simplement les copier. C'est ainsi que nous maintenons le système mince et méchant. Le temps montrera qu'une refacturation constante du système pour répondre aux demandes maintiendra la productivité constante en contrôlant la quantité mise en maintenance.

La pose de ruban adhésif augmente momentanément la productivité au détriment du transport d’un système sous-optimal. Une dette technique est contractée chaque fois que la productivité immédiate est favorisée au détriment des autres aspects d’un système. L'analogie de la dette est bonne parce que, tout comme les intérêts sur le capital emprunté réduisent les profits, le temps emprunté pour faire des choses nécessite rapidement une maintenance plus importante et augmente la fragilité du système, forçant une équipe à dépenser des ressources supplémentaires pour la maintenance plutôt que pour la création. Tout comme son parent financier, si l'emprunt continue sans relâche, la plupart des ressources sont dépensées pour le remboursement des intérêts, ce qui laisse très peu de choses à améliorer. La dette technique grugera les ressources techniques à un point tel que la plupart des ressources sont dépensées pour que le système continue de fonctionner à toute vitesse, mettant un terme à toutes les autres améliorations possibles.

En fin de compte, la question est de ne pas savoir si nous devrions ou ne devrions pas le faire, mais s'il est éthique de laisser les gestionnaires et les clients croire qu'ils peuvent compter sur des chiffres de productivité artificiellement gonflés par l'utilisation de ruban adhésif. Certains penseraient que c'est une décision commerciale, mais franchement, c'est parce que les gestionnaires ne la comprennent pas. En fin de compte, quelqu'un devra payer la dette, que ce soit par le biais d'une restructuration lourde ou par la migration vers un nouveau système. C’est finalement à nous, programmeurs, de garder les systèmes maintenables, vous ne devriez pas avoir à demander de re-factoriser car c’est une partie inhérente du travail; ne pas comprendre cela, c’est ne pas comprendre ce qu'est le génie logiciel. Cela dit, je me rends compte que certains systèmes ont déjà contracté une dette importante et que le remboursement de cette dette nécessitera des décisions des payeurs. Votre travail consiste à au moins faire votre part pour arrêter d’emprunter. Cette dette a été contractéePAR NOUS, peut - être parce que nous ne savions pas mieux, parce que nous avions subi des pressions pour le faire, nous avons néanmoins contracté cette dette et très souvent, les personnes à qui nous avons confié la dette ne la comprennent pas et ne peuvent donc pas la gérer correctement.

Voici votre logiciel, tout est fait, j'espère que vous l'aimez ... Ho, au fait, j'ai utilisé votre carte de crédit au maximum, j'espère que cela ne vous dérange pas ... cya

Newtopien
la source
3

Le re-factorisation a pour objectif de simplifier la conception et de supprimer les inefficacités. Cela facilite la correction des bogues et l’ajout de nouvelles fonctionnalités à l’avenir.

Le débogage est deux fois plus difficile que d'écrire le code en premier lieu. Par conséquent, si vous écrivez le code aussi intelligemment que possible, vous n'êtes pas, par définition, assez intelligent pour le déboguer.

Si vous continuez à ajouter de nouvelles fonctionnalités au code, la refactorisation sera rapidement rentabilisée. Cela sera visible avec un taux d'erreur plus bas, un débogage plus rapide et des correctifs plus rapides.

cmcginty
la source
Mais clever == 0alors 2 * clever == 0...
Thomas Eding
3

L'écriture d'un logiciel est un peu comme écrire un gros livre de non-fiction ou une encyclopédie.

Le premier projet est toujours nul. Vous pouvez toujours l'améliorer en le réorganisant, en supprimant les sections inutiles et en veillant à la cohérence du style.

Chaque fois que vous devez réviser, la chose la plus simple à faire est simplement d’ajouter une nouvelle section, de changer quelques mots, etc. Mais au fur et à mesure que les révisions s'accumulent, le livre commence à perdre de son organisation. Donc, vous devez faire d'autres passes de réorganisation. Si vous ne le faites pas, le livre devient un fouillis insensé.

Kristopher Johnson
la source
3

Prenez votre ordinateur de bureau par exemple. Vous avez une tour, un moniteur, un clavier, une souris, une imprimante, un scanner et des haut-parleurs. En fin de compte, tout ce que vous voulez, c'est un bon bureau organisé. Donc, il vous suffit de brancher les choses à l’aveugle et, quelques minutes plus tard, tout est organisé comme vous le souhaitez. Eh bien ... presque comme tu le veux.

Un jour plus tard, lorsque vous modifiez la balance de vos haut-parleurs, vous réalisez que vous avez accidentellement placé vos haut-parleurs gauche et droit dans les mauvaises zones et que vous souhaitez échanger leurs positions. Mais oh non! Il y a une jungle de cordes enchevêtrées; lorsque vous déplacez les haut-parleurs, le cordon de votre souris devient accroché et maintenant, votre souris est déplacée avec les haut-parleurs. De plus, votre clavier n'a plus de mou - vous pouviez auparavant le déplacer du bureau sur vos genoux.

Très bien, vous pouvez simplement débrancher la souris et le clavier et les réinsérer pour que tout soit réparé. Mais cela n’aidera pas les réorganisations futures et les ajouts futurs. Il est également fastidieux de tisser des cordons de souris et de clavier dans la jungle.

La meilleure solution consiste à tout rebrancher pour les rebrancher de manière nette, sans encombrer les câbles. Maintenant, les modifications futures sont faciles et continuent de l'être. Vous investissez un peu à l’avance pour de gros gains plus tard.

Le point clé est que la solution originale a principalement travaillé. C’est le problème de la refactorisation: cela fonctionne au départ, mais vous devez changer la façon dont les choses existent déjà pour apporter facilement des modifications futures (déplacement des haut-parleurs).

Thomas Eding
la source
2

C'est un peu comme nettoyer la maison après une fête sauvage et folle de la nuit précédente.

Supposons que le salon soit totalement détruit. La maison est toujours une maison, le salon est toujours un salon. Cela fonctionne, mais ce n'est pas comme cela pourrait être. Après avoir regardé le désordre, vous réalisez qu'il doit être nettoyé.

Alors, vous commencez à mettre la corbeille en sac. Cela semble déjà mieux. Alors, vous regardez autour de vous et décidez de redresser les meubles. Vous mettez un morceau en arrière, puis le suivant et le suivant. Wow, la chambre a l'air vraiment bien. Vous êtes fier.

Votre sœur entre et dit que la pièce ressemble à une poubelle, vous devriez réparer l'étagère et passer l'aspirateur sur le tapis. Elle a raison. La salle a l'air vraiment, vraiment bien.

Vous regardez autour de vous et voyez que les stores de la fenêtre seraient beaucoup mieux s'ils étaient tous à la même hauteur. Terminé. Wow, la salle est incroyable.

Traitez votre code de la même manière.

Michael Riley - AKA Gunny
la source
1
J'aime ça, mais je changerais pour nettoyer la cuisine. Pas de cuisine pendant un moment, mais les choses iront mieux par la suite. Les PHB peuvent avoir des difficultés à organiser une fête le temps passé en entreprise :)
Jaap
Analogie décente, mais il y a un défaut que les lecteurs devraient connaître: si vous ne nettoyez pas votre maison, celle-ci devient alors de moins en moins utilisable avec le temps. Alors qu'avec un programme, cela n'arrive pas.
Thomas Eding
1

Facile!

Prenons-le avec un exemple ... chacun a écrit dans sa vie une lettre à un être cher. Ce doit être une personne chère, car dans ces lettres, nous prêtons également une attention particulière à la composition.

Donc, vous avez votre texte, ... le sens va aller dans les deux sens, mais vous voulez que le tout sonne bien! Droite?

Refactoring, même chose ... mêmes informations, plus ou moins, mais la composition est meilleure. Et cela entraînera probablement une meilleure relecture par le lecteur.

Un autre exemple - écrire un article pour un magazine. Deux écrivains, tous deux connaissent "leur métier", la seule différence est que l'un sait "comment écrire" et l'autre écrit comme il a appris à écrire à partir de réponses comme celles-ci.

De quel article te souviendras-tu?

Tour
la source
1

Toutes les analogies avec les choses du monde physique - comme construire un théâtre - sont, OMI, terribles.

Vous devez expliquer que le code de refactoring est semblable à ... un code de refactoring. Le logiciel est malléable de la même manière que les analogues physiques. Au fur et à mesure que les choses deviennent de plus en plus complexes, il faut réactiver (ou refaire, à votre guise) des parties volumineuses ou petites d'une base de code afin de pouvoir continuer à augmenter la complexité sans pour autant devenir fou.

Pourquoi avons-nous refactor? Parce que le code qui n'est jamais refactorisé coûte plus cher par minute à maintenir et à modifier, et devient finalement plus problématique.

Ce qui est intéressant à propos de la refactorisation, c’est que nous avons refait la base de code mais, au moins au début, la fonctionnalité reste la même.

Yar
la source
/ Toutes les analogies /? Je suis fortement en désaccord. Vous avez juste besoin d'être plus créatif. Aussi ne répond pas à la question du PO.
Thomas Eding le
@ThomasEding merci pour votre commentaire. Je suis en désaccord sur le deuxième point: je réponds en fait à la question. Cependant, je vais faire une modification maintenant juste pour vous.
Dan Rosenstark
0

La refactorisation est la même chose que nettoyer quelque chose et donner un nouveau lieu de séjour

Facile simple et quelque chose qui peut prendre beaucoup de temps. Parfois, j'ajoute même que cette personne X a laissé un désordre énorme et que je dois tout nettoyer.

Barfieldmv
la source
0

J'ai pensé à un autre exemple, que personne ici n'a apparemment mentionné: la refactorisation est à peu près la même chose que le réarrangement d'une équation mathématique (bien que cela puisse tomber en dehors du domaine des "personnes non techniques, je suppose)".

Lorsque vous réorganisez une équation, il vous suffit de "déplacer des éléments" pour la rendre plus lisible et plus utilisable, sans en changer le sens .

Benjol
la source
1
Donc, si je suis un client PHB ou un client (qui va payer pour cet effort de refactoring), pourquoi devrais-je m'en soucier? Le code fonctionne (de mon point de vue)
Dan Pichelman le
0

Donnez-leur une équation mathématique simple. Par exemple:

Lequel est plus simple?

y = x + x

ou

y = 2x

Le refactoring est un concept similaire sauf que, au lieu d'équations mathématiques simples, vous mettez des algorithmes. L'idée principale est que vous pouvez permuter entre deux façons de faire car elles donneront le même résultat.

Le refactoring le plus simple qui puisse être fait est le renommage.

doX() { ... }
{
   doX()
}

Maintenant, parce que nous ne voulons pas vraiment que les choses s'appellent doX car nous ne savons pas vraiment ce que cela signifie, nous le renommons en autre chose plus explicite et nous le remplaçons partout où nous l'avons utilisé.

doBusinessTransaction() { ... }
{
   doBusinessTransaction()
}

Cela vous permettra d'économiser de l'argent par la suite en cas de problème ou d'amélioration, car cela réduira le temps nécessaire à la compréhension et à la correction de votre application. Pour économiser encore plus d’argent, certains outils gratuits fonctionnent automatiquement pour vous en fonction de la langue que vous utilisez. Ces outils sont également concédés sous licence, de sorte qu’ils ne sont pas restrictifs et vous obligeraient à faire quelque chose de spécial en plus de les reconnaître si vous les utilisez directement.

Archimedes Trajano
la source
1
J'aime beaucoup cette analogie car elle est compréhensible par tout le monde et ressemble beaucoup au code lui-même.
Venkat D.
Merci, je l'ai même posté sur mon blog aussi trajano.net/2013/05/refactoring-explained
Archimedes Trajano
0

Une image dit mille mots. Par exemple, le refactoring a deux cas d'utilisation:

  • Quand les choses ne sont pas bien faites la première fois:

refactoring lorsque les choses ne sont pas bien faites la première fois

  • Quand les choses sont fastidieuses:

refactoring quand les choses sont fastidieuses

Références

Paul Sweatte
la source
XKCD vaut le coup d'ignorer le fait que rendre une tâche de routine plus efficace peut signifier que vous finissez par en faire beaucoup plus que ce que vous auriez autrement fait. Vous devez donc prendre en compte la valeur des performances supplémentaires de la tâche.
bdsl
@bdsl qui est couvert sur workplace.se
Paul Sweatte
0

Considérez une réponse donnée dans Refactoring et ne l'expliquez pas à une personne non technique. Le refactoring est une activité technique dont ils n'ont pas besoin de savoir:

Bien sûr, beaucoup de gens disent qu’ils sont motivés par la qualité mais plus par l’échéancier. Dans ces cas, je donne mon conseil le plus controversé: ne le dites pas!

Subversif? Je ne pense pas. Les développeurs de logiciels sont des professionnels. Notre travail consiste à créer des logiciels efficaces aussi rapidement que possible. … Un gestionnaire axé sur les horaires veut que je fasse les choses le plus rapidement possible; comment je le fais c'est mon affaire. Le moyen le plus rapide est de refactoriser; donc je refactorise.

(Refactoring, Martin Fowler, 2000, page 61)

Bien sûr, cela ne fonctionnera pas si vous passez un mois à ne faire que refactoriser, mais je pense que c'est généralement une mauvaise idée de toute façon, et il est bien mieux de simplement refactoriser dans la mesure nécessaire pour faciliter votre tâche actuelle ou suivante. , ou pour nettoyer le code avec lequel vous venez de travailler.

bdsl
la source