hacker-laws-website

đŸ’»đŸ“– hacker-laws

Lois, théories, principes et modÚles que les développeurs trouveront utiles.

Traductions: đŸ‡§đŸ‡· 🇹🇳 đŸ‡©đŸ‡Ș đŸ‡«đŸ‡· đŸ‡ŹđŸ‡· 🇼đŸ‡č đŸ‡±đŸ‡» đŸ‡°đŸ‡· đŸ‡·đŸ‡ș đŸ‡Ș🇾 đŸ‡čđŸ‡·

Vous aimez ce projet ? N’hĂ©sitez pas Ă  me sponsoriser ainsi que les traducteurs.


Introduction

Il y a beaucoup de “lois” dont les gens parlent quand on discute de dĂ©veloppement. Ce repository offre une vue d’ensemble et une rĂ©fĂ©rence des plus communes. N’hĂ©sitez pas Ă  partager et Ă  proposer vos PRs !

❗: Ce repo ne prĂ©conise aucune des lois, principes ou modĂšles qui y sont expliquĂ©s. Leur application devrait toujours ĂȘtre le sujet d’un dĂ©bat, et dĂ©pend grandement de ce sur quoi vous travaillez.

Lois

Nous y voila !

Loi d’Amdahl

Loi d’Amdahl sur Wikipedia

La loi d’Amdahl est une formule qui montre le gain de vitesse potentiel sur un calcul, obtenu en augmentant les ressources d’un systĂšme. Habituellement utilisĂ© en calcul parallĂšle, elle peut prĂ©dire les bĂ©nĂ©fices rĂ©els de l’accroissement du nombre de processeurs. BĂ©nĂ©fices qui sont limitĂ©s par le potentiel du programme Ă  ĂȘtre parallĂ©lisĂ©.

Prenons un exemple: si un programme est composĂ© de 2 parties, la partie A devant ĂȘtre exĂ©cutĂ© par un seul processeur et la partie B pouvant ĂȘtre parallĂ©lisĂ©e, alors on peut constater qu’ajouter plusieurs processeurs au systĂšme executant le programme ne peut avoir qu’un bĂ©nĂ©fice limitĂ©. Cela peut potentiellement amĂ©liorer grandement la vitesse de la partie B, mais la vitesse de la partie A restera inchangĂ©e.

Le diagramme ci-dessous montre quelques exemples de gain de vitesse potentiels :

Diagram: Amdahl's Law

(Reference: par Daniels220 sur English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)

Comme il est visible, un programme qui est parallĂ©lisable Ă  50% ne bĂ©nĂ©ficiera que trĂšs peu au delĂ  des 10 processeurs, tandis qu’un programme parallĂ©lisable Ă  95% peut encore gagner en vitesse avec plus d’un millier de processeurs.

À mesure que la loi de Moore ralenti et que l’accĂ©lĂ©ration de la vitesse de calcul des processeurs diminue, la parallĂ©lisation est la clef de l’amĂ©lioration des performances. Prenons par exemple la programmation graphique avec les calculs de Shader: chaque pixel ou fragment peut ĂȘtre rendu en parallĂšle. Ce qui explique que les cartes graphiques rĂ©centes ont souvent plusieurs milliers de coeurs de calcul (GPUs ou Shader Units).

Voir aussi:

Théorie de la vitre brisée

Théorie de la vitre brisée sur Wikipedia

La thĂ©orie de la vitre brisĂ©e suggĂšre que des signes visibles de criminalitĂ© (ou de manque de soin d’un environnement) amĂšne Ă  des crimes plus nombreux et plus sĂ©rieux (ou une plus grande dĂ©tĂ©rioration de l’environnement).

Cette théorie est aussi appliqué au développement logiciel pour suggérer que du code de mauvaise qualité (ou de la dette technique) peut amener à penser que les efforts fait pour améliorer le code ne sont pas valorisés, voir complÚtement ignorés. Menant ainsi à une plus grande détérioration de la qualité du code au fil du temps.

Voir aussi:

Exemples:

Loi de Brooks

Loi de Brooks sur Wikipedia

Ajouter des personnes Ă  un projet en retard accroĂźt son retard.

Cette loi suggĂšre que dans beaucoup de cas, tenter d’accĂ©lĂ©rer le bouclage d’un projet qui est en retard en ajoutant plus de personnes dessus rendra le projet encore plus en retard. Brooks est clair sur le fait qu’il s’agit d’une grande simplification, mais le raisonnement gĂ©nĂ©ral est que la vitesse d’avancement du projet sur le court terme diminue Ă  cause du temps nĂ©cessaire Ă  l’intĂ©gration des nouveaux arrivants et du surplus de communication nĂ©cessaire. De plus, de nombreuses tĂąches peuvent ne pas ĂȘtre divisibles, comprendre rĂ©parties entre plusieurs personnes. Ce qui abaisse encore le potentiel d’augmentation de la vitesse d’avancement du projet.

La phrase bien connue “Neuf femmes ne peuvent pas faire un bĂ©bĂ© en un mois” illustre la loi de Brooks, en particulier le fait que certaines tĂąches ne sont pas divisibles ou parallĂ©lisables.

C’est un thùme central du livre ‘The Mythical Man Month’.

Voir aussi:

Loi de Conway

Loi de Conway sur Wikipedia

Cette loi suggĂšre que les contours techniques d’un systĂšme reflĂštent la structure de l’organisation qui a produit le systĂšme. Cette loi est souvent Ă©voquĂ©e quand on cherche Ă  amĂ©liorer l’organisation en question. Si une organisation est structurĂ©e en plusieurs unitĂ©s dĂ©connectĂ©es, le logiciel qui est produit le sera aussi. Si une organisation est composĂ©e de silos verticaux orientĂ©s autour de fonctionnalitĂ©s ou services, le logiciel le reflĂštera aussi.

Voir aussi:

Loi de Cunningham

Loi de Cunningham sur Wikipedia

Le meilleur moyen d’obtenir une bonne rĂ©ponse sur Internet n’est pas de poser la question, mais de poster la mauvaise rĂ©ponse.

Selon Steven McGeady, Ward Cunningham lui aurait conseillĂ© au dĂ©but des annĂ©es 1980: “le meilleur moyen d’obtenir une bonne rĂ©ponse sur Internet n’est pas de poser la question, mais de poster la mauvaise rĂ©ponse.” McGeady baptisa cette phrase la loi de Cunningham, bien que Cunningham lui mĂȘme en rĂ©fute la parentĂ©. Faisant initialement rĂ©fĂ©rence aux interactions sur Usenet, cette loi a Ă©tĂ© utilisĂ© pour dĂ©crire le fonctionnement d’autres communautĂ©s en ligne (Wikipedia, Reddit, Twitter, Facebook).

Voir aussi:

Nombre de Dunbar

Nombre de Dunbar sur Wikipedia

“Le nombre de Dunbar est le nombre maximum d’individus avec lesquels une personne peut entretenir simultanĂ©ment une relation humaine stable.” À savoir une relation dans laquelle un individu sait qui est chaque personne et comment elle est liĂ©e aux autres personnes. Il n’y a pas de vĂ©ritable consensus sur le nombre exact. “
 [Dunbar] avance que les ĂȘtres humains peuvent maintenir confortablement seulement 150 relations stables”. Il place le nombre dans un contexte social: “le nombre de personnes envers lesquelles vous ne vous sentiriez pas embarrassĂ© de partager un verre si vous les croisiez par hasard dans un bar”. Les estimations du nombre tombent gĂ©nĂ©ralement entre 100 et 250.

De mĂȘme que les relations stables entre individus, la relation entre un dĂ©veloppeur et une codebase requiert des efforts pour ĂȘtre maintenu. Lorsque nous faisons face Ă  de larges projets compliquĂ©s ou nombreux, nous pouvons nous aider de conventions, de procĂ©dures ou de modĂšles. Le nombre de Dunbar est important Ă  garder Ă  l’esprit non seulement lorsque la taille d’une entreprise augmente mais aussi lorsqu’on dĂ©cide de la portĂ©e des efforts Ă  rĂ©aliser pour une Ă©quipe. Pris dans un contexte d’ingĂ©nierie, il reprĂ©sente le nombre de projets sur lesquels on pourrait sereinement faire du support si on y Ă©tait amenĂ©.

Voir aussi :

Loi de Gall

Loi de Gall sur Wikipedia

Un systĂšme complexe qui fonctionne est une Ă©volution d’un systĂšme simple qui fonctionne. Un systĂšme complexe entiĂšrement conçu depuis zero ne fonctionne jamais et ne peut pas ĂȘtre modifiĂ© pour le faire fonctionner. Il faut recommencer avec un systĂšme simple qui fonctionne. (John Gall)

La loi de Gall implique que les tentatives de concevoir un systĂšme fortement complexe ont de grandes chances d’échouer. Les systĂšmes fortement complexes sont rarement construits d’un seul coup, mais Ă©voluent plutĂŽt depuis des systĂšmes plus simples.

Un exemple classique est le world-wide-web. Dans son Ă©tat actuel, il s’agit d’un systĂšme fortement complexe. Cependant, il Ă©tait initialement dĂ©finit comme un simple moyen d’échanger du contenu entre Ă©tablissements universitaires. Ayant atteint cet objectif avec un grand succĂšs, le systĂšme a Ă©voluĂ© pour devenir de plus en plus complexe au fil du temps.

Voir aussi :

Loi de Goodhart

Loi de Goodhart sur Wikipedia

Toute régularité statistique observée a tendance à perdre de sa fiabilité lorsque on tente de la contrÎler. Charles Goodhart

Souvent aussi énoncée de cette maniÚre :

Lorsqu’une mesure devient un objectif, elle cesse d’ĂȘtre une bonne mesure. Marilyn Strathern

Cette loi indique que les optimisations basĂ©es sur une mesure peuvent amener Ă  une perte de valeur de la mesure elle mĂȘme. Un ensemble de mesures (KPIs) trop restraint appliquĂ© aveuglĂ©ment Ă  un process dĂ©forme le rĂ©sultat. Les gens tendent Ă  “tricher” localement pour satisfaire une mesure en particulier sans faire attention aux effets globaux de leurs actions sur le systĂšme.

Exemples concrets :

Voir aussi :

Rasoir de Hanlon

Rasoir de Hanlon sur Wikipedia

Ne jamais attribuer Ă  la malveillance ce que la bĂȘtise suffit Ă  expliquer. Robert J. Hanlon

Ce principe suggÚre que des actions produisant un mauvais résultat ne sont pas toujours motivées par de mauvaises intentions. Il est au contraire plus probable que le problÚme se situe dans la compréhension de ces actions et de leurs impacts.

Loi de Hofstadter

Loi de Hofstadter sur Wikipedia

Il faut toujours plus de temps que prĂ©vu, mĂȘme en tenant compte de la loi de Hofstadter. (Douglas Hofstadter)

Vous pourrez entendre parler de cette loi lorsqu’on cherche Ă  estimer le temps nĂ©cessaire pour faire quelque chose. C’est un lieu commun de dire que nous ne sommes pas trĂšs bon pour estimer le temps nĂ©cessaire Ă  boucler un projet en dĂ©veloppement logiciel.

c’est un extrait du livre ‘Gödel, Escher, Bach: An Eternal Golden Braid’.

Voir aussi :

Loi de Hutber

Loi de Hutber sur Wikipedia

Amélioration veut dire détérioration. (Patrick Hutber)

Cette loi suggĂšre que les amĂ©liorations apportĂ©es Ă  un systĂšme vont mener Ă  la dĂ©tĂ©rioration d’autres choses. Ou qu’elles vont cacher d’autres dĂ©tĂ©riorations, amenant globalement Ă  une dĂ©gradation de l’état du systĂšme.

Par exemple, un abaissement de la latence de réponse sur une route (end-point) peut causer des problÚmes de débit et de capacité plus loin, affectant un sous-systÚme entiÚrement différent.

Cycle du hype & Loi d’Amara

Cycle du hype sur Wikipedia

On a tendance à surestimer l’effet d’une technologie sur le court terme et à le sous-estimer sur le long terme. (Roy Amara)

Le cycle du hype est une reprĂ©sentation visuelle de l’attrait et du dĂ©veloppement d’une technologie au fil du temps. Initialement rĂ©alisĂ© par Gartner, le concept est plus clair avec un diagramme :

The Hype Cycle

(Reference: par Jeremykemp sur English Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)

En clair, ce cycle montre qu’il y a gĂ©nĂ©ralement un pic d’excitation concernant les nouvelles technologies et leur potentiel impact. Les Ă©quipes adoptent ces technologies rapidement et se retrouvent parfois déçues des rĂ©sultats. Cela peut ĂȘtre Ă  cause d’un manque de maturitĂ© de la technologie, ou parce que les applications concrĂštes de cette technologie ne sont pas encore totalement maitrisĂ©es. AprĂšs un certain temps, les opportunitĂ©s d’utiliser cette technologie ainsi que ses capacitĂ©s augmentent suffisamment pour que les Ă©quipes deviennent vraiment productives. La citation de Roy Amara le rĂ©sume de maniĂšre plus succincte: “On a tendance Ă  surestimer l’effet d’une technologie sur le court terme et Ă  le surestimer sur le long terme”.

Loi d’Hyrum (loi des interfaces implicites)

Loi d’Hyrum en ligne

PassĂ© un certain nombre d’utilisateur d’une API, peu importe ce qui est promis par l’interface, tous les comportements possibles du systĂšme seront utilisĂ©s. (Hyrum Wright)

La loi d’Hyrum dĂ©cris le fait que lorsqu’une API a un nombre suffisamment Ă©levĂ© d’utilisateurs, tous les comportements de l’API (y compris ceux qui ne sont pas dĂ©finis publiquement) seront utilisĂ©s par quelqu’un. Un exemple trivial peut concerner les Ă©lĂ©ments non fonctionnels de l’API comme le temps de rĂ©ponse. Un exemple plus subtil peut ĂȘtre l’utilisation d’une regex sur les messages d’erreurs pour en dĂ©terminer le type. MĂȘme si la spĂ©cification de l’API ne mentionne rien quant au contenu des messages, certains utilisateurs peuvent utiliser ces messages. Un changement au niveau de ces messages reviendrait Ă  casser l’API pour ces utilisateurs.

Voir aussi :

Loi de Kernighan

Debugger est deux fois plus difficile que de rĂ©diger le code initial. Par consĂ©quent si vous rĂ©diger le code de maniĂšre aussi maligne que possible, vous n’ĂȘtes, par dĂ©finition, pas assez intelligent pour le debugger. (Brian Kernighan)

La loi de Kernighan est nommĂ©e d’aprĂšs Brian Kernighan et est basĂ©e d’une citation du livre de Kernighan et Plauger: The Elements of Programming Style.

Tout le monde sait que debugger est 2 fois plus difficile que de rĂ©diger le programme en premier lieu. Donc si vous ĂȘtes aussi malin que possible en le rĂ©digeant, comment pourrez vous le debugger ?

Bien qu’étant hyperbolique, la loi de Kernighan prĂ©sente l’argument que du code simple est prĂ©fĂ©rable Ă  du code complexe, car tout problĂšme qui pourrait apparaitre dans du code complexe sera couteux voir impossible Ă  debugger.

Voir aussi :

Loi de Metcalfe

Loi de Metcalfe sur Wikipedia

L’utilitĂ© d’un rĂ©seau est proportionnelle au carrĂ© du nombre de ses utilisateurs.

Cette loi est basĂ©e sur le nombre de connexions par pair Ă  l’intĂ©rieur d’un systĂšme et est fortement liĂ©e Ă  la Loi de Reed. Odlyzko et d’autres ont soutenus l’argument que la loi de Reed et la loi de Metcalfe surestiment la valeur du systĂšme en ne tenant pas compte des limites de l’intellect humain. Voir le Nombre de Dunbar.

Voir aussi :

Loi de Moore

Loi de Moore sur Wikipedia

Le nombre de transistors dans un circuit intégré double approximativement tous les 2 ans.

Souvent utilisĂ©e pour illustrer la grande vitesse Ă  laquelle les semi-conducteurs et les technologies de puces informatiques ont Ă©voluĂ©es. Cette prĂ©diction de Moore s’est rĂ©vĂ©lĂ©e ĂȘtre trĂšs prĂ©cise des annĂ©es 70 aux annĂ©es 2000. Plus rĂ©cemment ceci dit, la tendance a ralentie, en partie du aux limites physiques de la miniaturisation des composants. Cependant, les avancĂ©es dans la parallĂ©lisation et les changements potentiellement rĂ©volutionnaires dans les technologies des semi-conducteurs et du calcul quantique continueront peut ĂȘtre de faire respecter la loi de Moore pour les dĂ©cennies Ă  venir.

Loi de Murphy / Loi de Sod

Loi de Murphy sur Wikipedia

Tout ce qui est susceptible d’aller mal, ira mal.

ÉnoncĂ©e par Edward A. Murphy, Jr, la loi de Murphy dĂ©clare que si quelque chose peut mal tourner, cela tournera mal.

C’est une formule bien connue des dĂ©veloppeurs. Parfois l’inattendu surviens lors du dĂ©veloppement, des tests, ou mĂȘme en production. Cette loi peut aussi ĂȘtre liĂ©e Ă  la loi de Sod (plus courante en Anglais d’Angleterre) :

Si quelque chose peut mal tourner, cela tournera mal. Au pire moment possible.

Ces ‘lois’ sont souvent utilisĂ©es dans un sens humoristique. Cependant, des biais cognitifs tels que le biais de confirmation et le biais de sĂ©lection peuvent amener des gens Ă  porter trop d’importance Ă  ces lois. (On ne porte pas attention aux choses quand elles fonctionnent, la plupart du temps. Quand il y a un problĂšme en revanche, c’est plus remarquĂ© et peut entrainer des discussions)

Voir aussi :

Rasoir d’Occam

Rasoir d’Occam sur Wikipedia

Les multiples ne doivent pas ĂȘtre utilisĂ©s sans nĂ©cessitĂ©. William of Ockham

Le rasoir d’Occam nous indique que parmi plusieurs solutions possibles, la plus probable est celle Ă  laquelle est attachĂ©e le moins de concepts et d’à priori. Cette solution est la plus simple et rĂ©sout le problĂšme donnĂ© sans ajouter accidentellement de la complexitĂ© et de potentielles consĂ©quences nĂ©gatives.

Voir aussi :

Exemple :

Loi de Parkinson

Loi de Parkinson sur Wikipedia

Le travail s’étale de façon Ă  occuper le temps disponible pour son achĂšvement.

Dans son contexte original, cette loi Ă©tait basĂ©e sur l’étude des administrations. Elle peut ĂȘtre appliquĂ©e aux projets de dĂ©veloppement logiciel, la thĂ©orie Ă©tant que les Ă©quipes seront inefficaces jusqu’à l’approche des deadlines puis se dĂ©pĂȘcheront de finir le travail pour tenir les dĂ©lais. Rendant la deadline plus ou moins arbitraire.

Si cette loi est combinĂ©e avec la loi de Hofstadter, on arrive Ă  une perspective encore plus pessimiste: le travail s’étale pour occuper tout le temps disponible et au final prendra encore plus de temps que prĂ©vu.

Voir aussi :

Effet d’optimisation prĂ©maturĂ©e

Optimisation prématurée sur WikiWikiWeb

L’optimisation prĂ©maturĂ©e est la source de tous les maux. (Donald Knuth)

Dans l’article Structured Programming With Go To Statements rĂ©digĂ© par Donald Knuth, celui-ci Ă©crit : “Les programmeurs perdent un temps Ă©norme Ă  rĂ©flĂ©chir ou Ă  se soucier de la vitesse de certaines parties non-critiques de leurs programmes. Et ces tentatives d’ĂȘtre performant ont en vĂ©ritĂ© un impact fortement nĂ©gatif quand on prend en compte le debugging et la maintenance. Nous devrions oublier les petits rendements. Disons que 97% du temps: l’optimisation prĂ©maturĂ©e est la source de tous les maux. Ceci dit, nous ne devrions pas louper les opportunitĂ©s disponibles dans ces 3% cruciaux.”

L’optimisation prĂ©maturĂ©e peut aussi ĂȘtre dĂ©finie plus simplement comme: optimiser avant qu’on soit sĂ»r qu’il faille le faire.

Loi de Putt

Loi de Putt sur Wikipedia

La technologie est dominĂ©e par deux types de personnes: celles qui comprennent ce qu’elles ne managent pas et celles qui managent ce qu’elles ne comprennent pas.

La loi de Putt est souvent suivie par sa corollaire :

Toute hiérarchie technique développe tÎt ou tard une inversion de compétence.

Ces dĂ©clarations suggĂšrent que Ă©tant donnĂ© les divers critĂšres de sĂ©lection et tendances dans la maniĂšre dont les groupes s’organisent, on trouvera au sein d’une entreprise technique deux types d’employĂ©s: des employĂ©s compĂ©tents techniquement non cadres et des employĂ©s Ă  des postes de gestion qui ne comprennent pas aussi bien la complexitĂ© et les difficultĂ©s techniques. Cela peut ĂȘtre attribuĂ© Ă  des phĂ©nomĂšnes comme le principe de Peter or le principe de Dilbert.

Ceci dit, il est important de prĂ©ciser que ce genre de lois sont des gĂ©nĂ©ralisations et s’appliquent Ă  certains types d’organisation, sans s’appliquer Ă  d’autres.

Voir aussi :

Loi de Reed

Loi de Reed sur Wikipedia

L’utilitĂ© des grands rĂ©seaux, particuliĂšrement des rĂ©seaux sociaux, s’accroit exponentiellement avec la taille du rĂ©seau.

Cette loi est basĂ©e sur la thĂ©orie des graphs, oĂč l’utilitĂ© s’accroit avec le nombre de sous-groupes possibles. Odlyzko et d’autres ont avancĂ© l’argument que la loi de Reed surestime l’utilitĂ© du rĂ©seau en ne prenant pas en compte les limites du cerveau humain; voir le nombre de Dunbar.

Voir aussi :

Loi de la conservation de la complexité (Loi de Tesler)

Loi de la conservation de la complexité sur Wikipedia

Cette loi Ă©nonce qu’il y a une certaine quantitĂ© de complexitĂ© dans un systĂšme qui ne peut pas ĂȘtre rĂ©duite.

Une partie de la complexitĂ© d’un systĂšme est du Ă  de la nĂ©gligence. ConsĂ©quence d’une mauvaise structure, d’erreurs ou d’une mauvaise modĂ©lisation du problĂšme Ă  rĂ©soudre. Ce type de complexitĂ© peut ĂȘtre rĂ©duit, voir Ă©liminĂ©. Cependant, il y a une autre partie de la complexitĂ© qui est intrinsĂšque, du au problĂšme qu’on cherche Ă  rĂ©soudre. Ce type de complexitĂ© peut ĂȘtre dĂ©placĂ© mais pas Ă©liminĂ©.

Un Ă©lĂ©ment interessant soulevĂ© par cette loi est la suggestion que mĂȘme en simplifiant le systĂšme en entier, la complexitĂ© intrinsĂšque n’est pas rĂ©duite, elle est dĂ©portĂ©e sur l’utilisateur, qui doit alors compenser.

Loi des abstractions qui fuient

Loi des abstractions qui fuient sur Joel on Software

Toutes les abstractions non-triviales fuient plus ou moins. (Joel Spolsky)

Cette loi Ă©nonce que les abstractions, qui sont gĂ©nĂ©ralement utilisĂ© en informatique pour simplifier l’utilisation de systĂšmes complexes, vont “fuirent” une partie du systĂšme sous-jacent dans certaines situations.

Si on prends l’exemple de la lecture d’un fichier. Les APIs pour les systĂšmes de fichier sont une abstraction des systĂšmes plus bas niveau du kernel, qui sont eux mĂȘme une abstraction du processus physique de changement de donnĂ©es sur le disque (ou la mĂ©moire flash pour un SSD). Dans la plupart des cas, l’abstraction consistant Ă  traiter un fichier comme un flux de donnĂ©es binaire fonctionnera comme prĂ©vu. Cependant, avec un disque magnĂ©tique la lecture de donnĂ©es sĂ©quentielle sera significativement plus rapide que la lecture de donnĂ©es alĂ©atoire (due aux couts plus Ă©levĂ©s d’erreurs de page). Mais pour un disque SSD, ces couts supplĂ©mentaires n’existent pas. On peut donc voir que les dĂ©tails sous-jacents doivent ĂȘtre compris pour gĂ©rer cet exemple efficacement (par exemple les fichiers d’index de base de donnĂ©es sont structurĂ©s de maniĂšre Ă  limiter le surcout des accĂšs alĂ©atoires). L’abstraction “fuit” certains dĂ©tails d’implĂ©mentation que le dĂ©veloppeur peut donc avoir besoin de connaitre.

L’exemple ci-dessus peut devenir plus complexe quand des abstractions supplĂ©mentaires sont prĂ©sentes. Par exemple, le systĂšme d’exploitation Linux permet aux fichiers d’accĂ©der Ă  des fichiers via un rĂ©seau, mais les prĂ©sente sur la machine comme Ă©tant “normaux”. Cette abstraction va fuir s’il y a des problĂšmes de rĂ©seau. Si un dĂ©veloppeur traite ces fichiers comme Ă©tant “normaux” sans considĂ©rer le fait qu’ils peuvent ĂȘtre sujets Ă  de la latence ou des Ă©checs rĂ©seaux, le logiciel fonctionnera mal.

L’article dĂ©crivant cette loi suggĂšre qu’une dĂ©pendance trop forte aux abstractions combinĂ©e Ă  une faible comprĂ©hension des processus sous-jacent rend le problĂšme plus complexe Ă  gĂ©rer dans certains cas.

Voir aussi :

Exemples concrets :

Loi de futilité

Loi de futilité sur Wikipedia

Cette loi suggĂšre que les organisations donnent largement plus de temps et d’attention Ă  des dĂ©tails triviaux ou cosmĂ©tiques qu’aux problĂšmes fondamentaux et difficiles.

L’exemple fictif couramment utilisĂ© est celui d’un comitĂ© approuvant les plans d’une centrale nuclĂ©aire et qui passe la majoritĂ© de son temps Ă  parler du local Ă  vĂ©lo plutĂŽt que de la conception de la centrale en elle mĂȘme. Il peut ĂȘtre difficile de participer de maniĂšre utile Ă  des discussions concernant des sujets vastes et complexes sans une grande expertise ou prĂ©paration. Cependant les gens veulent ĂȘtre vu comme participant de maniĂšre utile. D’oĂč une tendance Ă  trop se focaliser sur des dĂ©tails qui peuvent ĂȘtre abordĂ©s simplement mais qui n’ont pas particuliĂšrement d’importance.

L’exemple ci-dessus Ă  conduit Ă  l’utilisation du terme ‘Bike Shedding’ (en rapport Ă  l’abri Ă  vĂ©lo) comme expression dĂ©signant une perte de temps sur des dĂ©tails triviaux. Un autre terme apparentĂ© est ‘Yak Shaving’, qui dĂ©signe une activitĂ© apparemment inutile qui fait partie d’une longe chaine de prĂ©-requis Ă  la tĂąche principale.

Philosophie d’Unix

The Unix Philosophie d’Unix sur Wikipedia

La philosophie d’Unix consiste Ă  dire que les programmes informatiques doivent ĂȘtre petits, ne faire qu’une seule chose et la faire bien. Cela peut rendre plus simple la construction de systĂšmes en combinant des unitĂ©s simples petites et bien dĂ©finies plutĂŽt que des programmes larges, complexes et servant Ă  plusieurs choses.

Certaines pratiques rĂ©centes comme l’architecture en microservices peut ĂȘtre vue comme une application de cette loi, oĂč les services sont petits et ne font qu’une seule chose, permettant la crĂ©ation de comportements complexes Ă  partir de briques qui sont simples.

ModĂšle de Spotify

ModĂšle de Spotify sur Spotify Labs

Le modĂšle de Spotify est une approche Ă  la structure d’entreprise et des Ă©quipes qui a Ă©tĂ© popularisĂ©e par Spotify. Dans ce modĂšle, les Ă©quipes sont organisĂ©es autour des fonctionnalitĂ©s plutĂŽt que des technologies.

Le modĂšle de Spotify a Ă©galement popularisĂ© les concepts de Tribus, Guildes, et Chapitres qui sont d’autres Ă©lĂ©ments de leur structure.

Loi de Wadler

Loi de Wadler sur wiki.haskell.org

Dans toute conception de langage, le temps total passé à discuter un aspect de cette liste est proportionnel à deux élevé à la puissance de la position correspondante.

  1. SĂ©mantique
  2. Syntaxe
  3. Syntaxe lexicale
  4. Syntaxe lexicale des commentaires (en clair, pour chaque heure passée sur la sémantique, 8 heures seront passées sur la syntaxe des commentaires)

Similaire Ă  la loi de trivialitĂ©, la loi de Wadler Ă©nonce que lors de la conception d’un langage, le temps passĂ© Ă  discuter des diffĂ©rents aspects est inversement proportionnel Ă  l’importance de ces aspects.

Voir aussi :

Loi de Wheaton

Le lien

Le jour officiel

Ne soyez pas un connard. Wil Wheaton

InventĂ©e par Will Wheaton (Star Trek: The Next Generation, The Big Bang Theory), cette loi simple, concise et puissante vise Ă  augmenter l’harmonie et le respect au sein d’un environnement professionnel. Elle peut ĂȘtre appliquĂ©e lorsqu’on parle Ă  ses collĂšgues, effectue une revue de code (code review), argumente contre un autre point de vue, critique et de maniĂšre gĂ©nĂ©rale, lors de la plupart des interactions entre humains.

Principes

Les principes sont généralement des lignes directrices liés à la conception.

Principe de Dilbert

Principe de Dilbert sur Wikipedia

Les entreprises tendent à promouvoir systématiquement les employés incompétents afin de les sortir du workflow. Scott Adams

Un concept de gestion inventĂ© par Scott Adams (crĂ©ateur du comic strip Dilbert) inspirĂ© par le principe de Peter. Suivant le principe de Dilbert, les employĂ©s qui n’ont jamais montrĂ© de compĂ©tence dans leur travail sont promus Ă  des postes de management afin de limiter les dommages qu’ils peuvent causer. Adams expliqua initialement le principe dans un article du Wall Street Journal datant de 1995, et Ă©labora le concept dans son livre de 1996: The Dilbert Principle.

Voir aussi :

Principe de Pareto (rĂšgle des 80/20)

Principe de Pareto sur Wikipedia

La plupart des choses dans la vie ne sont pas réparties également.

Le principe de Pareto suggĂšre que dans certains cas, la majoritĂ© des rĂ©sultats provient d’une minoritĂ© des actions :

Dans les annĂ©es 1940, l’ingĂ©nieur AmĂ©ricano-Roumain Dr. Joseph Juran, qui est largement crĂ©ditĂ© comme Ă©tant le pĂšre du contrĂŽle qualitĂ©, commença Ă  appliquer le principe de Pareto pour rĂ©soudre des problĂšmes de qualitĂ©.

Ce principe est aussi connu comme la rùgle des 80/20, ‘The Law of the Vital Few’ et ‘The Principle of Factor Sparsity’.

Exemples concrets :

Principe de Peter

Principe de Peter sur Wikipedia

Les gens faisant partie d’une hiĂ©rarchie tendent Ă  s’élever Ă  leur “niveau d’incompĂ©tence” Laurence J. Peter

Le principe de Peter est un concept de management inventĂ© par Laurence J. Peter qui observe que les gens qui sont bons dans leur travail sont promus jusqu’à ce qu’ils atteignent un niveau oĂč ils ne rĂ©ussissent plus (leur “niveau d’incompĂ©tence”). À ce point, Ă©tant donnĂ© leur expĂ©rience ils sont moins susceptibles de se faire renvoyer (Ă  part s’ils obtiennent des rĂ©sultats particuliĂšrement mauvais) et vont demeurer dans un poste pour lequel ils ont potentiellement peu de compĂ©tences.

Ce principe est particuliÚrement intéressant pour les ingénieurs qui démarrent leur carriÚre dans des postes profondément techniques mais évoluent souvent vers des postes de managers, qui requiert des compétences fondamentalement différentes.

Voir aussi :

Principe de robustesse (loi de Postel)

Principe de robustesse sur Wikipedia

Soyez tolérant dans ce que vous acceptez, et pointilleux dans ce que vous envoyez

Souvent appliquĂ© dans le dĂ©veloppement d’application serveur, ce principe Ă©nonce que ce que vous envoyez aux autres devrait ĂȘtre aussi minimal et conforme que possible. Mais que vous devriez accepter des donnĂ©es en entrĂ©e non-conforme si elles peuvent ĂȘtre traitĂ©s.

Le but de ce principe est de construire des systĂšmes qui sont robustes dans le sens oĂč ils peuvent gĂ©rer des entrĂ©es mal formĂ©es du moment qu’elles restent comprĂ©hensibles. Cependant, il y a de potentielles implications de sĂ©curitĂ© Ă  accepter des entrĂ©s mal formĂ©es. ParticuliĂšrement si le traitement de ces entrĂ©es n’est pas correctement testĂ©.

À terme, autoriser des entrĂ©es non-conforme peut amoindrir la capacitĂ© d’évolution des protocoles Ă©tant donnĂ© que les utilisateurs vont tĂŽt ou tard compter sur cette tolĂ©rance lors de leur utilisation.

Voir aussi :

SOLID

Il s’agit d’un acronyme qui signifie :

Ces principes sont fondamentaux dans la programmation orientée objet. Ces principes de conception devraient pouvoir aider les développeurs à construire des systÚmes plus facilement maintenable.

Principe de responsabilité unique

Principe de responsabilité unique sur Wikipedia

Chaque module ou classe ne doit avoir qu’une seule responsabilitĂ©.

Le premier des principes ‘SOLID’. Il suggĂšre que les modules ou classes ne devraient faire qu’une chose unique. Autrement dit, un seul petit changement sur une fonctionnalitĂ© d’un programme ne devrait nĂ©cessiter de changer qu’un seul composant. Par exemple, changer la maniĂšre de valider un mot de passe ne devrait nĂ©cessiter un changement qu’à un endroit du programme.

ThĂ©oriquement, cela devrait rendre le code plus robuste et plus simple Ă  modifier. Savoir qu’un composant en train d’ĂȘtre modifiĂ© possĂšde une seule responsabilitĂ© veut aussi dire que tester cette modification devrait ĂȘtre plus simple. Pour reprendre l’exemple precedent, changer le composant concernant la validation d’un mot de passe ne devrait affecter que cette fonctionnalitĂ©. Il est souvent beaucoup plus difficile de rĂ©flĂ©chir aux impacts d’un changement sur un composant qui est responsable de plusieurs choses.

Voir aussi :

Principe ouvert/fermé

Principe ouvert/fermé sur Wikipedia

Les entitĂ©s devraient ĂȘtre ouvertes Ă  l’extension et fermĂ©es Ă  la modification.

Le deuxiĂšme des principes ‘SOLID’. Il Ă©nonce que le comportement des entitĂ©s (classes, modules, fonctions, etc.) devrait ĂȘtre Ă©tendu, mais que le comportement existant ne devrait pas ĂȘtre modifiĂ©.

Imaginons par exemple un module capable de changer un document rĂ©digĂ© en Markdown en HTML. Ce module peut ĂȘtre Ă©tendu en y ajoutant le support pour une nouvelle fonctionnalitĂ© Markdown sans modifier son fonctionnement interne. Le module est en revanche fermĂ© Ă  la modification dans le sens oĂč un utilisateur ne peut pas changer la maniĂšre dont le code existant est rĂ©digĂ©.

Ce principe est particuliĂšrement pertinent pour la programmation orientĂ©e objet, oĂč on cherche la plupart du temps Ă  concevoir des objets qu’on puisse facilement Ă©tendre mais dont le comportement existant ne puisse pas ĂȘtre modifiĂ© de maniĂšre imprĂ©vue.

Voir aussi :

Principe de substitution de Liskov

Principe de substitution de Liskov sur Wikipedia

Il devrait ĂȘtre possible de remplacer un type avec un sous-type sans casser le systĂšme.

Le troisiĂšme des principes ‘SOLID’. Il Ă©nonce que si un composant repose sur un type, alors il devrait ĂȘtre capable d’utiliser un sous-type de ce type sans que le systĂšme ne plante ou qu’il y ai besoin de connaitre les dĂ©tails de ce sous-type.

Imaginons par exemple que nous ayons une mĂ©thode qui lit un document XML depuis une structure reprĂ©sentant un fichier. Si cette mĂ©thode utilise un type ‘fichier’ de base, alors tous les types dĂ©rivant de ‘fichier’ devraient pouvoir ĂȘtre utilisĂ© avec cette fonction. Si ‘fichier’ supporte une recherche partant de la fin et que le parser XML utilise cette fonction, mais que le type dĂ©rivĂ© ‘fichier rĂ©seau’ ne permet pas de recherche en partant de la fin, alors ‘fichier rĂ©seau’ viole le principe.

Ce principe est particuliĂšrement pertinent pour la programmation orientĂ©e objet, oĂč les hierarchies de types doivent ĂȘtre conçues soigneusement pour Ă©viter de brouiller les utilisateurs d’un systĂšme.

Voir aussi :

Principe de ségrégation des interfaces

Principe de ségrégation des interfaces sur Wikipedia

Aucun client de devrait dĂ©pendre de mĂ©thodes qu’il n’utilise pas.

Le quatriĂšme des principes ‘SOLID’. Celui-ci Ă©nonce que les utilisateurs d’un composant ne devraient pas dĂ©pendre des fonctions de ce composant qu’il n’utilise pas.

Par exemple, imaginons que nous ayons une mĂ©thode qui lit un document XML depuis une structure reprĂ©sentant un fichier. Elle nĂ©cĂ©ssite seulement de pouvoir lire des octets, avancer ou reculer dans le fichier. Le principe sera invalidĂ© si cette mĂ©thode a besoin d’ĂȘtre mise Ă  jour lorsqu’une fonctionnalitĂ© sans rapport du fichier change (ex. une mise Ă  jour de modĂšle de permissions pour l’accĂšs au fichier). Il serait prĂ©fĂ©rable pour le fichier d’implĂ©menter une interface ‘seekable-stream’, et pour le lecteur XML de l’utiliser.

Ce principe est particuliĂšrement pertinent pour la programmation orientĂ©e objet, oĂč les interfaces, hierarchies et type abstraits sont utilisĂ©s pour minimiser le couplage entre les diffĂ©rents composants. Le duck typing est une mĂ©thode qui applique ce principe en Ă©liminant les interfaces explicites.

Voir aussi :

Principe d’inversion des dĂ©pendances

Principe d’inversion des dĂ©pendances sur Wikipedia

Les modules de haut niveau ne devraient pas dépendre des implémentations de bas niveau.

Le cinquiĂšme des principes ‘SOLID’. Il Ă©nonce que les composants de hauts niveau ne devraient pas avoir Ă  connaitre les dĂ©tails de leurs dependences.

Prenons par exemple un programme qui lit des mĂ©ta-donnĂ©s depuis un site web. Ce programme possĂšde un composant principal qui connait un autre composant chargĂ© de tĂ©lĂ©charger le contenu de la page, ainsi qu’un autre composant capable de lire les mĂ©ta-donnĂ©s. En prenant en compte le principe d’inversion des dĂ©pendances, le composant principal ne devrait dĂ©pendre que de: un composant abstrait capable de tĂ©lĂ©charger des donnĂ©es binaires, ainsi que d’un composant abstrait capable de lire des mĂ©ta-donnĂ©s depuis un flux binaire. Le composant principal ne devrais pas Ă  connaitre les concepts de TCP/IP, HTTP, HTML, etc.

Ce principe est complexe Ă©tant donnĂ© qu’il semble ‘inverser’ les dĂ©pendances attendues dans un systĂšme (d’oĂč le nom). En pratique cela veut aussi dire qu’un composant ‘orchestrateur’ doit s’assurer que les types abstraits soient correctement implĂ©mentĂ©s. (Pour reprendre l’exemple prĂ©cĂ©dent, quelque chose doit fournir un downloader de fichier HTTP et un liseur de meta tag HTML au composant lisant les mĂ©ta-donnĂ©s.) On touche alors Ă  des patterns tels que l’inversion de contrĂŽle et l’injection de dĂ©pendances.

Voir aussi :

Principe DRY

Principe DRY sur Wikipedia

Dans un systÚme, toute connaissance doit avoir une représentation unique, non-ambiguë, faisant autorité.

DRY est un acronyme pour Don’t Repeat Yourself (ne vous rĂ©pĂ©tez pas). Ce principe vise Ă  aider les dĂ©veloppeurs Ă  rĂ©duire les rĂ©pĂ©titions de code et Ă  garder l’information Ă  un seul endroit. Il a Ă©tĂ© formulĂ© en 1999 par Andrew Hunt et Dave Thomas dans le livre The Pragmatic Developer.

L’opposĂ© de DRY serait WET (Write Everything Twice ou We Enjoy Typing, qu’on peut traduire par Tout Ă©crire en double ou On aime taper au clavier).

En pratique, si vous avez la mĂȘme information dans deux (ou plus) endroits, vous pouvez utiliser DRY pour les fusionner et rĂ©utiliser cette unique instance partout oĂč c’est nĂ©cessaire.

Voir aussi :

Principe KISS

KISS sur Wikipedia

Keep it simple, stupid. (Ne complique pas les choses)

Le principe KISS Ă©nonce que la plupart des systĂšmes fonctionnent mieux s’ils sont simples que compliquĂ©s. Par consĂ©quent, la simplicitĂ© devrait ĂȘtre un but essentiel dans la conception et toute complexitĂ© inutile devrait ĂȘtre Ă©vitĂ©. Provenant de la marine AmĂ©ricaine en 1960, la phrase est attribuĂ©e Ă  l’ingĂ©nieur Kelly Johnson.

Le principe est exemplifiĂ© le mieux par l’histoire de Johnson qui donna Ă  une Ă©quipe d’ingĂ©nieurs une poignĂ©e d’outils et le dĂ©fi de concevoir un avion de chasse qui soit rĂ©parable par un mĂ©canicien lambda, sur le terrain, en condition de combat avec ces outils uniquement. Le “supid” fait donc rĂ©fĂ©rence Ă  la relation entre la maniĂšre dont les choses cassent et la sophistication des outils Ă  disposition pour les rĂ©parer, et non aux capacitĂ©s des ingĂ©nieurs eux-mĂȘmes.

Voir aussi :

YAGNI

YAGNI sur Wikipedia

Il s’agit d’un acronyme pour You Ain’t Gonna Need It. Que l’on peut traduire par: “vous n’en aurez pas besoin”.

ImplĂ©mentez les choses uniquement quand vous en avez rĂ©ellement besoin et non quand vous pensez que vous en aurez besoin plus tard. (Ron Jeffries) (Co-fondateur de XP et auteur du livre “Extreme Programming Installed”)

Ce principe d’Extreme Programming (XP) suggĂšre que les dĂ©veloppeurs ne devraient implĂ©menter que les fonctionnalitĂ©s qui sont nĂ©cessaires immĂ©diatement et Ă©viter de tenter de prĂ©dire l’avenir en implĂ©mentant des fonctionnalitĂ©s qui pourraient ĂȘtre nĂ©cessaires plus tard.

AdhĂ©rer Ă  ce principe devrait rĂ©duire la quantitĂ© de code inutilisĂ© dans le codebase et permet d’éviter de passer du temps sur des fonctionnalitĂ©s qui n’apportent rien.

Voir aussi :

Illusions de l’informatique distribuĂ©e

Illusions de l’informatique distribuĂ©e sur Wikipedia

Aussi connues sous le nom de illusions de l’informatique en rĂ©seau, les illusions sont une liste de suppositions (ou croyances) concernant l’informatique distribuĂ©e, qui peuvent amener Ă  des problĂšmes dans le dĂ©veloppement logiciel. Les suppositions sont :

Les quatre premiers Ă©lĂ©ments furent listĂ©s par Bill Joy et Tom Lyon vers 1991 et qualifiĂ©s pour la premiĂšre fois d’“illusions de l’informatique distribuĂ©e” par James Gosling. L. Peter Deutsch ajouta les 5Ăšme, 6Ăšme et 7Ăšme illusions. Gosling ajouta la 8Ăšme illusion vers la fin des annĂ©es 90.

Le groupe Ă©tait inspirĂ© par ce qui se passait Ă  l’époque chez Sun Microsystems.

Ces illusions devraient ĂȘtre gardĂ©es Ă  l’esprit pour concevoir du code rĂ©sistant Ă©tant donnĂ© que chacune d’entre elle peut mener Ă  une perception biaisĂ©e qui ne prend pas en compte la rĂ©alitĂ© et la complexitĂ© des systĂšmes distribuĂ©s.

Voir aussi :

À lire

Si vous avez trouvĂ© ces concepts intĂ©ressants, vous apprĂ©cierez peut ĂȘtre aussi les livres suivants :

Traductions

GrĂące Ă  l’aide de merveilleux contributeurs, Hacker Laws est disponible dans plusieurs langues. N’hĂ©sitez pas Ă  envisager de sponsoriser les modĂ©rateurs !

Langue Moderateur Status
đŸ‡§đŸ‡· Brasileiro / BrĂ©silien Leonardo Costa gitlocalized
🇹🇳 äž­æ–‡ / Chinois Steve Xu Partiellement complĂšte
đŸ‡©đŸ‡Ș Deutsch / Allemand Vikto gitlocalized
đŸ‡«đŸ‡· Français / French Kevin Bockelandt gitlocalized
đŸ‡ŹđŸ‡· ΔλληΜÎčÎșÎŹ / Grecque Panagiotis Gourgaris gitlocalized
🇼đŸ‡č Italiano / Italien Claudio Sparpaglione Partiellement complĂšte
đŸ‡°đŸ‡· 한ꔭ얎 / CorĂ©en Doughnut Partiellement complĂšte
đŸ‡±đŸ‡» LatvieĆĄu Valoda / Letton Arturs Jansons gitlocalized
đŸ‡·đŸ‡ș РуссĐșая ĐČĐ”Ń€ŃĐžŃ / Russe Alena Batitskaya Partiellement complĂšte
đŸ‡Ș🇾 Castellano / Espagnol Manuel Rubio (Sponsor) Partiellement complĂšte
đŸ‡čđŸ‡· TĂŒrkçe / Turc Umut IĆŸÄ±k gitlocalized

Si vous souhaitez mettre Ă  jour une traduction, vous pouvez ouvrir une pull request. Si vous voulez ajouter une nouvelle langue, connectez vous Ă  GitLocalize pour crĂ©er un compte, puis crĂ©ez une issue afin que je vous ajoute au projet ! Il serait Ă©galement trĂšs apprĂ©ciĂ© d’ouvrir une pull request correspondante qui met Ă  jour le tableau ci-dessus et la liste de liens au dĂ©but de ce fichier.

Projets liés

Contribuer

N’hĂ©sitez pas Ă  contribuer ! Vous pouvez crĂ©er une issue pour suggĂ©rer une addition ou un changement, ou ouvrir une pull request pour proposer vos propres modifications.

Merci de lire le guide de contribution pour connaitre les pré-requis concernant le style, le contenu, etc. Veuillez lire également le code de conduite afin de le respecter lors des discussions sur le projet.

TODO

Si vous ĂȘtes atteris ici vous avez cliquĂ© sur un lien concernant un sujet qui n’a pas encore Ă©tĂ© rĂ©digĂ©. DĂ©solĂ© ! Tout n’est pas encore terminĂ©.

N’hĂ©sitez pas Ă  crĂ©er une issue pour avoir plus de dĂ©tails, ou ouvrez une pull request pour soumettre votre propre texte sur le sujet.