Citation de Torvalds sur un bon programmeur
Par accident, je suis tombé 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 ai réfléchi ces derniers jours et je suis toujours confus (ce qui n'est probablement pas un bon signe), donc je voulais discuter de ce qui suit:
- Quelle interprétation de cela possible/logique?
- Que peut-on en tirer/en tirer?
Il pourrait être utile de considérer ce que Torvalds a dit juste avant:
git a en fait une conception simple, avec des structures de données stables et raisonnablement bien documentées. En fait, je suis un grand 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 assez bien réussi […] Je vais en fait affirmer que la différence entre un mauvais programmeur et un bon, c'est s'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, tandis 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 modifient leur format de données relativement régulièrement afin de 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 pour la première fois, beaucoup de gens ne pouvaient pas comprendre ce que le modèle distribué rendait les fusions tellement plus propres que le contrôle de version centralisé. La réponse est absolument rien, sauf les structures de données distribuées had pour être beaucoup mieux afin d'avoir un espoir de travailler du tout. Je crois que les algorithmes de fusion centralisés ont depuis rattrapé, mais cela a pris beaucoup de temps car leurs anciennes structures de données limitaient les types d'algorithmes qu'ils pouvaient utiliser, et les nouvelles structures de données ont brisé beaucoup de code existant.
En revanche, malgré une explosion de fonctionnalités dans git, ses structures de données sous-jacentes ont à peine changé. Inquiétez-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 de exprimer les algorithmes et les structures de données.
Cette citation est très familière à l'une des règles de "The Art of Unix Programming" qui est le fort de Torvalds en tant que créateur de Linux. Le livre se trouve en ligne ici
Du livre est la citation suivante qui expose ce que dit Torvalds.
Règle de représentation: intégrer les connaissances dans les données afin que la logique du programme puisse être stupide et robuste.
Même la logique procédurale la plus simple est difficile à vérifier pour les humains, mais les structures de données assez complexes sont assez faciles à modéliser et à raisonner. Pour voir cela, comparez l'expressivité et la puissance explicative d'un diagramme (disons) d'un arbre de pointeurs à cinquante nœuds avec un organigramme d'un programme de cinquante lignes. Ou, comparez un initialiseur de tableau exprimant une table de conversion avec une instruction switch équivalente. La différence de transparence et de clarté est dramatique. Voir la règle 5 de Rob Pike.
Les données sont plus faciles à gérer que la logique du programme. Il s'ensuit que lorsque vous voyez un choix entre la complexité des structures de données et la complexité du code, choisissez la première. Plus: dans l'évolution d'une conception, vous devez rechercher activement des moyens de déplacer la complexité du code vers les données.
La communauté Unix n'est pas à l'origine de cet aperçu, mais beaucoup de code Unix affiche son influence. La facilité du langage C à manipuler les pointeurs, en particulier, a encouragé l'utilisation de structures de référence modifiées dynamiquement à tous les niveaux de codage du noyau vers le haut. De simples poursuites de pointeurs dans de telles structures remplissent fréquemment des fonctions que les implémentations dans d'autres langages devraient plutôt incarner 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 inquiétez du code, cela signifie que vous n'obtenez pas encore ces bases et que vous êtes probablement perdu sur le complexe (c'est-à-dire les structures de données et leurs relations).
Pour développer Morons's answer un peu, l'idée est que la compréhension des détails du code (syntaxe, et dans une moindre mesure, structure/mise en page) est assez facile pour que nous construisions des outils qui peuvent le faire . Les compilateurs peuvent comprendre tout ce qu'il faut savoir sur le code pour le transformer en programme/bibliothèque fonctionnel. Mais un compilateur ne peut pas réellement résoudre les problèmes que les programmeurs font.
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.
Donc, quelle que soit la route que vous prenez pour arriver 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. C'est la pensée critique de toutes les pièces nécessaires pour arriver à ce code qui compte. Dans le monde de Linus, il s'agit principalement de structures et de relations de données, bien que dans d'autres domaines, il puisse s'agir d'autres éléments. Mais dans ce contexte, Linus dit simplement: "Je me fiche que vous puissiez écrire du code, je tiens à ce que vous compreniez les choses qui résoudront les problèmes auxquels je fais face".
Linus signifie ceci:
Montrez-moi vos organigrammes [code] et cachez vos 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 de l'homme mythique", 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 mise en œuvre (code). Je pense qu'il apprécie les programmeurs qui peuvent concevoir un système plutôt que ceux qui ne peuvent se concentrer que sur les détails d'un système.
Les deux sont importants, mais je conviens 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. Ceci est étroitement lié à ce que j'essayais d'exprimer à propos de diviser les grandes fonctions en petites .
Eh bien, je ne suis pas entièrement d'accord, car vous devez vous inquiéter de tout cela. Et d'ailleurs, l'une des choses que j'aime dans la programmation, c'est le passage à différents niveaux d'abstraction et de taille qui passent rapidement de la réflexion sur les nanosecondes à la réflexion sur les mois, et inversement.
Cependant, les choses supérieures sont plus importantes.
Si j'ai une faille dans quelques lignes de problèmes qui provoque un comportement incorrect, ce n'est probablement pas trop difficile à corriger. Si cela entraîne une sous-performance, cela n'a probablement même pas d'importance.
Si j'ai un défaut dans le choix de la structure des données dans un sous-système, qui provoque un comportement incorrect, c'est un problème beaucoup plus important et plus difficile à résoudre. Si cela la rend sous-performante, elle pourrait être assez grave ou, si elle est supportable, toujours sensiblement moins bonne qu'une approche rivale.
Si j'ai une faille dans la relation entre les structures de données les plus importantes dans une application, ce qui provoque un comportement incorrect, j'ai une refonte massive devant moi. Si cela le rend sous-performant, il pourrait être si mauvais qu'il serait presque préférable qu'il se comporte mal.
Et ce sera ce qui rend difficile la recherche de ces problèmes de bas niveau (la correction de bogues de bas niveau est normalement facile, c'est de les trouver qui peuvent être difficiles).
La substance de bas niveau est importante, et son importance restante est souvent sérieusement sous-estimée, mais elle est pâle par rapport aux grandes choses.
Il est important de savoir comment les données circuleront. La connaissance du flux nécessite que vous conceviez de bonnes structures de données.
Si vous remontez vingt ans en arrière, c'était l'un des principaux arguments de vente pour l'approche orientée objet utilisant Smalltalk, C++ ou Java. Le gros argument - du moins avec C++ parce que c'est ce que j'ai appris en premier - était de concevoir la classe et les méthodes, puis tout le reste se mettrait en place.
Linus parlait sans aucun doute en termes plus larges, mais les structures de données mal conçues nécessitent souvent une refonte supplémentaire du code, ce qui peut également entraîner d'autres problèmes.
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.
Que peut-on en tirer/en tirer?
Si vous me le permettez, 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 n'arrêtais pas de voir et de dire "structure, structure ...", c'est pourquoi il y avait une telle différence dramatique. Maintenant, je vois que c'est la structure des données qui a fait toute la différence. Et je veux dire tout .
Après avoir testé ma livraison d'origine, l'analyste d'affaires 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 et des jours discrets; pas 540 jours pour 18 mois par exemple.
Le correctif: dans la structure de données remplacer un seul entier par une classe contenant plusieurs entiers, le changement de sa construction était limité à une seule méthode. Modifiez les déclarations arithmétiques de la date réelle - les deux.
Le gain
- La nouvelle implémentation avait plus de fonctionnalités mais le code de l'algorithme était plus court et clairement plus simple.
Dans Correction du comportement/des résultats du code:
- J'ai changé la structure des données, pas l'algorithme.
- AUCUNE logique de contrôle n'a été touchée n'importe où dans le code.
- Aucune API n'a été modifiée.
- La classe d'usine de structure de données n'a pas changé du tout.
Je ne peux pas être plus d'accord avec Linus. Se concentrer sur les données permet de distiller considérablement une solution simple et flexible à un problème donné. Git lui-même en est un exemple probant - avec autant de fonctionnalités prises en charge pendant les années de développement, la structure des données de base reste largement inchangée. C'est magique! --2c
J'aime imaginer une équipe de bibliothécaires très intelligente dans une bibliothèque magnifiquement faite avec un million de livres aléatoires et brillants, ce serait une folie.
Je me retrouve à écrire de nouvelles fonctions et à mettre à jour celles qui existent déjà beaucoup plus souvent que de devoir ajouter de nouvelles colonnes ou tables à mon schéma de base de données. Cela est probablement vrai pour tous les systèmes bien conçus. Si vous devez changer votre schéma chaque fois que vous devez changer votre code, c'est un signe clair que vous êtes un très mauvais développeur.
indicateur de qualité du code = [changements de code]/[changements 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)
J'ai vu que ce sont de nombreux domaines.
Pensez à l'analyse commerciale ... Disons que vous analysez la meilleure façon de soutenir le marketing dans une entreprise de produits de consommation comme Colgate. Si vous commencez avec des fenêtres sophistiquées ou les dernières technologies, vous n'aiderez pas l'entreprise autant que si vous réfléchissez d'abord aux besoins en données de l'entreprise, puis vous vous inquiétez de la présentation plus tard. Le modèle de données survit au logiciel de présentation.
Pensez à créer une page Web. Il est préférable de réfléchir à ce que vous voulez afficher (le HTML) en premier, et de vous soucier 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 le fondement. Un modèle de données médiocre reflète un modèle commercial trop complexe ou non réfléchi.