- Règle 1 : il est impossible de prédire où un programme passera son temps. Les goulots d’étranglement apparaissent là où on ne les attend pas, donc n’essayez pas d’améliorer les performances tant qu’il n’est pas prouvé qu’il s’agit réellement d’un goulot d’étranglement
- Règle 2 : la mesure d’abord. Le réglage des performances ne doit être fait qu’après mesure, et l’optimisation ne doit être envisagée que lorsqu’une partie du code domine clairement l’ensemble
- Règle 3 : les algorithmes complexes sont lents pour les petits n. Les algorithmes complexes ont de grandes constantes ; tant que n ne grandit pas souvent, il faut utiliser une méthode simple. Et même si n grandit, il faut d’abord appliquer la règle 2
- Règle 4 : les algorithmes complexes comportent plus de bugs et sont plus difficiles à implémenter. Il est préférable d’utiliser des algorithmes simples et des structures de données simples
- Règle 5 : les données sont essentielles. Si l’on choisit la bonne structure de données et qu’on l’organise correctement, l’algorithme devient presque évident. Le cœur de la programmation n’est pas l’algorithme, mais la structure de données
Philosophie et citations associées
- Les règles 1 et 2 ont le même sens que l’adage de Tony Hoare : « l’optimisation prématurée est la racine de tous les maux »
- Ken Thompson a réinterprété les règles 3 et 4 en « en cas de doute, utilisez la méthode simple (Brute Force) »
- Les règles 3 et 4 sont un exemple de la philosophie de conception KISS (Keep It Simple, Stupid)
- La règle 5 avait déjà été évoquée par Fred Brooks dans The Mythical Man-Month,
souvent résumée par « écrire un code simple en utilisant des objets intelligents »
Aucun commentaire pour le moment.