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

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

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

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.

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

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

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.

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

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 ¹ [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.

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

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!

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.

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

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.

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

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

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.

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?

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.

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.

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 .

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.

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:

• Quand les choses sont fastidieuses:

Références

• xkcd: bon code

• xkcd: ça vaut le temps?

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.