👨🏼‍🔬 🎵 😄 Lois de programmation 🍕 😩 😷

Lois, théories, principes et modèles utiles aux développeurs

introduction

Traduction du référentiel github.com/dwmkerr/hacker-laws

Dans les discussions liées au développement de logiciels, les gens parlent souvent de lois différentes. Ce référentiel contient des liens et des descriptions de certains des plus célèbres d'entre eux.

Il contient des explications sur certaines lois, principes et lois, mais il n'y a aucune agitation en leur faveur. Les utiliser ou non est toujours un point discutable, et tout dépend de ce sur quoi vous travaillez.

Les lois

La loi d'Amdahl

La loi d'Amdahl est une formule qui démontre le potentiel d'accélération d'une tâche de calcul qui peut être réalisée avec une augmentation de la quantité de ressources système. Il est généralement utilisé dans le calcul parallèle et peut prédire les avantages réels d'augmenter le nombre de processeurs, en tenant compte des limites de parallélisme du programme.

Nous donnons un exemple. Si le programme se compose de deux parties - la partie A, qui doit être exécutée sur un processeur, et la partie B, qui peut être parallélisée, il est clair que les avantages d'ajouter plusieurs processeurs au système exécutant le programme sont limités. Potentiellement, cela peut accélérer considérablement la partie B - mais la vitesse de la partie A ne changera pas.

Le diagramme suivant montre des exemples de gains de vitesse potentiels:

Comme vous pouvez le voir, même si 50% du programme peut être parallélisé, les avantages de l'ajout de plus de 10 processeurs séparés seront négligeables. Si le programme peut être parallélisé à 95%, les améliorations seront perceptibles même après l'ajout de milliers de processeurs.

Avec le ralentissement de la loi de Moore et l'accélération du processeur, la parallélisation devient la clé pour améliorer l'efficacité. La programmation graphique est un excellent exemple - une programmation moderne basée sur des shaders vous permet de dessiner des fragments de l'image en parallèle, donc dans les cartes graphiques modernes, vous pouvez trouver des milliers de cœurs de processeur (GPU ou modules shader).

Théorie des fenêtres brisées

La théorie des fenêtres brisées affirme que les signes visibles de criminalité (ou le manque de préoccupation pour l'environnement) entraînent une augmentation du nombre et de la gravité de la criminalité (et une nouvelle détérioration de l'environnement).

Cette théorie a été appliquée au développement de logiciels, suggérant qu'une mauvaise qualité de code (ou la soi-disant " dette technique ") peut donner l'impression que toutes les tentatives d'amélioration de la qualité seront ignorées ou sous-estimées, ce qui conduira à l'apparition d'un nouveau mauvais code. Cet effet se développe en cascade, c'est pourquoi la qualité se dégrade avec le temps.

Brooks Law

L'ajout de ressources humaines supplémentaires à un projet tardif a encore plus retardé sa production.

La loi de Brooks dit que dans de nombreux cas, les tentatives d'accélérer la publication d'un projet qui est déjà en retard en y ajoutant des personnes supplémentaires conduisent au fait que le projet est publié encore plus tard qu'il ne le pourrait. Cependant, Brooks souligne qu'il s'agit d'une simplification excessive du problème. Il a raisonné comme suit: compte tenu du coût du temps nécessaire à la mise en service de nouvelles ressources et de la communication des gens entre eux, à court terme le taux de développement du projet baisse. En outre, de nombreuses tâches peuvent ne pas être soumises à une séparation, c'est-à-dire qu'elles ne peuvent pas être facilement réparties entre les ressources, dont le montant a été augmenté, de sorte que l'augmentation potentielle de la vitesse n'est pas si importante.

Le dicton courant «neuf femmes ne peuvent pas donner naissance à un bébé en un mois» fait référence à la loi Brooks, en particulier parce que certains types de travail ne peuvent être divisés ou parallélisés.

C'est le thème principal du livre Mythical Man-Month.

Loi de Conway

La loi de Conway stipule que les limites techniques du système conçu refléteront la structure de l'organisation. On se souvient souvent de lui en essayant d'améliorer l'organisation. La loi stipule que si une organisation est structurée en de nombreux petits modules indépendants, le programme qu'elle crée sera le même. Si l'organisation sera construite autour de verticales, basées sur certaines fonctionnalités ou services, alors son logiciel reflétera ce fait.

Loi de Cunningham

La meilleure façon de trouver la bonne réponse sur Internet n'est pas de poser une question, mais de publier une réponse délibérément erronée.

Stephen McGeady dit qu'au début des années 1980, Ward Cunningham lui a donné des conseils: "La meilleure façon de trouver la bonne réponse sur Internet n'est pas de poser une question, mais de publier une réponse délibérément fausse." McGeady l'a appelé "la loi de Cunningham", bien que Cunningham lui-même le nie et dit qu'il est "mal cité". Bien que la phrase fasse à l'origine référence à une communication sur Usenet, la loi a depuis été utilisée pour décrire le travail et d'autres communautés (Wikipedia, Reddit, Twitter, Facebook).

Numéro Dunbar

Le nombre de Dunbar est une limite sur le nombre de liens sociaux permanents qu'une personne peut maintenir. Il s'agit de relations impliquant la connaissance des traits distinctifs d'un individu particulier, dont le lien doit être maintenu, son caractère, ainsi que son statut social et ses liens avec d'autres personnes.

Le nombre exact de ces relations est inconnu. Dunbar lui-même a suggéré qu'une personne ne peut supporter confortablement pas plus de 150 connexions de ce type. Il le décrit dans un contexte plus social: "Le nombre de personnes que vous n’hésitez pas à rejoindre sans invitation à boire ensemble si vous les rencontrez accidentellement au bar." En règle générale, les estimations de ce nombre varient de 100 à 250.

Comme les relations stables entre les personnes, le maintien de la relation d'un programmeur avec le code nécessite beaucoup d'efforts. Lorsque nous sommes confrontés à des projets grands et complexes ou à la propriété de nombreux petits, nous nous appuyons sur certains accords, politiques et procédures. Il est important de prendre en compte le nombre Dunbar non seulement lors de l'augmentation du nombre d'employés, mais également lors de la détermination de l'échelle de l'équipe ou du moment où le système doit acquérir des outils auxiliaires pour la modélisation et l'automatisation de la logistique. Dans le contexte d'ingénierie, il s'agit du nombre de projets (ou de la complexité normalisée d'un projet) pour lesquels vous seriez en toute confiance inclus dans le groupe de support de code.

Loi de Goll

Un système complexe fonctionnant venait nécessairement d'un système simple fonctionnant. Un système complexe conçu à partir de zéro ne fonctionne jamais, et il est impossible de le réparer pour qu'il fonctionne. Vous devez recommencer avec un système de travail simple.

La loi de Goll suggère que les tentatives de développement d'un système très complexe échoueront très probablement. Les systèmes de grande complexité sont rarement créés en une seule séance - ils évoluent à partir de systèmes plus simples.

Un exemple classique est un réseau mondial. Dans l'état actuel, c'est un système de grande complexité. Cependant, il a été initialement identifié comme un moyen simple d'échanger du contenu entre les institutions. Elle a très bien réussi à faire face à ces objectifs et a évolué, devenant au fil du temps un objectif plus complexe.

Loi de Goodhart

Tout modèle statistique observé a tendance à s'effondrer dès qu'une pression est exercée sur lui pour le contrôler.

Il est également souvent formulé comme:

Lorsqu'une mesure devient un objectif, elle cesse d'être une bonne mesure.
Marilyn Strain

La loi précise qu'une optimisation basée sur certaines mesures peut conduire à la dépréciation de ces mesures. Des mesures trop sélectives (KPI) appliquées aveuglément à un processus entraînent une distorsion. Les gens s'efforcent d'optimiser le processus localement, «trompant» le système afin de satisfaire une certaine métrique, au lieu de prêter attention au résultat global de leurs actions.

Exemples:

Les tests sans revendications satisfont aux attentes en matière de couverture de code, malgré le fait qu'une telle métrique ait été créée pour que le programme soit bien testé.
L'évaluation de l'efficacité du développeur en fonction du nombre de lignes contribuées au projet conduit à des ballonnements injustifiés du code.

Rasoir Hanlon

N'attribuez jamais la méchanceté à ce qui est complètement expliqué par la stupidité.

Le principe stipule que les actions conduisant à un résultat négatif pourraient être menées non avec de mauvaises intentions. Le résultat négatif est probablement dû au fait que ces actions et leurs conséquences n'étaient pas bien comprises.

Loi de Hofstader

La réalisation d'une tâche prend toujours plus de temps que prévu, même si vous avez pris en compte la loi de Hofstader.

Vous pouvez rencontrer des références à cette loi lorsque vous traitez des estimations du temps passé sur un projet. Dans le domaine du développement logiciel, il semble un truisme que nous ne soyons pas très bien en mesure d'estimer avec précision le temps nécessaire pour achever le projet.

Citation du livre " Gödel, Escher, Bach: This Endless Garland ".

Loi Hutber

L'amélioration équivaut à la destruction.

Cette loi stipule que l'amélioration d'une partie du système conduit à la destruction d'autres parties, ou masque d'autres types de destruction, ce qui conduit généralement à la dégradation du système par rapport à son état actuel.

Par exemple, la diminution du temps de réponse dans une certaine partie du système peut entraîner une augmentation de son débit et, par conséquent, des problèmes de capacité quelque part sur le chemin du flux de demandes, ce qui peut affecter un autre sous-système.

Le cycle du battage médiatique et la loi d'Amar

Nous avons tendance à surestimer l'impact de la technologie à court terme et à le sous-estimer à long terme.

Le cycle de battage médiatique est une visualisation de l'enthousiasme et du développement de la technologie au fil du temps, construit à l'origine par Gartner. Il est mieux illustré par le graphique:

après l'avènement de la technologie, sa popularité atteint le sommet des attentes gonflées, puis plonge dans le creux de la déception, monte le long de la pente de l'illumination et atteint le plateau de la productivité

En bref, le cycle fait valoir qu'une source d'enthousiasme naît généralement autour des nouvelles technologies et de leurs conséquences potentielles. Les équipes sont souvent rapidement accros à ces technologies et sont souvent déçues des résultats. C'est peut-être parce que la technologie n'est pas encore suffisamment développée ou que les méthodes pour son application n'ont pas encore été réfléchies. Après un certain temps, les capacités de la technologie augmentent et le nombre d'applications pratiques augmente, après quoi les équipes peuvent enfin devenir productives.

Loi d'Hiram

Lorsque vous atteignez un nombre suffisant d'utilisateurs de l'API, peu importe les fonctionnalités que vous avez promises à tout le monde: pour toutes les fonctionnalités possibles du comportement de votre système, il y aura un utilisateur en fonction.

La loi d'Hiram postule que si votre API a suffisamment d'utilisateurs, il y aura un utilisateur qui en dépendra pour tout comportement possible de votre système (même pas décrit dans le contrat public). Un exemple trivial serait les fonctionnalités d'API non fonctionnelles, telles que le temps de réponse. Un exemple plus subtil est celui des consommateurs qui dépendent de la détermination du type d'erreur en appliquant la fonction regex à sa description. Même si le contrat public ne dit rien sur le contenu du message et implique que les utilisateurs doivent utiliser le code d'erreur, certains d'entre eux peuvent décider d'utiliser le message et la modification du message interrompra l'API pour ces utilisateurs.

Loi de Kernigan

Le débogage du code est deux fois plus difficile que de l'écrire. Par conséquent, si vous écrivez du code à la limite de vos capacités mentales, vous, par définition, ne disposerez pas de suffisamment d'intelligence pour le déboguer.

La loi de Kernigan tire son nom de Brian Kernigan et est tirée d'un livre écrit par lui et Plauger: «Éléments d'un style de programmation».

Tout le monde sait que le débogage du code est deux fois plus difficile que de l'écrire. Par conséquent, si vous faites tous vos efforts mentaux lors de l'écriture de code, comment allez-vous le déboguer?

Bien que la loi soit une hyperbole, elle prétend qu'il vaut mieux utiliser un code simple que complexe, car le débogage de tout problème qui survient dans un code complexe peut être trop coûteux, voire impossible.

Loi de Metcalf

Dans la théorie des réseaux, l'utilité d'un réseau croît à peu près comme le carré de ses utilisateurs.

La loi est basée sur le nombre de connexions par paire possibles au sein du système et est étroitement liée à la loi de Reed. Odlyzhko et d'autres ont fait valoir que les lois de Reed et Metcalf exagéraient la valeur du système, sans tenir compte des limites de la capacité humaine à comprendre le réseau; voir numéro Dunbar.

la loi de Moore

Le nombre de transistors placés sur une puce de circuit intégré double environ tous les 24 mois.

La prédiction de Moore , qui est souvent utilisée pour démontrer la vitesse incroyable de l'amélioration des technologies de fabrication de semi-conducteurs et de puces, était étonnamment précise et a fonctionné des années 1970 à la fin des années 2000. Ces dernières années, la tendance a légèrement changé, notamment en raison des limites physiques de la miniaturisation des composants. Cependant, les progrès de la parallélisation et les changements potentiellement révolutionnaires dans la technologie des semi-conducteurs et les ordinateurs quantiques peuvent signifier que la loi de Moore peut rester vraie pour les prochaines décennies.

La loi de Murphy

Tout ce qui peut mal tourner va mal.

La loi de Murphy, rédigée par Edward A. Murphy, postule que tout ce qui peut mal tourner va nécessairement mal.

Ce dicton est souvent utilisé par les développeurs. Parfois, des choses inattendues se produisent pendant le développement, les tests ou même en production. Il peut être associé à la loi de la méchanceté, qui est plus souvent utilisée en Grande-Bretagne [en fait, elle est également connue en Russie / env. trad.]:

Si quelque chose peut mal tourner, cela arrivera et au pire moment possible.

Habituellement, ces «lois» sont utilisées dans un sens humoristique. Cependant, des phénomènes tels que le biais de confirmation et l'erreur de sélection systématique peuvent amener les gens à être trop intéressés par ces lois (dans la plupart des cas, lorsque tout fonctionne comme il se doit, personne ne le remarque, mais les échecs sont plus visibles et suscitent plus de discussions).

le rasoir d'Occam

Vous ne devez pas multiplier les choses inutilement.

Le rasoir d'Occam prétend que parmi les quelques solutions possibles, la solution qui contient le moins de concepts et d'hypothèses sera la plus probable. Cette solution sera la plus simple et ne résoudra que le problème donné sans introduire de difficultés aléatoires et d'éventuelles conséquences négatives.

Loi de Parkinson

Le travail remplit le temps qui lui est alloué.

Dans le contexte d'origine, la loi était basée sur l'étude de la bureaucratie. Pessimiste, il peut être appliqué au développement de logiciels, en supposant que l'équipe fonctionnera de manière inefficace jusqu'à ce que la date limite du projet commence à approcher, puis il sera pressé de le livrer à temps, ce qui rend la date de fin spécifique plutôt arbitraire.

Si vous le combinez avec la loi de Hofstader, vous obtenez une vue encore plus pessimiste: le travail s'étendra jusqu'à ce qu'il remplisse tout le temps nécessaire pour le terminer, et prend toujours plus que prévu.

L'effet d'une optimisation prématurée

L'optimisation prématurée est la racine de tout Mal.

Dans le travail de Donald Knuth «Programmation structurée avec GoTo», il a écrit: «Les programmeurs passent beaucoup de temps à réfléchir et à s'inquiéter de la vitesse d'exécution des parties non critiques des programmes, et essayer de les rendre plus efficaces a un fort effet négatif si vous pensez à les déboguer et à les soutenir. Nous devons oublier l'efficacité sans importance de 97% du temps: l'optimisation prématurée est la racine de tous les maux. Cependant, dans 3% des cas critiques et critiques, nous ne devons pas laisser passer cette occasion. »

Cependant, l'optimisation prématurée peut également être décrite comme une tentative d'optimiser quelque chose avant de comprendre ce que nous devons faire.

Patt Law

Le secteur technologique est dominé par deux types de personnes: ceux qui comprennent qu'ils ne contrôlent pas et ceux qui contrôlent ce qu'ils ne comprennent pas.

Pour la loi, Patta devrait souvent conclure Patta:

Dans toute hiérarchie technique, une inversion des compétences se développe dans le temps.

Ces déclarations suggèrent qu'en raison des différents critères de sélection et des tendances de l'organisation du groupe, il y aura toujours un certain nombre de personnes expérimentées aux niveaux de travail de l'organisation technique, et il y aura toujours des gens au niveau de la direction qui n'auront aucune idée de la complexité et des problèmes du travail qu'ils gèrent.

Cependant, il convient de souligner que ces lois sont une généralisation très grossière et peuvent être applicables à certains types d'organisations et non à d'autres.

Loi de Reed

L'utilité des grands réseaux, en particulier les réseaux sociaux, évolue de façon exponentielle avec la croissance de la taille du réseau.

Cette loi est basée sur la théorie des graphes, où l'utilité évolue comme le nombre de sous-groupes possibles, augmentant plus rapidement que le nombre de participants ou les connexions par paires possibles. Odlyzhko et d'autres ont fait valoir que les lois de Reed et Metcalf exagéraient la valeur du système, sans tenir compte des limites de la capacité humaine à comprendre le réseau; voir numéro Dunbar.

La loi de conservation de la complexité (loi de Tesler)

La loi stipule que le système présente une certaine complexité, qui ne peut être réduite.

Une partie de la complexité du système peut survenir involontairement. C'est le résultat d'une mauvaise structure, d'erreurs ou d'une modélisation infructueuse du problème résolu. La complexité par inadvertance peut être réduite ou éliminée. Cependant, certains types de complexité sont une conséquence intégrale de la complexité de la tâche elle-même. Cette complexité peut être déplacée, mais pas éliminée.

L'un des éléments intéressants de cette loi est l'hypothèse que même avec la simplification de l'ensemble du système, sa complexité interne ne diminue pas, mais revient à l'utilisateur, qui a plus de mal à se comporter.

La loi des abstractions fluides

Toutes les abstractions non triviales sont sujettes à un flux à une certaine limite.

Cette loi stipule que les abstractions, qui sont généralement utilisées en informatique pour simplifier le travail avec des systèmes complexes, fuient dans certaines situations, libérant les éléments des systèmes qui les sous-tendent, ce qui rend l'abstraction imprévisible.

Un exemple est le téléchargement d'un fichier et la lecture de son contenu. L'API du système de fichiers est une abstraction des systèmes de noyau de niveau inférieur, qui eux-mêmes sont une abstraction des processus physiques associés à la modification des données sur une plaque magnétique (ou dans une mémoire flash SSD). Dans la plupart des cas, une abstraction représentant un fichier en tant que flux de données binaires fonctionnera. Cependant, la lecture séquentielle des données d'un disque magnétique ira plus vite que l'accès aléatoire à ces derniers, mais les SSD n'auront pas de tels problèmes. Vous devez comprendre les détails approfondis afin de gérer ces cas (par exemple, les fichiers de base de données d'index sont structurés pour réduire le temps d'accès aléatoire), lorsque l'abstraction donne une fuite de détails d'implémentation que le développeur doit connaître.

L'exemple ci-dessus peut devenir plus compliqué lors de l'ajout de nouvelles abstractions. Linux vous permet d'accéder aux fichiers sur le réseau, mais ils sont visibles localement comme «normaux». Cette abstraction fuira en cas de problèmes de réseau. Si le développeur les traite comme «normaux», sans tenir compte du fait qu'ils sont sujets à des problèmes de retards et de pannes de réseau, sa solution sera sous-optimale et boguée.

Dans l'article décrivant la loi, on suppose qu'une dépendance excessive aux abstractions, associée à une mauvaise compréhension des processus sous-jacents, complique même dans certains cas le processus de résolution du problème.

Exemples: démarrage lent de Photoshop. Je suis tombé sur ce problèmedans le passé. Photoshop a démarré très lentement, parfois cela prenait quelques minutes. Apparemment, le problème était qu'au démarrage, il lit les informations sur l'imprimante actuelle par défaut. Mais si cette imprimante était une imprimante réseau, cela pourrait prendre un temps extrêmement long. L'abstraction, selon laquelle l'imprimante réseau est similaire à l'imprimante locale, a causé des problèmes à l'utilisateur en cas de mauvaise communication.

Loi de la trivialité

La loi stipule que les groupes consacrent beaucoup plus de temps et d'attention aux discussions sur les questions cosmétiques ou triviales que sur les questions sérieuses et approfondies.

Habituellement, un exemple est le travail d'un comité qui approuve les plans d'une centrale nucléaire, qui discute la plupart du temps de la structure du parking à vélos, que les questions plus importantes de la conception de la station elle-même. Il peut être difficile d'apporter une précieuse contribution à la discussion de sujets très vastes et complexes sans avoir une connaissance approfondie de ce sujet. Cependant, les gens veulent être reconnus pour leurs précieux commentaires. D'où la tendance à se concentrer sur les petits détails, dont il est facile de parler, mais qui ne sont pas nécessairement importants pour le projet dans son ensemble.

L'exemple fictif donné ci-dessus a donné naissance au terme «effet de garage à vélos», qui décrit la perte de temps pour discuter de détails triviaux. Il existe un terme similaire, «coupe de cheveux de yak», qui décrit une activité apparemment sans rapport qui fait partie d'une longue chaîne d'étapes préparatoires nécessaires.

Philosophie Unix

La philosophie Unix est que les composants logiciels doivent être petits et se concentrer sur une bonne tâche spécifique. Cela facilite le processus de construction de systèmes en recrutant à partir de modules petits, simples et bien définis, au lieu d'utiliser de grands programmes complexes et multifonctionnels.

Les pratiques modernes, telles que «l'architecture de microservices», peuvent être considérées comme l'application de cette philosophie - les services sont petits, concentrés sur une tâche spécifique, ce qui vous permet de faire un comportement complexe à partir de simples blocs de construction.

Modèle Spotify

L'approche de la structure et de l'organisation des équipes promue par Spotify . Dans ce modèle, les équipes sont organisées autour des fonctions du programme, pas autour de la technologie.

Le modèle fait également la promotion des concepts de tribus, de guildes, de branches - d'autres composantes de la structure organisationnelle.

Loi de Wadler

Lors de la conception d'une langue, le temps total passé à discuter d'une fonctionnalité de cette liste est proportionnel à la puissance du numéro de position de cette fonctionnalité dans la liste.
0. Sémantique.
1. La syntaxe.
2. Syntaxe lexicale.
3. La syntaxe lexicale des commentaires.

Autrement dit, pour chaque heure consacrée à la sémantique, il y a 8 heures consacrées à la syntaxe des commentaires.

Comme la loi de la trivialité, la loi de Wadler postule que lors de la conception d'une langue, le temps consacré aux structures linguistiques est disproportionné par rapport à l'importance de ces structures.

Loi de Wheaton

Ne soyez pas une chèvre.

Cette loi concise, simple et complète, formulée par Will Wheatan, vise à accroître l'harmonie et le respect au sein d'une organisation professionnelle. Il peut être utilisé dans des conversations avec des collègues, lors d'une évaluation experte du code, dans la recherche d'objections à d'autres points de vue, dans la critique et, en général, dans la communication professionnelle entre les personnes.

Des principes

Les principes sont le plus souvent associés à des conseils sur la conception de programmes.

Principe de Dilbert

Dans les entreprises, il y a une tendance à transformer les employés incompétents en managers afin de les éliminer du processus de travail.

Concept de gestion développé par Scott Adams (créateur des bandes dessinées de Dilbert), inspiré du principe de Peter. Selon le principe Dilbert , les salariés qui ne pouvaient être considérés comme compétents sont promus managers afin de limiter les éventuels dommages à l'entreprise. Adams a d'abord expliqué ce principe dans un article pour le Wall Street Journal en 1995, puis l'a décrit en détail dans son livre de 1996, The Dilbert Principle.

Principe de Pareto (règle 80/20)

Pour la plupart, tout dans la vie est réparti de manière inégale.

Le principe de Pareto stipule que, dans certains cas, une plus petite partie de l'investissement est responsable de la plupart des résultats:

80% du programme peut être écrit en 20% du temps (et les 20% les plus difficiles prennent les 80% restants).
20% de l'effort donne 80% du résultat.
20% du travail crée 80% du profit.
20% des erreurs entraînent 80% des plantages du programme.
20% des fonctions sont utilisées 80% du temps.

Dans les années 40, un ingénieur américain d'origine roumaine, Joseph Juran, souvent appelé le père de la gestion de la qualité, a commencé à appliquer le principe de Pareto aux problèmes de qualité.

En outre, ce principe est connu, en tant que règle 80/20, la loi du plus important petit, le principe de la déficience des facteurs.

Exemples: En 2002, Microsoft a signalé qu'après avoir corrigé 20% des erreurs les plus courantes, 80% des problèmes et plantages liés à Windows et Office seront corrigés.

Principe de Peter

Dans le système hiérarchique, chaque individu a tendance à s'élever au niveau de son incompétence.

Le concept managérial créé par Lawrence Johnston Peter note le fait que les personnes qui font du bon travail sont promues jusqu'à ce qu'elles atteignent un niveau où elles ne font plus face («niveau d'incompétence»). Puisqu'ils ont grimpé assez haut, ils sont déjà moins susceptibles d'être licenciés (à moins qu'ils ne créent une sorte de non-sens complet), donc ils resteront dans cette position, pour laquelle ils n'ont pas les compétences nécessaires, car leurs compétences comportementales dans l'organisation ne coïncident pas nécessairement avec les compétences nécessaires pour réussir dans ce poste.

Ce principe est particulièrement intéressant pour les ingénieurs qui commencent à travailler avec des rôles purement techniques, mais construisent souvent une carrière menant à la gestion d'autres ingénieurs - ce qui nécessite un ensemble de compétences complètement différent.

Le principe de fiabilité (loi de Postel)

Soyez prudent sur vos activités et libéral sur les contributions des autres.

Ce principe est souvent appliqué au développement d'applications serveur. Selon lui, les données que vous envoyez à d'autres doivent être aussi petites que possible et le mieux possible pour se conformer à la norme, mais vous devez accepter vous-même des données non entièrement standardisées en entrée, si vous parvenez à les traiter.

Le but de ce principe est de créer des systèmes fiables capables de digérer des données mal formatées dont la signification est encore compréhensible. Cependant, la réception de données d'entrée non standard peut avoir des conséquences associées à une violation de la sécurité, surtout si la réception de ces données n'a pas été bien testée.

Au fil du temps, la pratique de recevoir des données non standard peut conduire au fait que les protocoles cesseront de se développer, car ceux qui mettent en œuvre l'échange de données commenceront à s'appuyer sur la libéralité des programmes, créant de nouvelles fonctions.

SOLIDE

L'acronyme pour les 5 principes suivants:

S: le principe de responsabilité unique
O: le principe ouvert / fermé
L: le principe de substitution de Liskov
I: le principe de ségrégation d'interface [ Principe de séparation d'interface]
D: Le principe d'inversion de dépendance

Ce sont les principes clés de la programmation orientée objet. Ces principes de conception devraient aider les développeurs à créer des systèmes plus faciles à entretenir.

Principe de responsabilité exclusive

Chaque objet doit avoir une responsabilité, et cette responsabilité doit être entièrement encapsulée dans la classe.

Le premier des principes de SOLID. Le principe stipule que chaque module ou classe ne doit faire qu'une seule chose. Dans la pratique, cela signifie qu'un petit et unique changement dans la fonction d'un programme devrait nécessiter un changement dans un seul composant. Par exemple, pour modifier la procédure de vérification de la complexité du mot de passe, le programme doit être corrigé en un seul endroit.

Théoriquement, cela donne la fiabilité du code et simplifie son changement. Le fait que le composant en cours de modification ait la seule responsabilité devrait signifier qu'il sera plus facile de tester ce changement. La modification du composant de vérification de la complexité des mots de passe dans l'exemple précédent ne devrait affecter que les fonctions liées à la complexité des mots de passe. Il est beaucoup plus difficile de parler de ce qui sera affecté par un changement de composant avec de nombreuses responsabilités.

Le principe d'ouverture / de proximité

Les entités doivent être ouvertes pour l'expansion, mais fermées pour le changement.

Le deuxième des principes de SOLID. Le principe stipule que les entités (classes, modules, fonctions, etc.) doivent permettre à leur comportement d'être étendu, mais leur comportement actuel ne doit pas être modifié.

Un exemple hypothétique: imaginez un module qui peut transformer un document de balisage Markdown en un document de balisage HTML. Si le module peut être étendu pour qu'il apprenne à gérer les nouvelles fonctionnalités du format Markdown sans changer ses fonctions internes, alors le module est ouvert pour l'expansion. Si le module ne peut pas modifier le traitement des fonctions Markdown actuelles, le module est fermé pour modification.

Le principe est particulièrement étroitement associé à la programmation orientée objet, où vous pouvez concevoir des objets faciles à développer, mais vous ne devez pas concevoir des objets dont l'intérieur changera de façon inattendue.

Barbara Liskov Principe de substitution

Il devrait être possible de remplacer le type par un sous-type sans casser le système.

Le troisième des principes de SOLID. Le principe stipule que si un composant dépend d'un type, il devrait être possible d'utiliser des sous-types de ce type afin que le système ne refuse pas de fonctionner ou ne nécessite pas de détails sur ce sous-type.

Par exemple, nous avons une méthode qui lit un document XML à partir d'une structure désignant un fichier. Si la méthode utilise le fichier de type de base, la fonction doit pouvoir utiliser tout ce qui provient du fichier. Si le fichier prend en charge la recherche inversée et que l'analyseur XML utilise cette fonction, mais que le type dérivé «fichier réseau» refuse de fonctionner avec la recherche inversée, le «fichier réseau» viole ce principe.

Le principe est particulièrement lié à la programmation orientée objet, où les hiérarchies de types doivent être modélisées très soigneusement pour éviter toute confusion pour l'utilisateur du système.

Principe de séparation des interfaces

Les entités logicielles ne doivent pas dépendre de méthodes qu'elles n'utilisent pas.

Le quatrième des principes de SOLID. Le principe stipule que les consommateurs d'un composant ne devraient pas dépendre des fonctions d'un composant qu'il n'utilise pas.

Par exemple, nous avons une méthode qui lit un document XML à partir d'une structure désignant un fichier. Il a seulement besoin de lire les octets, d'avancer ou de reculer dans le fichier. Si cette méthode doit être mise à jour en raison de changements dans une structure de fichier qui ne lui est pas liée (par exemple, en raison d'une mise à jour du modèle de contrôle d'accès représentant la sécurité des fichiers), alors ce principe sera violé. Il est préférable que le fichier implémente l'interface "flux de recherche" et la méthode XML pour l'utiliser.

Le principe est particulièrement lié à la programmation orientée objet, où les interfaces, les hiérarchies et les types abstraits sont utilisés pour minimiser les connexions entre les composants. Ce principe oblige à utiliser le typage canard , une méthodologie qui élimine les interfaces explicites.

Principe d'inversion de dépendance

Les modules de niveau supérieur ne doivent pas dépendre de modules de niveau inférieur.

Cinquième des principes de SOLID. Le principe stipule que les composants de contrôle de niveaux supérieurs ne doivent pas connaître les détails de la mise en œuvre de leurs dépendances.

Par exemple, nous avons un programme qui lit les métadonnées d'un site Web. Vraisemblablement, son composant principal doit être conscient d'un composant qui télécharge le contenu d'une page Web et d'un composant qui lit les métadonnées. Si nous prenons en compte le principe de l'inversion de dépendance, alors le composant principal ne dépendra que du composant abstrait recevant des données d'octets, et à son tour, du composant abstrait qui peut lire les métadonnées du flux d'octets. Le composant principal ne saura rien sur TCP / IP, HTTP, HTML, etc.

Le principe est assez compliqué, car il inverse la dépendance attendue du système. En pratique, cela signifie également qu'un composant de contrôle séparé doit garantir la bonne mise en œuvre des types abstraits (dans l'exemple précédent, quelque chose doit fournir le lecteur de métadonnées du composant pour télécharger le fichier via HTTP et pour lire les données de la balise meta HTML).

Ne répétez pas le principe

Chaque élément de connaissance doit avoir une représentation unique, cohérente et faisant autorité au sein du système.

Ne vous répétez pas , ou DRY, aide les développeurs à réduire la répétabilité du code et à conserver les informations au même endroit. Il a été mentionné en 1999 par Andy Hunt et Dave Thomas dans leur livre Pragmatic Programmer.

L'opposé du principe DRY sec] devrait être le principe du WET humide] - "Écrivez tout deux fois" ou "Nous aimons taper" [Nous aimons taper].

En pratique, si la même information est dupliquée en vous à deux endroits ou plus, utilisez le principe DRY, fusionnez-les en un seul endroit et réutilisez-les si nécessaire.

Principe KISS

Restez simple, stupide [ne vous compliquez pas, idiot]

Le principe KISS dit que la plupart des systèmes fonctionnent mieux s'ils ne sont pas compliqués; par conséquent, la simplicité devrait être un objectif clé du développement et une complexité inutile devrait être évitée. Il est originaire de la marine américaine en 1960, et l'expression est attribuée au concepteur d'avions Clarence Johnson.

Il est préférable de l'imaginer en utilisant un exemple lorsque Johnson a donné un petit ensemble d'outils à une équipe d'ingénieurs concepteurs et leur a demandé de concevoir un avion afin qu'un mécanicien moyen puisse le réparer dans un champ de bataille en utilisant uniquement cet ensemble. Ici, stupide dénote la relation entre la façon dont les choses se décomposent et la complexité des outils disponibles pour les réparer, plutôt que les capacités mentales des ingénieurs.

YAGNI

Acronyme de vous n'en aurez pas besoin [vous n'en aurez pas besoin].

N'implémentez toujours les fonctions que lorsque vous en avez vraiment besoin, et non lorsque vous pensez en avoir besoin à l'avenir.

L'auteur de la programmation extrême (XP) et du livre "Installed Extreme Programming" Ron Jeffries suggère que les développeurs ne devraient implémenter que les fonctionnalités nécessaires pour le moment, et ne pas essayer de prédire l'avenir, en mettant en œuvre les fonctionnalités qui pourraient être nécessaires plus tard.

Suivre ce principe devrait réduire la quantité de code inutilisé dans la base de données, ainsi que le gaspillage de temps et d'énergie sur des fonctionnalités qui n'apportent pas d'avantages.

Idées fausses sur l'informatique distribuée

Également connu sous le nom d'erreurs de l'informatique en réseau. Il s'agit d'une liste d'hypothèses concernant l'informatique distribuée qui peuvent entraîner des défaillances logicielles. Ce sont les hypothèses suivantes:

Le réseau est fiable.
Le retard est nul.
La bande passante est infinie.
Le réseau est sécurisé.
La topologie ne change pas.
Il n'y a qu'un seul administrateur.
Le coût d'expédition est nul.
Le réseau est homogène.

Les quatre premiers ont été répertoriés par Bill Joy et Tom Lyon en 1991, et James Gosling les a classés pour la première fois sous le nom de «Network Computing Misconceptions». Peter Deutsch a ajouté les 5e, 6e et 7e illusions. À la fin des années 90, Gosling a ajouté le 8e.

Un groupe d'ingénieurs s'est inspiré des processus en cours à l'époque chez Sun Microsystems.

Ces erreurs doivent être soigneusement prises en compte lors du développement d'un code fiable. Chacune des erreurs peut conduire à une logique incorrecte, incapable de faire face à la réalité et à la complexité des systèmes distribués.

Lois de programmation