Citation de Torvalds sur un bon programmeur [fermé]

238

Je suis tombé par hasard sur la citation suivante de Linus Torvalds:

"Les mauvais programmeurs s'inquiètent du code. Les bons programmeurs s'inquiètent des structures de données et de leurs relations."

J'y réfléchis depuis quelques jours et je suis toujours confus (ce qui n'est probablement pas un bon signe), c'est pourquoi je voulais aborder les points suivants:

  • Quelle interprétation de ce possible / a du sens?
  • Que peut-on appliquer / apprendre de cela?
Beyeran
la source
18
Je pense que cette question a probablement plusieurs réponses qui sont également valables. Mais c'est quand même une bonne question. J'aime cette citation. Cela explique pourquoi je ne comprends pas les programmeurs qui s’inquiètent du changement de langue. Ce qui compte dans un programme, c'est rarement la langue, ce sont les structures de données et leurs relations.
Ryan Kinal
5
Peut-être que si vous prenez le temps de rendre les structures de données "élégantes", le code n'a pas besoin d'être compliqué pour traiter ces structures de données? Je suis probablement trop bête pour vraiment comprendre le sens de la citation de Torvalds. :}
programmeur
3
@RyanKinal Mais bien sûr, le langage est important , car il facilite considérablement la gestion et la réflexion de certaines structures de données. Pensez à toutes les langues spécialisées dans l'analyse syntaxique, par exemple, ou aux langues qui prennent en charge de manière native les structures de données qui doivent être piratées dans d'autres langues (des ensembles et des tableaux fragmentés viennent à l'esprit).
kojiro
83
Soit dit en passant, Torvalds n'est pas seul dans cette situation: "Montrez-moi votre organigramme et cachez vos tableaux, et je continuerai à être mystifié. Montrez-moi vos tableaux et je n'aurai généralement pas besoin de votre organigramme; ce sera évident. " - Fred Brooks, Le mois mythique de l'homme. "Montrez-moi votre code et cachez vos structures de données, et je continuerai à être mystifié. Montrez-moi vos structures de données, et je n'aurai généralement pas besoin de votre code; ce sera évident." et "Les structures de données intelligentes et le code muet fonctionnent beaucoup mieux que l'inverse." - Eric S. Raymond, La cathédrale et le bazar.
Jörg W Mittag
4
Ceci explique pourquoi le noyau Linux est en désordre :)
l1x le

Réponses:

326

Il serait peut-être utile de considérer ce que Torvalds a dit juste avant cela:

git a en fait une conception simple, avec des structures de données stables et raisonnablement bien documentées. En fait, je suis un fervent partisan de la conception de votre code autour des données, plutôt que l'inverse, et je pense que c'est l'une des raisons pour lesquelles git a eu assez de succès […] Je vais en fait dire que la différence entre un mauvais programmeur et un bon programmeur, il faut qu'il considère son code ou ses structures de données plus importants.

Ce qu'il dit, c'est que de bonnes structures de données rendent le code très facile à concevoir et à maintenir, alors que le meilleur code ne peut pas compenser les mauvaises structures de données.

Si vous vous interrogez sur l'exemple de git, de nombreux systèmes de contrôle de version changent leur format de données assez régulièrement pour prendre en charge de nouvelles fonctionnalités. Lorsque vous effectuez une mise à niveau pour obtenir la nouvelle fonctionnalité, vous devez souvent exécuter une sorte d’outil pour convertir également la base de données.

Par exemple, lorsque DVCS est devenu populaire, beaucoup de gens ne comprenaient pas ce que le modèle distribué permettait de fusionner de manière beaucoup plus nette qu'un contrôle de version centralisé. La réponse n’est absolument rien, sauf que les structures de données distribuées devaient être bien meilleures pour avoir l’espoir de fonctionner. Je crois que les algorithmes de fusion centralisés ont repris depuis, mais cela a pris beaucoup de temps car leurs anciennes structures de données limitaient le type d'algorithmes qu'ils pouvaient utiliser et les nouvelles structures de données cassaient beaucoup de code existant.

En revanche, malgré l’explosion de fonctionnalités dans git, les structures de données sous-jacentes n’ont pratiquement pas changé. Préoccupez-vous d'abord des structures de données et votre code sera naturellement plus propre.

Karl Bielefeldt
la source
25
le meilleur code ne peut compenser la faiblesse des structures de données, une bonne qualité est vrai
Conrad Frix
5
Il parle du point de vue des programmeurs apportant des modifications à git lui-même. Le point de vue de l'utilisateur final est complètement orthogonal à cette discussion, mis à part le fait que le code est facilement maintenable, réduisant ainsi le nombre de bogues et ajoutant des fonctionnalités plus rapidement.
Karl Bielefeldt
2
@ James: Il dit que le logiciel est meilleur (donc plus facile à utiliser et utilisé par plus de gens) parce que les structures de données sont meilleures. Bien entendu, vous n'avez pas besoin de connaître les structures de données des logiciels que vous utilisez, mais vous vous en souciez , indirectement, même si vous ne le réalisez pas, car ce sont les structures de données qui déterminent ce que vous réalisez. se soucier de.
Ruakh
1
+1 Cette réponse met le contexte sur une déclaration qui pourrait autrement être interprétée comme signifiant quelque chose de très différent. Quiconque a lu une monstruosité de 5000 lignes d'un fichier sait exactement ce que je veux dire.
Riwalk
20
"Préoccupez-vous d'abord des structures de données, et votre code sera naturellement plus propre.": L'homme d'État romain Cato ( en.wikipedia.org/wiki/Cato_the_Elder ) avait l'habitude de dire "Rem tene, verba sequentur" = "Avoir l'argument clair dans votre esprit, les mots suivront naturellement ". Même chose avec la programmation: comprendre les structures de données et la conception d’abord, le code réel suivra tout seul.
Giorgio
60

Algorithmes + Structures de Données = Programmes

Le code est juste le moyen d' exprimer les algorithmes et les structures de données.

zxcdw
la source
Dernière édition de ethoberon.ethz.ch/WirthPubl/AD.pdf
dchest
Ceci est vrai pour la programmation procédurale; en POO est un peu différent.
m3th0dman
3
Il est pas fondamentalement tout différent. Vous avez des données et effectuez un ensemble d'opérations dessus. Variables membres et méthodes. Exactement la même chose. L'essence même de l'informatique depuis les années 50 repose sur cette règle très simple selon laquelle les programmes sont constitués d'algorithmes modifiant les structures de données, et cela reste vrai 60 ans plus tard. Vous pouvez également considérer les programmes comme des fonctions . Ils prennent une entrée sur laquelle ils fonctionnent pour produire une sortie . Exactement comme le font les fonctions mathématiques.
zxcdw
31

Cette citation est très familière à l’une des règles de "L’art de la programmation Unix", qui est le fer de lance de Torvalds en tant que créateur de Linux. Le livre est en ligne ici

La citation suivante est tirée du livre et explique ce que dit Torvalds.

Règle de représentation: incorporez la connaissance aux données afin que la logique du programme puisse être stupide et robuste.

Même la plus simple logique procédurale est difficile à vérifier, mais des structures de données assez complexes sont assez faciles à modéliser et à raisonner. Pour voir cela, comparez l'expressivité et le pouvoir explicatif d'un diagramme d'un arbre de pointeur de cinquante nœuds avec un organigramme d'un programme de cinquante lignes. Vous pouvez également comparer un initialiseur de tableau exprimant une table de conversion avec une instruction switch équivalente. La différence de transparence et de clarté est spectaculaire. Voir la règle 5 de Rob Pike.

Les données sont plus faciles à manipuler que la logique du programme. Il s'ensuit que lorsque vous voyez le choix entre complexité dans les structures de données et complexité dans le code, choisissez le premier. Plus: lorsque vous modifiez une conception, vous devez rechercher activement des moyens de déplacer la complexité du code vers les données.

La communauté Unix n’a pas été à l’origine de cette idée, mais beaucoup de code Unix affiche son influence. La facilité du langage C à manipuler des pointeurs, en particulier, a encouragé l’utilisation de structures de référence modifiées de façon dynamique à tous les niveaux de codage, à partir du noyau. De simples poursuites au pointeur dans de telles structures font souvent des tâches que les implémentations dans d'autres langues devraient plutôt incorporer dans des procédures plus élaborées.

Jay Atkinson
la source
Je m'en suis souvenu aussi!
Jesvin Jose
1
OTOH, regardez toute question sur StackOverflow int**. Cela devrait vous convaincre que les données ne sont en réalité PAS évidentes; cela ne le devient qu'en attachant une signification aux données. Et cette signification est dans le code.
MSalters
29

Le code est facile, c'est la logique derrière le code qui est complexe.

Si vous vous préoccupez du code, cela signifie que vous ne maîtrisez pas encore ces bases et que vous êtes probablement perdu dans le complexe (par exemple, les structures de données et leurs relations).

Morons
la source
17
Heh, je me demande si la prochaine génération de programmeurs demandera: "Les crétins ont déjà dit Code is easy, it's the logic behind the code that is complex, qu'est-ce qu'il voulait dire?"
Yannis
36
@YannisRizos Ce sera particulièrement déroutant quand les gens ne savent pas s'il a été dit par les gens qui étaient des crétins, ou une seule personne par le nom de Morons.
KChaloux
14

Pour développer un peu la réponse de Morons , l’idée est que la compréhension des détails du code (syntaxe et, dans une moindre mesure, structure / mise en forme) est assez simple pour que nous puissions créer des outils capables de le faire. Les compilateurs peuvent comprendre tout ce qui doit être connu sur le code pour le transformer en programme / bibliothèque en état de fonctionnement. Mais un compilateur ne peut pas réellement résoudre les problèmes des programmeurs.

Vous pouvez pousser l'argument un peu plus loin et dire "mais nous avons des programmes qui génèrent du code", mais le code qu'il génère est basé sur une sorte d'entrée qui est presque toujours construite à la main.

Ainsi, quel que soit le chemin emprunté pour accéder au code: que ce soit via une sorte de configuration ou une autre entrée qui produit ensuite du code via un outil, ou si vous l'écrivez à partir de zéro, ce n'est pas le code qui compte. Ce qui compte, c'est la pensée critique de tous les éléments nécessaires pour obtenir ce code. Dans le monde de Linus, il s’agit principalement de structures de données et de relations, alors que dans d’autres domaines, ce peut être d’autres pièces. Mais dans ce contexte, Linus ne fait que dire: "Peu importe que vous puissiez écrire du code, cela ne me dérange pas que vous puissiez comprendre ce qui résoudra les problèmes que je rencontre".

Daniel DiPaolo
la source
Chaque programmeur utilise des programmes qui génèrent du code. Ils sont souvent appelés "compilateurs", parfois en combinaison avec des "lieurs". Ils prennent une entrée (relativement) lisible et inscriptible par l'homme, qui est généralement (mais pas toujours) fournie sous une forme de texte, et la transforment en données que l'ordinateur peut comprendre sous forme d'instructions et exécuter.
un CVn
13

Linus veut dire ceci:

Montre-moi tes organigrammes [code], et cache tes tableaux [schéma], et je continuerai à être mystifié; montrez-moi vos tableaux [schéma] et je n'aurai généralement pas besoin de vos organigrammes [code]: ils seront évidents.

- Fred Brooks, "Le mois des hommes mythiques", ch. 9.

Daniel Shawcross Wilkerson
la source
12

Je pense qu'il dit que la conception globale de haut niveau (structures de données et leurs relations) est beaucoup plus importante que les détails de la mise en œuvre (code). Je pense qu'il apprécie les programmeurs qui peuvent concevoir un système par rapport à ceux qui ne peuvent se concentrer que sur les détails d'un système.

Les deux sont importants, mais je conviendrais qu'il est généralement beaucoup mieux d'avoir une vue d'ensemble et d'avoir des problèmes avec les détails que l'inverse. Cela est étroitement lié à ce que j’essayais d’exprimer à propos de la division de grandes fonctions en petites fonctions .

GlenPeterson
la source
+1: Je suis d'accord avec toi. Un autre aspect est que souvent les programmeurs s'inquiètent davantage de la fonctionnalité de langage cool qu'ils vont utiliser, au lieu de se concentrer sur leurs structures de données et leurs algorithmes et sur la façon de les écrire de manière simple et claire.
Giorgio
Je suis aussi d'accord Le fait est qu'il est facile de modifier des éléments de code isolés, mais plus difficile de modifier les structures de données ou les interfaces entre des éléments de code (car ces types de modifications peuvent affecter beaucoup de choses plutôt qu'une seule chose).
Brendan
5

Eh bien, je ne peux pas être tout à fait d’accord, car vous devez vous inquiéter de tout cela. Et à ce propos, l’une des choses que j’aime dans la programmation, c’est le passage à différents niveaux d’abstraction et de taille qui passe rapidement de la réflexion à la nanoseconde à la réflexion sur des mois, et ainsi de suite.

Cependant, les choses les plus importantes sont plus importantes.

Si j'ai un défaut dans quelques lignes de problèmes qui provoque un comportement incorrect, ce n'est probablement pas trop difficile à résoudre. Si cela entraîne une sous-performance, cela n'a probablement même pas d'importance.

Si un défaut dans le choix de la structure de données dans un sous-système entraîne un comportement incorrect, il s'agit d'un problème beaucoup plus important et plus difficile à résoudre. Si cela entraîne une sous-performance, cela pourrait être assez grave ou, si cela est supportable, encore moins bon qu'une approche concurrente.

Si j'ai un problème dans la relation entre les structures de données les plus importantes dans une application, cela entraîne un comportement incorrect, j'ai une refonte massive en face de moi. Si cela le rend moins performant, cela pourrait être si grave que ce serait presque mieux s'il se comportait mal.

Et ce sera ce qui rend difficile la recherche de ces problèmes de bas niveau (la résolution des bogues de bas niveau est normalement facile, mais de les trouver qui peuvent être difficiles).

Le matériel de bas niveau est important, et son importance restante est souvent sérieusement minimisée, mais elle est pâle par rapport au gros.

Jon Hanna
la source
2

Quelqu'un qui connaît le code voit les "arbres". Mais quelqu'un qui comprend les structures de données voit la "forêt". Par conséquent, un bon programmeur se concentrera davantage sur les structures de données que sur le code.

Tom Au
la source
2
Mais se focaliser sur la forêt ou les arbres à l’exclusion de l’autre peut être préjudiciable, donc je ne pense pas que cette analogie convient.
kojiro
1
@kojiro: Dans l'expression ne peut pas voir la forêt pour les arbres , il est supposé que quelqu'un qui peut voir la forêt verra également les arbres (voir en.wiktionary.org/wiki/see_the_forest_for_the_trees ). Par conséquent, je pense que c'est une bonne analogie ici.
Treb
2

Savoir comment les données vont circuler est primordial. Pour connaître le flux, vous devez concevoir de bonnes structures de données.

Si vous remontez vingt ans en arrière, c’était l’un des principaux arguments de vente de l’approche orientée objet utilisant SmallTalk, C ++ ou Java. Le gros argument - du moins avec C ++, car c’est ce que j’ai appris en premier lieu - était de concevoir la classe et les méthodes, puis tout le reste tomberait en place.

Linus parlait sans doute d'une manière plus large, mais des structures de données mal conçues nécessitent souvent une retouche supplémentaire du code, ce qui peut également entraîner d'autres problèmes.

Octopusgrabbus
la source
2

Que peut-on appliquer / apprendre de cela?

Si je peux me permettre, mon expérience des dernières semaines. Les discussions précédentes ont clarifié la réponse à ma question: "qu'est-ce que j'ai appris?"

J'ai réécrit du code et réfléchi aux résultats que je voyais sans cesse en disant «structure, structure ...», c'est pourquoi il y avait une telle différence. Maintenant, je vois que c'est la structure de données qui a fait toute la différence. Et je veux dire tout .

  • Après avoir testé ma livraison initiale, l'analyste commercial m'a dit que cela ne fonctionnait pas. Nous avons dit "ajouter 30 jours" mais ce que nous voulions dire était "ajouter un mois" (le jour dans la date résultante ne change pas). Ajoutez des années, des mois, des jours discrets; pas 540 jours pour 18 mois par exemple.

  • Le correctif: dans la structure de données, remplacez un entier unique par une classe contenant plusieurs entiers, mais la modification de sa construction était limitée à une méthode. Modifiez les deux déclarations arithmétiques de date réelle.

Le gain

  • La nouvelle implémentation avait plus de fonctionnalités mais le code de l’algorithme était plus court et nettement plus simple.

Dans Correction du comportement du code / des résultats:

  • J'ai changé de structure de données, pas d'algorithme.
  • AUCUNE logique de contrôle n'a été touchée dans le code.
  • Aucune API n'a été modifiée.
  • La classe de fabrique de structures de données n'a pas changé du tout.
radarbob
la source
1

J'aime imaginer une équipe très intelligente de bibliothécaires dans une bibliothèque superbement construite avec un million de livres aléatoires et brillants, ce serait une folie.

Tudor Watson
la source
1

Je ne peux pas être plus d'accord avec Linus. En se concentrant sur les données, on obtient une solution simple et flexible à un problème donné. Git lui-même est un exemple probant: en offrant tant de fonctionnalités prises en charge au cours des années de développement, la structure de données de base reste en grande partie inchangée. C'est magique! --2c

mc2
la source
0

J'ai vu que ce sont de nombreux domaines.

Pensez à l'analyse commerciale ... Supposons que vous analysez la meilleure façon de soutenir le marketing dans une entreprise de produits de consommation telle que Colgate. Si vous commencez avec des fenêtres sophistiquées ou avec les dernières technologies, vous n'aiderez pas l'aide de l'entreprise autant que si vous réfléchissiez d'abord aux besoins de l'entreprise en matière de données, puis à vous soucier de la présentation plus tard. Le modèle de données dure plus longtemps que le logiciel de présentation.

Envisagez de faire une page Web. Il est bien préférable de commencer par penser à ce que vous voulez afficher (le HTML), puis de vous préoccuper du style (CSS) et des scripts (choisissez votre outil) après.

Cela ne veut pas dire que le codage n'est pas important non plus. Vous avez besoin de compétences en programmation pour obtenir ce dont vous avez besoin à la fin. C'est que les données sont la base. Un modèle de données médiocre reflète un modèle d'entreprise trop complexe ou impensé.

MathAttack
la source
0

Je me retrouve à écrire de nouvelles fonctions et à mettre à jour des fonctions existantes beaucoup plus souvent que de devoir ajouter de nouvelles colonnes ou tables à mon schéma de base de données. Ceci est probablement vrai pour tous les systèmes bien conçus. Si vous devez modifier votre schéma chaque fois que vous devez modifier votre code, c'est un signe clair que vous êtes un très mauvais développeur.

indicateur de qualité de code = [modifications de code] / [modifications de schéma de base de données]

"Montrez-moi vos organigrammes et cachez vos tableaux, et je continuerai à être mystifié. Montrez-moi vos tableaux, et je n'aurai généralement pas besoin de vos organigrammes; ils seront évidents." (Fred Brooks)

Joel Jacobson
la source
-2

Il semble que cette idée ait diverses interprétations dans les différents types de programmation. Cela est vrai pour le développement des systèmes, mais également pour le développement des entreprises. Par exemple, on pourrait faire valoir que le net changement d'orientation vers le domaine dans la conception pilotée par domaine ressemble beaucoup à celui qui est mis sur les structures et les relations de données.

eulerfx
la source
-4

En voici mon interprétation: vous utilisez du code pour créer des structures de données, vous devriez donc vous concentrer sur ces dernières. C'est comme construire un pont - vous devriez concevoir une structure solide plutôt que séduisante. Il se trouve que des structures de données bien écrites et des ponts de qualité présentent un bel aspect en raison de leur conception efficace.

Bob
la source