Les règles de programmation de Rob Pike (1989)
(users.ece.utexas.edu)- Article sur les cinq règles de programmation de Rob Pike en 1989
- Règle 1 : ne supposez pas où un programme passera l’essentiel de son temps ; les goulets d’étranglement peuvent apparaître de manière inattendue. Évitez les hacks de performance tant qu’un goulot d’étranglement n’a pas été démontré.
- Règle 2 : mesurez toujours avant d’optimiser pour la vitesse. N’optimisez que si une partie du code a un impact significatif sur le reste.
- Règle 3 : quand
nest petit, les algorithmes complexes sont lents. C’est le cas la plupart du temps. N’utilisez des algorithmes complexes que sinest souvent grand, et même dans ce cas, appliquez d’abord la règle 2. - Règle 4 : les algorithmes simples et les structures de données simples sont préférables. Ils sont moins sujets aux bugs que les solutions complexes et plus faciles à implémenter.
- Règle 5 : la bonne structure de données est décisive en programmation. Si les données sont bien organisées, l’algorithme deviendra évident.
- Les règles 1 et 2 de Pike reflètent la maxime de Tony Hoare : « l’optimisation prématurée est la racine de tous les maux ».
- Ken Thompson a reformulé les règles 3 et 4 de Pike ainsi : « dans le doute, utilisez la force brute ».
- Les règles 3 et 4 mettent en pratique la philosophie de conception KISS (Keep It Simple, Stupid).
- La règle 5 est cohérente avec une remarque de Fred Brooks dans The Mythical Man-Month, souvent résumée par : « écrivez du code stupide qui utilise des objets intelligents ».
1 commentaires
Avis de Hacker News
Je suis entièrement d’accord avec l’idée que « les données dominent ».
C’est pourquoi les entretiens LeetCode m’ont toujours semblé étranges. Ils se concentrent généralement sur les algorithmes, alors qu’en réalité, il ne faut souvent pas aborder les choses ainsi dès le départ : les structures de données devraient être davantage au centre.
Bien sûr, si l’on ne connaît aucun algorithme, on peut ne pas repérer les cas particuliers ou les moments où il faut s’appuyer sur un algorithme précis pour une raison donnée. Malgré tout, les algorithmes peuvent s’enseigner assez rapidement, tandis que sentir quelle structure de données utiliser semble être plus difficile pour beaucoup de gens.
À ce moment-là, l’ambiance change : « ah, on a vraiment un ingénieur senior en face ». Les discussions techniques s’ouvrent davantage, et l’attitude consistant à prouver « qu’on sait coder » diminue.
À l’inverse, les équipes avec lesquelles il a été le plus difficile de créer de bons changements, d’atteindre des jalons et de collaborer étaient celles où personne ne posait correctement les structures de données et l’architecture du code. On dirait que beaucoup se sont habitués à l’idée que le framework fait tout, et que si ça ne marche pas, un plugin ou un middleware conçu par quelqu’un de plus intelligent réglera le problème.
Un ingénieur qui évite les structures de données se tire une balle dans le pied : il renonce à l’un des outils les plus utiles, et ses limites finissent par apparaître au quotidien.
Par exemple, le code peut largement servir à trouver le plus long chemin dans un graphe orienté acyclique (DAG) pondéré, mais l’essentiel était de comprendre que le problème pouvait être représenté comme un DAG pondéré. Si on ne le voit pas, on peut encore résoudre le problème, mais avec une solution beaucoup plus lente et complexe.
L’intervieweur ne vous dira pas d’emblée qu’il faut utiliser une file de priorité, une matrice d’adjacence ou un trie. Il peut donner un indice si vous bloquez, mais un guidage trop appuyé passe difficilement pour un signal fort à l’embauche.
À propos de l’affirmation selon laquelle « les algorithmes sophistiqués sont lents quand n est petit, et n est généralement petit », ce que j’ai ressenti dans un projet récent, c’est que les grands n peuvent être bien plus grands qu’on ne l’imagine.
On a vite fait de se dire « il faut absolument optimiser, il y a 100 000 opérations à faire », mais les ordinateurs sont rapides, et 100 000 multiplications sont généralement si rapides qu’il n’est pas forcément nécessaire d’y réfléchir en profondeur.
Je ne dis pas qu’il ne faut jamais réfléchir, mais la vitesse délirante du matériel moderne surprend souvent.
J’ai vu des incidents de production causés par du code devenu quadratique par erreur, et même si 99 % des utilisateurs ont toujours un petit n, certains rencontrent souvent de grands n et se retrouvent avec une application très lente.
Dans la plupart des cas, je préfère choisir un algorithme meilleur que le temps quadratique, même s’il est un peu plus lent dans le cas courant et un peu plus complexe à implémenter. Les chemins lents fréquents finissent par être optimisés, mais les chemins lents rares passent sous le radar des développeurs ou explosent en production.
Bien sûr, si l’algorithme est trop complexe, je peux choisir une implémentation quadratique simple, mais par défaut, j’essaie de viser moins que quadratique quand c’est possible. J’ai aussi écrit un article à ce sujet : https://kevincox.ca/2023/05/09/less-than-quadratic/
Cela pouvait donc être plus vrai il y a 40 ans, quand les CPU n’étaient pas aussi rapides par rapport à la mémoire et qu’on se souciait moins des échecs de prédiction de branchement sur le matériel grand public.
À chaque entretien, il arrive que le responsable du recrutement le veuille, mais qu’un débutant LeetCode qui n’a pas encore connu les blessures de la production refuse cette décision.
https://www.frankmcsherry.org/assets/COST.pdf
Vu les progrès des performances des ordinateurs ces 20 dernières années, relever ce seuil à 100 000 semble assez raisonnable.
Le célèbre adage « l’optimisation prématurée est la racine de tous les maux » ne vient pas de Tony Hoare mais en réalité de Donald Knuth, et il est souvent utilisé hors contexte comme un argument contre toute optimisation.
La phrase complète est : « Nous devrions oublier les petites efficacités, disons dans 97 % des cas. L’optimisation prématurée est la racine de tous les maux. Mais nous ne devons pas laisser passer les occasions dans les 3 % cruciaux. »
L’idée est d’optimiser en consacrant du temps là où cela a un impact.
Il est possible que Tony l’ait dit en premier et que Knuth l’ait peaufiné puis publié. Il est toujours bon d’inclure la citation longue qui donne le contexte nécessaire.
À l’époque, la programmation était très différente d’aujourd’hui. L’« optimisation prématurée » d’alors ne signifiait pas « utilisons simplement une bibliothèque populaire et scalable », mais plutôt « utilisons un algorithme de manipulation de bits incompréhensible qui ne fonctionne que sur ce matériel ».
C’est déjà inclus dans « l’optimisation prématurée est la racine de tous les maux » ; l’adage n’est pas « l’optimisation est la racine de tous les maux ».
Lors d’entretiens sur les structures de données et les algorithmes en entreprise, j’ai vu d’innombrables développeurs front-end dire que le tri à bulles était la meilleure option. Il n’est pas nécessaire de tout redériver sur le moment ; connaître quelques options et savoir proposer un bon choix adapté au problème suffit.
Si l’on pousse « ne pas optimiser prématurément » à un tel extrême qu’on ne connaît même pas les méthodes efficaces, comment savoir où se trouvent les points importants ?
L’idée que « les structures de données sont essentielles » est doublement importante dans les bases de données.
Les gens qui utilisent une base de données comme un simple réservoir de bits idiot, ou comme le reflet 1:1 de définitions d’objets, sont souvent surpris lorsque la base le prend personnellement et détruit les performances.
Si je dois revoir un schéma de base de données généré par un ORM, ce sera probablement une rencontre trop précoce.
Le problème est que certains développeurs, voire beaucoup, ne connaissent pas SQL et n’ont pas non plus les connaissances en bases de données nécessaires pour utiliser un ORM.
Un ORM est une abstraction qui fuit pas mal : il faut savoir ce qu’il y a en dessous. Si on le comprend, on peut produire un schéma correct avec la plupart des ORM.
Pour bien organiser les structures de données et les maintenir ainsi malgré l’évolution de la conception, il faut séparer les données et le code au niveau organisationnel.
La conception du schéma de base de données, les cas d’usage et le mapping entre les deux devraient être séparés du reste de l’implémentation, et ce groupe devrait aussi écrire les contrôles d’intégrité, entre autres. Si la structure de l’organisation ne sépare pas les données et le code, il est difficile de séparer le code et les données.
Ma règle supplémentaire est que les petits gaspillages de performance, accumulés, finissent par ralentir un programme même si chacun paraît insignifiant.
Si cela n’a pas d’impact sur la complexité, la lisibilité, la maintenabilité ou le coût d’implémentation, il ne faut pas simplement jeter la performance. Toutes choses presque égales par ailleurs, choisir l’option la plus lente entre deux solutions n’est pas acceptable.
Par ailleurs, si l’on suppose que n est petit, presque tout fonctionne. Mais si l’on écrit du code qui marche bien jusqu’à 100 et s’effondre au-delà de 10000, par exemple en O(n²), il faut tout simplement imposer une limite. Si l’hypothèse d’un petit n est violée, il vaut mieux échouer bruyamment qu’avoir une facture AWS explosive ou un programme bloqué.
Une bonne partie de ces directives revient finalement à des stratégies pour éviter la surconception.
D’après mon expérience, l’optimisation prématurée est l’un des pièges les plus coûteux. Contourner trop tôt des problèmes potentiels laisse ces hypothèses non vérifiées, et l’équipe suivante doit élaborer des solutions coûteuses pour gérer une complexité inutile.
L’approche que j’ai apprise est la suivante : l’optimisation repose sur des estimations, et les estimations du début sont souvent fausses.
J’ai aussi constaté que, pour empêcher les gens de produire du code excessivement complexe, la gestion de l’ego et la compréhension psychologique comptent beaucoup.
La surproduction est généralement considérée comme le pire des gaspillages, car non seulement elle produit quelque chose d’inutile, mais elle consomme aussi des efforts qui auraient pu être consacrés à ce qui était réellement nécessaire. La surconception est similaire.
Par exemple, même avec seulement 100 utilisateurs, on commence avec une architecture microservices parce qu’un jour, s’il y en a un million, il sera difficile de reconcevoir le monolithe.
Il faut donc d’abord s’attaquer à la question de savoir pourquoi le code devient moins malléable avec le temps.
Ce sont globalement de bonnes règles, mais dans la pratique, la règle 1 ne tient pas telle quelle
Au départ, il faut une hypothèse sur ce qui deviendra le goulot d’étranglement. Il n’est pas toujours possible de se dire qu’on implémentera XYZ, puis qu’on mesurera ce qui est lent et qu’on le corrigera. X, Y et Z sont parfois liés, au point qu’il faut concevoir X et Z d’une certaine manière pour rendre Y rapide, et il arrive qu’on sache déjà que Y sera le goulot d’étranglement
Même si, plus tard, les mesures permettent de savoir ce qui est lent, il faut parier sur une approche pour le rendre plus rapide. Plus ce pari est éclairé, mieux c’est
Les bons programmeurs mesurent, mais ils savent aussi prédire ce qui sera lent, bogué et gourmand en mémoire, ce qui leur évite des itérations. Présenter comme une règle l’idée qu’on ne peut pas prédire le comportement en matière de performances revient à ignorer l’expérience et le savoir-faire accumulés par les bons programmeurs
Car c’est précisément en appliquant la règle 1 qu’on acquiert l’expérience et le bagage empirique nécessaires à une bonne intuition pour anticiper les goulots d’étranglement
Si la prédiction de performance est fausse, on se retrouve à traîner du code inutilement complexe pendant toute la durée de vie du projet
Les gens se trompent souvent sur la vitesse des algorithmes. Si l’ordinateur passe 99 % de son temps à récupérer n depuis le serveur de base de données, O(n) et O(n²) peuvent souvent sembler équivalents en temps réel
Un algorithme écrit en C peut aussi être plus lent que le code Python équivalent, parce que le compilateur de bytecode a pu faire quelque chose d’intelligent
J’ai beaucoup travaillé à rendre du code legacy plus rapide, et c’est généralement bien plus facile qu’on ne l’imagine, avec des lenteurs dues à des raisons qui n’étaient pas évidentes pour l’auteur initial. En pratique, le code est souvent lent parce que la base de code est devenue trop complexe pour que son auteur d’origine puisse encore raisonner dessus. De mon côté, j’ai un exemple concret de quelque chose de « trop lent », donc il est facile de l’exécuter, d’observer où ça ralentit et de le déboguer
Si vous développez un jeu vidéo avec beaucoup d’objets physiques et que, par expérience, vous savez avec certitude que la détection des collisions sera un gros problème, concevoir le jeu et le système autour de cela n’est pas un hack de performance
Si vous savez que la performance sera une préoccupation majeure pour une tâche, il faut évidemment mesurer. Il ne s’agit pas de vérifier si c’est une préoccupation, mais de vérifier à quel point vous la traitez bien
Si l’on crée un nouveau système pour de nouvelles exigences, il me semble que, souvent, on peut simplement commencer. Construire, tester et mesurer, jeter ou refactorer, puis recommencer
Prenons Rust comme exemple : il a commencé avec un langage de brouillon et un compilateur écrit en OCaml, puis a itéré. Même si l’on savait qu’un jour il serait possible de passer d’OCaml à l’auto-hébergement, je ne suis pas sûr que cela aurait changé grand-chose
S’il n’y a pas d’utilisateurs, même une fonction qui prend plusieurs heures reste suffisamment rapide par rapport à une fonction qui passerait à quelques millisecondes une fois optimisée. Je ne sais pas vraiment si quelqu’un a prouvé qu’il pouvait faire ce genre de prédiction avec précision
En objection à la règle 5, des algorithmes complexes appliqués à des données simples peuvent apporter de gros gains de performance, supprimer des obstacles et même simplifier les choses
Par exemple, si l’on utilise une recherche binaire dans un tableau trié plutôt qu’un objet BinaryTree, la fusion devient plus simple — concaténation puis tri —, l’absence de pointeurs facilite la sérialisation et, dans certains cas, rend la sérialisation elle-même inutile. Le tableau peut résider sur disque, en mémoire, ou dans les deux via mmap ; il peut gérer des données plus grandes que la RAM ; il permet aussi un cold start où l’on pointe simplement vers un fichier ou un mapping et l’on exécute directement. Il a aussi des propriétés cache-oblivious
Le codage de Huffman en est un autre exemple. À l’université, on l’a généralement appris comme un algorithme à base d’arbre en complexité O(n log n), mais j’ignorais qu’il existait une méthode pour construire un arbre de Huffman en temps linéaire, en place, à partir d’un tableau
Bien sûr, 99 % du temps, on construit des microservices backend avec les structures de données des collections standard. Mais si je dois traiter du big data au travail, je préfère de très loin le faire sur une seule machine locale équipée de gros disques plutôt que d’adopter la famille MapReduce à la mode du moment
Rob Pike aurait sans doute commencé par profiler le code, puis regardé si le code élégant ou la structure de données alternative était effectivement plus rapide
J’ai lu ce texte pour la première fois sur cat-v il y a plus de dix ans, et il a eu une influence indélébile sur ma façon d’aborder et de penser la conception et la complexité
http://doc.cat-v.org/bell_labs/pikestyle
Je ne vois pas comment on passe de la règle originale « les structures de données sont au cœur du sujet » à « écrivez du code stupide qui utilise des objets intelligents »
L’expression « smart objects » était vraiment mauvaise, et la règle originale est bien meilleure, même si elle est plus longue