Qu'est-ce qu'une bonne métaphore de programmation? [fermé]

Je parle d'expliquer au non-programmeur ce qu'est la programmation. J'ai veillé à rechercher des questions similaires avant de créer celle-ci, mais les quelques-unes que j'ai trouvées semblaient esquiver la question, et j'aimerais spécifiquement voir des métaphores ou des analogies. Personnellement, je trouve plus facile d'expliquer quelque chose de technique à quelqu'un en utilisant des métaphores ou des analogies.

La raison pour laquelle je m'intéresse à cela est que de nombreuses personnes rencontrent quotidiennement le travail d'un programmeur, mais si vous demandez à la personne moyenne ce qu'est ou fait un programmeur, elle ne sait pas vraiment. Cela conduit à certaines situations de malentendu (ex. "[...] mais je pensais que vous étiez bon avec les ordinateurs!")

J'aimerais vraiment trouver le meilleur sur le marché. J'aimerais pouvoir expliquer facilement à quelqu'un en quoi consiste mon choix de carrière. Bien sûr, au moins l'idée générale.

Personnellement, je n'en ai pas de solide, mais j'y ai longtemps réfléchi et j'ai généralement gravité vers la métaphore du `` langage '', où nous connaissons un langage que les ordinateurs comprennent, et donc nous pouvons dire aux ordinateurs quoi faire, ou "leur apprendre", pour résoudre nos problèmes.

Par exemple:

Imaginez que dans une réalité alternative, des robots humanoïdes dotés d'une intelligence artificielle existent, et certaines personnes sont capables de communiquer avec eux à travers un langage commun, qui est une variante de l'anglais. Ces personnes qui peuvent communiquer avec les robots peuvent leur apprendre à résoudre certains problèmes ou à effectuer certaines tâches, comme faire nos tâches ménagères.

Eh bien, bien que de tels robots n'existent pas encore, les programmeurs de notre temps sont comme ces gens, mais au lieu de communiquer avec les robots, ils communiquent avec les ordinateurs. Les programmeurs "apprennent" aux ordinateurs comment effectuer certaines tâches ou résoudre certains problèmes au moyen de logiciels qu'ils créent en utilisant ce "langage commun".

Les programmeurs et ce «langage commun» sont ce qui nous donne des choses comme le courrier électronique, les sites Web, les jeux vidéo, les traitements de texte, les téléphones intelligents ( pour le dire simplement ), et bien d'autres choses que nous utilisons quotidiennement.

Je ne veux pas mettre de programmation sur le trône ou quoi que ce soit, c'est juste la meilleure métaphore que j'ai pu trouver.

Je suis sûr que quelqu'un trouvera un problème avec celui-ci, il est probablement un peu artificiel, mais là encore, c'est pourquoi je pose cette question.

C'est comme avoir à écrire des instructions détaillées étape par étape pour savoir comment conduire quelque part. Mais vous devez généralement ajouter des plans d'urgence pour des choses comme «et s'il y a un embouteillage» ou «et si un camion tombe en panne dans la voie de virage».

Et parfois, vous devez plonger encore plus profondément et expliquer les règles de la route, par exemple de quel côté conduire ou quoi faire au feu rouge. Et parfois, vous devez même expliquer précisément comment fonctionne le volant ou la pédale d'accélérateur.

Et généralement, une fois que vous avez tout décrit en détail, le client dit "c'est parfait, sauf qu'il doit fonctionner pour quelqu'un qui conduit un aéroglisseur"

J'écris des instructions très, très détaillées pour une machine très, très stupide.

J'utilise la métaphore «Nous écrivons des recettes de tricot » qui est conviviale pour grand-mère.

Raisonnement:

• Le tricot est un processus mécanique assez simple où vous devez essentiellement suivre des instructions détaillées exactement pour en tirer quelque chose.
• La plupart des instructions de tricot sont pour plusieurs tailles. Cela vous donne des ifinstructions et des mathématiques et des boucles.
• Vous pouvez trouver l'erreur dans la recette lorsque l'armée des grands-mères en colère vient avec ses pulls buggy!

Pas très bonne analogie mais quand les gens me disent de réparer leur machine je dis "Je suis le gars qui conçoit les voitures. Je ne suis pas le mécanicien!"

Enfant, j'ai lu une très bonne description de la programmation: c'est comme dire à un robot comment faire une tâche courante, comme aller à l'école. Vous pouvez donc lui dire "Allez à l'école!", Mais il ne sait pas comment. Vous lui dites donc de "sortir, prendre à gauche, continuer à marcher jusqu'à ce que vous arriviez à l'école, prendre à gauche, entrer et vous asseoir". Mais il y a une route sur le chemin! Il faut donc lui dire de "s'arrêter sur la route, vérifier qu'il n'y a pas de circulation, traverser la route et continuer à marcher" quelque part au milieu là-bas. Et les portes? Vous ajoutez donc "vérifiez si la porte de l'école est ouverte. Si ce n'est pas le cas, ouvrez-la". là-dedans. Finalement, vous avez un programme qui peut dire à votre robot comment se rendre à l'école par lui-même.

Cela s'harmonise très bien avec Logo, où vous demandez à la tortue exactement de cette façon de créer des formes complexes.

La programmation est comme une boîte de chocolats . Parfois, vous trouvez tout de suite ce que vous cherchez, mais la plupart du temps cela prend beaucoup d'essais et d'erreurs. Parfois, vous obtenez de la noix de coco.

Feux de circulation . Les voitures bougent ou s'arrêtent. Un feu de circulation est facile à imaginer, mais que se passe-t-il si vous en ajoutez un autre? Et un tiers? Et une ville entière? Un système de transport en commun est composé de milliers de feux stop, chacun simple en soi, mais pris dans son ensemble, il devient un système complexe. Si l'un de ces feux de signalisation ne fonctionne pas correctement ou s'éteint de quelques secondes, il plonge tout le système dans le chaos. Si tout est synchronisé, vous profitez simplement de la balade.

Un conférencier motivateur trouve les clés pour ouvrir le puzzle des motivations, des rêves et des idées des gens. Chaque situation, chaque personne est différente. Ce qui a fonctionné dans le passé n'est peut-être pas approprié maintenant. Parfois, une clé peut être réutilisée, mais doit être adaptée à l'individu. D'autres fois, la clé doit être refaite. Ce qui est le plus gratifiant, c'est lorsque la personne a été déverrouillée et que vous la voyez sortir et conquérir le monde. Le plus dévastateur est lorsque vous vous sentez proche, mais que vous n'êtes tout simplement pas en mesure de libérer le potentiel.

Une histoire de détective , où le détective construit lentement son cas en recherchant des indices et en rassemblant des preuves. Méthodique, intelligent et précis l'emportera. Sloppy, ignorant et paresseux condamnera l'affaire. Finalement, le travail se tiendra ou tombera devant un jury de pairs.

Une machine à sous . Vous mettez toutes vos pièces et tirez sur le levier. Parfois, vous gagnez gros, parfois vous restez assis pendant des heures et rien ne se passe. Parfois, quelqu'un d'autre passe nonchalamment, tire une fois sur le levier et remporte le jackpot.

La musique . Une note est assez simple, mais une mesure est plus complexe. Une chanson complète a de nombreuses mesures avec de nombreuses notes. Si une note est désactivée, cela peut ruiner toute la performance. Si chaque note est parfaitement livrée, la performance s'estompe en arrière-plan et seule la musique existe.

La meilleure métaphore de tout est elle-même. Tout autre élément perdra une certaine précision. En tant que tel, choisir la meilleure métaphore dépend de ce que vous voulez capturer spécifiquement sur la programmation. Puisqu'il y aura beaucoup de réponses ici sur le codage des métaphores, je répondrai avec la métaphore classique pour le processus de développement dans son ensemble:

Construction de bâtiments

L'aspect le plus courant de cette métaphore est qu'un architecte physique est quelque peu analogue à un architecte logiciel. Voici quelques autres parallèles:

• Les modifications sont de moins en moins coûteuses à mesure que vous les effectuez. Autrement dit, vous pouvez déplacer une ligne sur papier maintenant ou 10 tonnes de ciment plus tard.
• Un bâtiment sans plan approprié aura tendance à s'effondrer
• Les constructeurs tentent d'implémenter ce que le client veut. Si le client ne décrit pas exactement à quoi il veut que le bâtiment ressemble (ou s'il y a un autre échec de communication), il sera coûteux de changer.
• Il existe certaines lois de la physique qui ne peuvent pas être pliées. Tout comme un deuxième étage de trois cents pieds de large ne peut pas être construit sur un premier étage de 100 pieds de large, la fonctionnalité X ne peut pas être construite sans un sous-système robuste Y.

Bien sûr, comme toute métaphore, elle a ses limites. Quelques défauts:

• Les bâtiments sont à usage unique; vous le construisez quelque part, et il y reste. Vous ne pouvez pas le copier un million de fois pour un million d'utilisateurs différents avec un million de besoins différents à un coût incrémentiel nul.
• Les bâtiments sont considérablement plus immuables que les logiciels.
• Il n'y a aucune analogie claire avec le coût des matériaux de construction. Une ligne de code ne coûte rien - seul le temps qu'il faut pour la produire coûte de l'argent.
• L'architecture incrémentielle qui est (selon qui vous demandez) possible avec le logiciel n'est pas possible avec la construction, où vous la concevez une fois, puis construisez-la.

Donc, comme toute analogie, cela dépend de ce que vous essayez d'expliquer. Méfiez-vous de trop compter sur une métaphore ou votre client commencera à se demander quels seront les impôts fonciers sur son nouveau système de paie.

J'aime l' analogie de Chris McMahon avec le développement de logiciels comme la création de musique, en particulier la musique jazz.

Il s'agit d'Ella Fitzgerald et de Count Basie qui interprètent la chanson One O'Clock Jump. La chanson est un blues à douze mesures, qui est l'équivalent jazz d'une application de base de données avec une interface utilisateur. J'entends par là: tout comme chaque programmeur a construit une application de base de données avec une interface utilisateur, chaque musicien américain a joué du blues à douze mesures. C'est un cadre sur lequel de nombreuses chansons sont accrochées, de Count Basie à Jimi Hendrix en passant par les Ramones.

Cette vidéo particulière est un excellent exemple de pratique agile. Écoutez comment la voix et le piano s'influencent mutuellement. Cela ressemble beaucoup à la programmation par paires et ressemble beaucoup à TDD: la voix fait quelque chose; le piano répond; le piano fait quelque chose; répond la voix. Et remarquez le contact visuel. Ces personnes sont profondément conscientes de ce qui se passe instantanément. Ils n'ont pas de partitions (BDUF). Ils sont impliqués dans une activité qui demande une concentration et des compétences intenses, tout comme un bon développement logiciel. Ils sont également clairement conscients qu'il y a un public, tout comme un bon développement logiciel doit être conscient des besoins des personnes qui paient les factures.

Voici le lien vers le billet de blog dans lequel il en discute: http://chrismcmahonsblog.blogspot.com/2007/05/example-of-analogy-monks-vs-music.html

Parfois, je fais référence à la programmation comme au contrôle des zombies stupides . Résumant mon article de blog à ce sujet:

• Comme les zombies, les ordinateurs avec lesquels nous fonctionnons sont très stupides. Il est difficile de leur demander de faire quoi que ce soit à moins que les instructions ne soient détaillées
• Le zombie est agressif et si nous manquons de petits détails dans les instructions, laissez la créature sans contrôle, il peut tout écraser autour de lui. La même chose avec les ordinateurs: un manque de détails dans les instructions peut faire planter votre programme et détruire vos données.
• Vous devez connaître la magie si vous voulez contrôler un zombie. La même chose avec la programmation.
• Plus il y a de cerveaux au même endroit, plus ils ont d'ordinateurs. Il semble que les cerveaux attirent les ordinateurs - de la même manière qu'ils attirent les zombies.

La programmation, c'est comme construire des choses avec Lego :

• Vous collez beaucoup de petits morceaux ensemble pour faire de plus grandes choses
• Les petits morceaux viennent dans un nombre limité de formes et de tailles
• Les petites choses ne peuvent s'emboîter que de certaines façons
• Jouer avec ces trucs peut être très amusant

Programmer un ordinateur, c'est comme élever un enfant ...

• Tout le monde n'est pas d'accord sur la bonne façon de le faire
• Il vous tient éveillé la nuit
• Il ne fait jamais ce que vous lui dites
• Peu importe le nombre de livres que vous lisez sur le sujet, quand vous allez le faire, vous vous sentez comme si vous n'aviez aucune idée de ce que vous faites
• Après un certain temps, vous avez tendance à devenir paresseux
• Vous vous attendez à ce qu'il ait de grands rendements à l'avenir, mais vous finissez par devoir le maintenir jusqu'à sa fin de vie
• Ce n'est jamais aussi propre, intelligent ou sécurisé que vous le vouliez
• Lorsque vous y repensez plus tard, vous vous demandez à quoi diable vous pensiez
• Malgré tout le stress que cela vous a causé, vous l'aimez quand même.

La principale différence est que nous nous fâchons si quelqu'un vole notre code source, mais nous sommes souvent heureux d'avoir quelqu'un pour nous enlever nos enfants.

La programmation, c'est comme construire une usine ou une chaîne de montage.

Considérez le logiciel comme une machine ou une chaîne de montage qui existe à l'intérieur de l'ordinateur. Certaines matières premières et certains composants sont introduits dans la machine, et il suit un ensemble de procédures pour les transformer en un produit final. Les procédures sont configurées pour effectuer une opération spécifique sur une matière première ou un composant selon un ensemble spécifique de paramètres (par exemple, le temps, la température, la distance, etc.) dans un ordre particulier. Si les détails de l'opération à effectuer étaient incorrects, ou si les capteurs de la machine ne sont pas correctement étalonnés, ou si une matière première ou un composant n'était pas conforme aux normes de qualité attendues, cela pourrait changer le résultat de l'opération et le produit ne tournerait pas comme prévu.

Une telle machine est très rigide dans son fonctionnement et possède des entrées acceptables. Les machines ne remettent pas en cause l'intelligence des concepteurs ni son environnement d'exploitation actuel. Il continuera de suivre les procédures tant qu'il lui sera adressé. Même si un changement de matières premières ou de composants pouvait avoir un effet drastique sur ce qui s'est passé lors d'opérations ultérieures, la machine continuerait à exécuter ses procédures. Le processus devrait être revu pour voir quelles modifications aux procédures étaient nécessaires pour compenser et produire le résultat souhaité. Une modification de la conception ou de la configuration du produit peut également nécessiter une modification importante des opérations effectuées ou de leur commande. Bien que les responsables de la production aient rapidement compris l'importance d'isoler autant que possible les opérations pour réduire les effets indésirables entre elles, un grand nombre d'hypothèses sont faites quant à l'état des composants pendant leur traitement; hypothèses qui pourraient ne pas être détectées tant que le produit final n'est pas entre les mains de l'utilisateur dans un environnement d'exploitation différent.

Aider un idiot rapide à réussir un cours de mathématiques qui nécessite un essai écrit.

La programmation informatique, c'est comme jouer à un jeu d'échecs dans lequel la taille du plateau, le nombre de pièces en jeu et les règles qui régissent ces pièces augmentent en taille et en complexité au fur et à mesure du jeu.

Le logiciel d'écriture, c'est comme ... l'écriture! ^^

Les nouveaux étudiants dans les classes CS / Programmation sont, pratiquement, comme des utilisateurs non programmeurs. L'exemple du robot est bon.

Dans les années 80, l'utilisation de Logo, Karel (ou d'environnements de programmation similaires), où l'utilisateur apprend à programmer, en regardant l'ordinateur comme un robot, au lieu d'un téléviseur avec une machine à écrire, a beaucoup aidé. Ces outils étaient couramment utilisés au collège et au lycée.

Cette programmation pratique a aidé les élèves à acquérir des compétences en résolution de problèmes, même s'ils n'étaient pas liés à l'ordinateur !!!

Ou, même si les étudiants ne sont pas devenus programmeurs.

Certains collèges et universités ont également appliqué ces outils dans les cours de première année.

Je me demande pourquoi de nombreux lycées abandonnent l'enseignement Logo et Karel ...

J'aime l'analogie avec Fred Brooks, du Mythical Man-Month, que la programmation est comme faire de la magie.

(La) construction du programme, contrairement aux mots du poète, est réelle dans le sens où elle se déplace et fonctionne, produisant une sortie visible distincte de la construction elle-même. Il imprime les résultats, dessine des images, produit des sons, bouge les bras. La magie du mythe et de la légende s'est réalisée à notre époque. On tape la bonne incantation sur un clavier, et un écran d'affichage prend vie, montrant des choses qui n'ont jamais été ni ne pourraient l'être. ...

(Un) doit fonctionner correctement. L'ordinateur ressemble aussi à la magie du mythe et de la légende à cet égard. Si un personnage, une pause de l'incantation n'est pas strictement en bonne forme, la magie ne fonctionne pas. Les êtres humains n'ont pas l'habitude d'être parfaits et peu de domaines d'activité humaine l'exigent. S'adapter à l'exigence de perfection est, je pense, la partie la plus difficile de l'apprentissage de la programmation.

"[...] mais je pensais que tu étais bon avec les ordinateurs!"

Il s'agit généralement d'une tentative pour inciter un geek à réparer un ordinateur (vous avez envie de lui prouver le contraire?). Ma réponse standard:
je suis programmeur. C'est comme un ingénieur automobile - il ne saura probablement pas comment réparer les freins de votre Trabant '72, et certainement pas s'il le savait. Un mécanicien ferait ça!

J'adore le concept d'une recette de cuisine.

La programmation, c'est comme utiliser des quantités énormes de puissance. Vous pouvez faire en sorte que l'ordinateur fasse tout ce que vous voulez. Vous n'êtes limité que par votre imagination et le temps que vous êtes prêt à investir.

Les programmeurs sont comme les créateurs d'une maison. Nous pouvons tout vous dire sur les maisons que nous avons construites. Pourtant, si vous nous demandez de demander une maison au hasard que nous traversons sur la route, il est probable que nous ne sachions pas grand-chose. Mais si vous avez besoin d'ajouter ou de modifier quelque chose dans cette maison, nous pouvons y arriver à condition que le propriétaire nous le permette.

Dans l'un des anciens articles de Chris Crawford sur la programmation, il a comparé un programme complexe à une bureaucratie, avec plusieurs agences qui communiquent en passant des notes de service. J'ai trouvé que c'était une métaphore très utile pour expliquer le développement de logiciels.

J'assimile généralement la programmation à un puzzle.

Pour créer un nouveau projet - vous avez des tonnes de pièces, dont deux n'appartiennent pas à cette image, et vous n'avez pas d'aperçu de ce à quoi ressemble le puzzle lorsqu'il est terminé. Mais vous connaissez la taille et les couleurs générales, donc des estimations sont possibles, mais pas nécessairement précises.

Pour modifier un projet déjà existant - un chat est venu et a fait tomber une partie du puzzle terminé. Cela prendra un certain temps, mais le cadre est déjà là, donc ça ne devrait pas être trop mauvais (selon la quantité à changer).

Il aide également à décrire les progrès. Un de mes projets récents, à un moment donné, je me demandais comment le décrire pour qu'une personne non technique comprenne pourquoi je ne sais pas combien de temps encore, et j'ai trouvé: Pensez à un puzzle où tous les les pièces de bordure sont terminées, tout comme un peu plus de la moitié des pièces intérieures. Ceux qui restent sont tous séparés les uns des autres, ce que je dois faire maintenant est de combler les lacunes.

C'est triste mais, la programmation est un travail qui ne peut être compris qu'en apprenant à le faire.

La programmation a plusieurs niveaux de perception différents et différents de différents côtés.

À bas niveau, il s'agit "d'écrire des instructions très, très détaillées pour une machine très, très stupide"

Au niveau suivant, il s'agit de la complexité. Construire une nouvelle métaphore pour simplifier le travail. Comme les mathématiques supérieures.

D'un autre côté, son utilisation de technologies auxiliaires comme le contrôle de version, le code auto-documenté, la construction de projets et les tests.

D'un autre côté, son interface utilisateur "construction" (pas littéralement, je veux dire API aussi UI), prédire les erreurs possibles (faites par l'utilisateur, les données ou même lui-même) et corriger correctement les erreurs.

Et enfin.

La métaphore de la programmation est la littérature. Il faut d'abord apprendre l'alphabet. Mais l'écriture d'un roman à cela ne commence même pas.