Aujourd'hui, je veux spéculer sur la complexité qui nous entoure (les gens) et sur notre capacité à travailler avec elle. Non pas sur la complexité qu'ils écrivent dans les statuts matrimoniaux dans les réseaux sociaux, comme "tout est compliqué", mais sur la complexité des systèmes organisationnels et techniques (d'ailleurs, à mon avis, cela s'est avéré un bon nom pour une spécialité universitaire). Je ne prétends pas être original et, en plus, je ne prétends pas être vrai (d'autant plus que, au moins à moitié, je vais ici rabaisser, bricoler et rigoler). J'ai déjà fait une partie de ce raisonnement quelque part dans les commentaires, mais pour moi, cette question n'est pas fermée. Par conséquent, la vie me jette toujours divers exemples illustratifs qui m'encouragent à réfléchir plus loin. Malgré vendredi, ce n'était pas censé être une lecture divertissante, il n'y aura pas d'images amusantes, voire rien - je vous avais prévenu. Si vous ne voulez lire qu'une phrase,et allez lire le reste des articles amusants du vendredi - le voici: "Simplifiez la complexité là où cela peut être fait, traitez la complexité là où elle ne peut pas être simplifiée et gagnez de l'expérience et la capacité de distinguer le premier cas du second."
Quelques citations des grands :
Comprendre, c'est simplifier.
Simplifier n'est pas comprendre.
La simplicité exige du design et du bon goût.
Restez aussi simple que possible, mais pas plus simple.
La complexité est partout autour de nous. Nous utilisons des dispositifs techniques sophistiqués, nous honorons un code pénal complexe, à l'intérieur de nous un système immunitaire complexe combat le coronavirus, les êtres vivants unicellulaires les plus simples portent des organites étonnamment complexes, la loi la plus simple de Newton s'avère être une simplification d'une loi beaucoup plus complexe à des vitesses non relativistes, et à propos de la complexité des modèles standard et de toutes sortes de mécaniques quantiques différentes, je reste généralement silencieux.
La complexité est toujours un certain ordre, un certain système d'éléments en interaction, et conformément à la définition de ce concept de base, la complexité augmente lorsque le nombre d'éléments augmente et lorsque le nombre et la variété des connexions entre ces éléments augmentent. Peut-être la complexité est-elle synonyme d'ordre, l'antithèse du chaos ?
La vie en général est une augmentation spontanée de la complexité à l'intérieur de nous en raison d'une diminution de la complexité à l'extérieur, comme cela devrait être le cas pour tout système dissipatif décent. L'énergie est redistribuée de telle sorte que pour augmenter la complexité, il faut en dépenser une partie, mais l'organisation qui en résulte, l'ordre qui en résulte, donne « accès » à de grandes quantités d'énergie. C'est, je pense, la raison évolutive de l'augmentation "spontanée" de la complexité de la vie.
Les systèmes complexes qui nous entourent, la complexité de l'organisation de la matière et de l'énergie autour, que l'on veut dissiper, conduisent à une augmentation de la complexité du consommateur, et plus loin dans la chaîne. Une fleur dans laquelle vous ne pouvez accéder au nectar qu'à l'aide d'un long tronc provoque le
Nous sommes des programmeurs, nous créons des systèmes logiciels qui, comme le tronc de ce papillon, doivent être délicats pour automatiser des solutions similaires aux processus complexes et délicats de la vie.
Nous sommes des programmeurs, nous créons des complexessystèmes logiciels, et peu importe ce qu'ils disent, nous aimons créer cette complexité, mais il y a une nuance qui nous distingue des créateurs de tout autre système technique complexe.
Le créateur d'un dispositif matériel et technique complexe est limité par la résistance, les frottements et autres matériaux qui étouffent légèrement le vol de son imagination. La force de friction du programmeur ne se soucie pas ou ne limite pas (à moins qu'il ne soit le développeur du meilleur simulateur de fracturation hydraulique au monde ), la résistance et le poids de l'appareil également, et à partir de là, à mon avis, le principal problème se pose.
Et cela réside dans le fait qu'il est trop facile pour nous, programmeurs, de créer de la complexité. C'est trop facile pour nous. Ctrl + C et Ctrl + V, une nouvelle fonction, un nouveau module, une nouvelle bibliothèque, une nouvelle couche d'abstraction, des macros-shmakros, des préprocesseurs-postprocesseurs, des adaptateurs, des convertisseurs et des façades - tout cela fonctionnera, il vous suffit d'ajouter plus de fréquence et de RAM, et aucun réducteur de friction n'est nécessaire. Dans le monde physique créé, tout n'est pas si simple. Où dans la production industrielle se trouvent des analogues non seulement de la programmation génétique, mais au moins même de simples macros Lisp ?
De nouveau. Il est trop facile en programmation d'ajouter de la complexité, et trop difficile en programmation pour réduire la complexité. De plus, personne n'aime jamais ceux qui réduisent la complexité de la programmation, car ils cassent toujours tout lors du refactoring.
Je ne dis pas que le code complexe est une mauvaise chose. Le code automatise une tâche de la vie réelle, il la reflète dans ses modèles de données, le code ne peut pas être plus simple que nature. La complexité du code augmente avec la complexité du problème, mais un développeur illettré ajoute beaucoup plus de complexité au code que la complexité du problème.
Un développeur compétent s'abstient d'introduire de la complexité dans le code. Pas étonnant que les grands disent que puisque le débogage est plus difficile que l'écriture de code, vous ne pourrez pas déboguer le code que vous avez écrit à la limite de la complexité dont vous disposez. Mais je dirais aussi qu'un développeur compétent ne crée pas de solutions plus difficiles que 84 % de sa capacité à faire face à la complexité.
L'incapacité de concevoir de futurs changements imprévisibles dans les exigences de la vie conduit au fait que le code doit être réécrit et retravaillé. Bonjour, je suis votre casquette. Mais vous ne pouvez pas réécrire des systèmes logiciels complexes à partir de zéro simplement parce que vous ne les aimez pas pour leur complexité.
La complexité et la confusion sont deux choses différentes. Comme je dis toujours aux étudiants qui ont amené le laboratoire de quelqu'un d'autre et sont sûrs qu'ils l'ont compris (deux cadres ont même récemment dit qu'ils pensaient qu'ils devraient apprendre à expliquer le code de quelqu'un d'autre, et non pas écrire le leur - expliquer, Karl, même pas éditer et développer ! ), il est impossible de comprendre que vous ne comprenez pas quelque chose si vous ne le comprenez pas. De ce côté du seuil inductif, la situation « je pense avoir compris » est indiscernable de la situation « j'ai vraiment compris ».
Si quelqu'un vient à vous et vous dit : "C'est trop difficile pour vous ici, nous écrirons à partir de zéro" - vous ne devez pas le laisser entrer, vous devez d'abord démontrer qu'il peut refactoriser l'ancien système. Si vous ne pouvez pas faire face à la complexité que vous avez déjà, par la méthode de refactorisation progressive, alors lorsque vous commencez à écrire vous-même, vous déformerez encore plus la complexité et au final vous ne résoudrez pas le problème. Et pourquoi? Parce qu'il est impossible de comprendre exactement ce que vous ne comprenez pas et sous-estimez, par définition.
Exagérer : même inventer le bon vélo ne fonctionnera pas du premier coup. Le premier vélo sera courbé et oblique, avec trois engrenages reliés par paires, comme dans les images classiques des filles-créatrices. Mais cela vous amènera au niveau de difficulté avec lequel vous devez travailler lors de sa construction, et le deuxième vélo en sortira déjà raisonnable. Ils écrivent leur propre classe de chaînes non pas pour apprendre la syntaxe, mais pour obtenir une partie de complexité vitale.
La complexité d'un même morceau de code, de la même solution, dépend beaucoup de sa complexité déjà présente dans le système, et la complexité du système n'est pas la somme des complexités des sous-systèmes. Et cela fait partie du problème lorsque l'on travaille avec un client ou tout autre observateur extérieur. Vous avez probablement entendu maintes fois : "C'est facile à faire, c'est juste {action X} {à l'intérieur du système Y}, là ça existe déjà {à l'intérieur du système Z} !". C'est le résultat d'une sous-estimation de la complexité systémique, lorsqu'une personne croit que si quelque chose est facile à faire séparément de tout le reste, alors il est facile de le faire à l'intérieur d'un grand système prêt à l'emploi. Si le programme doit mettre en œuvre A, B, C, D, E et F, et qu'ils sont tous approximativement de la même complexité, alors ce serait une forte sous-estimation de penser qu'ils seront construits en même temps.
L'essentiel pour un programmeur expérimenté est la capacité à gérer la complexité. Habituellement, nous ajoutons simplement de la complexité (vous ne pouvez pas simplement refactoriser), mais malheur à quelqu'un qui n'arrive pas à refactoriser (en fait, la simplification !). Ensuite, au lieu de mettre les choses en ordre et de simplifier, un tel développeur enroule des béquilles sur des béquilles et ne peut pas s'arrêter, car les béquilles sont plus faciles à écrire. Avec le temps, il devient de plus en plus difficile d'écrire des béquilles, mais le truc c'est qu'à chaque instant il est de plus en plus difficile d'écrire une autre béquille, mais c'est toujours plus facile que de nettoyer les écuries et de remettre les choses en ordre. Et il y a toujours cette illusion qu'en raison des délais, la solution optimale est d'écrire des béquilles. Hélas, c'est la solution optimale pour le moment, mais très sous-optimale à long terme. Programmation gourmande.
La capacité à faire face à la complexité, à anticiper les conséquences et à voir les relations en dehors de l'objet en question est en soi une grande valeur professionnelle, c'est ainsi que les programmeurs entrent dans les managers et les patrons. En un sens, prédire le comportement d'un système complexe, anticiper les conséquences des nouvelles connexions système émergentes, le "débogage mental" et les "tests de cas extrêmes", "à quoi cela va-t-il conduire", en tant que compétence professionnelle des programmeurs, encourage leur la croissance en gestionnaires, ainsi que des compétences générales d'abstraction, d'induction et de déduction. Certes, la réflexion et l'introspection, l'introversion, comme nombre d'autres compétences professionnelles des programmeurs, au contraire, les limite dans cette croissance.
Comment apprendre à gérer la complexité ? Je n'ai pas de recette autre que des conseils pour apprendre à voir ce qui fonctionne pour cette compétence et ce qui fonctionne contre elle. Mais dans tous les cas, je pense que tout commence par l'éducation la plus élémentaire. Études. La répétition est la mère de l'apprentissage. Je suis enseignant, j'ai une déformation professionnelle : répéter deux fois la même chose. Je suis enseignant, j'ai une déformation professionnelle : répéter deux fois la même chose.
Il y a souvent de nombreuses plaintes concernant l'enseignement en général et l'enseignement à l'école et à l'université en particulier sur le fait qu'on enseigne quelque chose de non pertinent, les cerveaux sont bourrés de connaissances et de compétences inutiles. Ma fille avait de tels cubes creux avec des trous de géométries différentes, et seules des figures plus petites de la forme correspondante tombaient à l'intérieur. Y a-t-il quelqu'un qui pense qu'un enfant à qui l'on apprend à sélectionner une clé de la forme géométrique souhaitée aura besoin des compétences d'un épouvantail à l'âge adulte ?
Je pense qu'une partie très sérieuse de l'éducation, et depuis le début jusqu'à la soutenance de la première thèse, consiste à entraîner le cerveau à faire face à la complexité. Lorsqu'un enfant à l'école apprend à multiplier des nombres à trois chiffres dans une colonne sur une feuille de papier, personne de sensé ne pensera que cette compétence lui sera utile dans la vie. Multiplier correctement deux nombres à trois chiffres dans une colonne est un exercice qui permet de solliciter le cerveau, de garder quelques nombres à l'esprit et de ne pas perdre sa concentration pendant une période de temps donnée. Ajoutez d'abord dans une colonne, puis multipliez, puis divisez. En augmentant la complexité. La capacité de forcer, la capacité de travailler.
Est-ce la bonne qualité ? Cela dépend de qui vous voulez créer ! S'il s'agit d'un "utilisateur qualifié", alors ce n'est pas nécessaire. Si "un homme créateur", alors, je pense, est nécessaire. Dans la vie, la possibilité de multiplier dans une colonne n'est pas utile, dans la vie, il sera utile de pouvoir multiplier les mêmes nombres au téléphone, si vous avez besoin d'une réponse exacte - et la possibilité de ne laisser qu'un chiffre significatif de chaque numéro dans votre esprit sans téléphone et estimer approximativement l'ordre de la valeur obtenue. Et cela, d'ailleurs, n'est rien de plus que la capacité de travailler avec la complexité : prendre rapidement des décisions sur des données complexes, en simplifiant les données d'entrée et en utilisant des estimations approximatives. Mais si quelqu'un pense que dans son travail, il n'aura pas besoin de se concentrer et qu'il effectuera sans erreur des opérations de routine similaires, il est fort probable qu'il ne travaillera pas avec sa tête dans cette vie.
Concluant ceci, bien sûr, un flux de pensées mal ordonné, je veux juste répéter une fois de plus l'appel lancé dans le tout premier paragraphe. Apprenez à simplifier la complexité là où c'est possible, apprenez à gérer la complexité là où elle ne peut pas être simplifiée et développez l'expérience et la capacité à distinguer la première de la seconde.