Citation de Torvalds sur un bon programmeur [fermé]

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?

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.

Algorithmes + Structures de Données = Programmes

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

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.

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

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

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.

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 .

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.

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.

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.

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.

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.

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

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

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)

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.

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.