Le style de code comme norme de développement

Voyons tout de suite, il ne s'agit pas de crochets. Ici, nous parlerons du fonctionnement de notre cerveau et des raisons pour lesquelles le style de code aide à assurer le développement linéaire du projet, accélère considérablement l'adaptation des nouveaux employés et, en général, forme et éduque la culture du développement. J'ai essayé de rassembler dans un article plusieurs études et principes sur le travail du cerveau du développeur, et comment les programmeurs lisent le code, et j'ai également partagé les résultats d'une expérience personnelle.

Intéressant? Bienvenue au chat.



Salut Mon nom est Anton, j'écris backend dans ManyChat. Récemment, nous avons eu un mitap dédié au développement PHP, où j'ai donné une conférence sur le style de code comme l'une des normes de développement. Sur retour d'expérience, il s'est bien rendu aux invités de l'événement, et nous avons décidé de décrypter le reportage sur Habr. Pour ceux qui apprécient particulièrement l'effet de la présence personnelle et qui aiment davantage regarder une vidéo que lire des textes, nous diffusons, qui est disponible dès maintenant. Vous pouvez le trouver ici. Pour ceux qui aiment longrid, bienvenue encore.

Notre cerveau est un réseau neuronal

Cela vaut la peine de commencer par une description de son fonctionnement en général et de la raison pour laquelle vous avez besoin de tout ce dont je parlerai plus tard. Beaucoup d'entre vous connaissent le concept d'un réseau de neurones, ou du moins ont entendu cette phrase, qui depuis plusieurs années est presque un symbole de battage médiatique dans l'espace informatique et le marketing. Même maintenant, de nombreuses entreprises ajoutent «basé sur l'IA» à leurs produits, comme l'autocollant «sans OGM» sur les boulettes. Le réseau de neurones fonctionne sur le principe de la reconnaissance des formes et est extrêmement efficace lorsque vous travaillez avec des données homogènes. Ce sont des images, des vidéos, du son, etc. Le point culminant qui a à voir avec le style du code est le principe sur lequel ils ont été construits. Les perceptrons, cellules du réseau, ont été décrits comme des processus cérébraux et définis bien avant de pouvoir être mis en œuvre dans un réseau fonctionnel, fonctionnel et efficace en raison d'une faible puissance de calcul. Notre cerveau, bien que beaucoup plus puissant, fonctionne de manière similaire. En conséquence, une personne utilise la puissance d'un réseau neuronal formé de la naissance à la mort, et la formation est presque transparente.

Ainsi, nous ne percevons que des images. Pour le cerveau, il n'y a pas de textes, de sons et d'autres choses - nous ne percevons tout cela qu'après décomposition. En gros, nous séparons les images «pixel par pixel», les ajoutons à la mémoire, puis à l'aide de la pensée associative, nous reconnaissons divers objets. Grâce à cela, nous pouvons comprendre si nous devons fuir le serpent ou monter un vélo et appuyer sur ses pédales. Voici un schéma d'un perceptron standard, qui illustre comment la classification des objets se produit. Pour ceux qui ne connaissent pas le principe du perceptron , il peut sembler un peu chaotique. Mais grâce à un tel schéma d'équilibrage et de pesée, le réseau neuronal reconnaît les images rapidement et efficacement.



De la programmation, vous pouvez rappeler le principe DuckType, quand on pense que si un objet nage comme un canard, vole comme un canard et quacks comme un canard, c'est un canard. Une approximation particulière de la détection d'objets. Et pour notre cerveau, la reconnaissance d'objet se produit instantanément. La formation est un processus beaucoup plus long. Par conséquent, vous pouvez imaginer ce processus ainsi que la formation d'un jeune enfant qui n'apprend que des mots. Vous prenez une pomme, pointez et dites: "Ceci est une pomme." Prenez-en une autre et répétez encore: "Ceci est une pomme."



Et ainsi de suite jusqu'à ce que le résultat soit fixe. Vert, jaune, rouge, sphérique, allongé, avec et sans boutures, noir et blanc. Année après année, l'enfant construit sa base sur la base de connaissances empiriques. Je pense que le principe est clair. Nous faisons la même chose lors de la formation d'un réseau neuronal. D'objet en objet ou, plus précisément, d'image en image.

Comment un programmeur lit le code

La même chose se produit lorsque nous travaillons avec du code. Nous ouvrons la page, l'étudions, la décomposons en blocs, identifions différentes parties - nous séparons facilement les propriétés des fonctions, les niveaux d'isolement des méthodes et des propriétés, trouvons des constantes, etc. Nous identifions tout cela par blocs, et par conséquent, un aspect important du style de code est de mettre le code entier sous la même forme. Il s'agit d'un facteur clé qui caractérise la lisibilité du code.

Pourquoi est-ce important? Parce que la plupart de son temps, un programmeur lit du code. Aucune corrélation directe n'a été trouvée, pour la plupart cela dépend des qualifications, du langage (par exemple, Python est en retrait, et un code mal structuré ne fonctionnera tout simplement pas), de la qualité du code, etc. Mais à partir de 50% du temps, il faut lire votre propre code et celui de quelqu'un d'autre. Si le code est complexe, l'indicateur peut atteindre 75%, et si le code est vraiment mauvais, alors 95% du temps peut être consacré à la lecture et à essayer de savoir où ajouter une ligne afin de corriger une sorte de faille. Et maintenant la question. Que ferez-vous si vous voyez que votre code passe 75% de son temps à lire un disque ou à allouer de la mémoire à des listes doublement liées? Le programmeur tentera d'optimiser ce processus, de changer l'algorithme, d'appliquer une structure de stockage plus efficace, etc. En conséquence, lorsque le temps passé est devenu critique, j'ai commencé à inspecter ce processus. Et on pourrait dire, eh bien, c'est le cerveau, il est beaucoup plus puissant que n'importe quel ordinateur et peut stocker environ un pétaoctet de données. Mais, dans le processus de développement de mon cadre mental pour travailler avec du code (un processus caché de formation d'habitudes de lecture de code), je suis tombé sur des études dans lesquelles des capteurs surveillaient les mouvements oculaires de programmeurs débutants et expérimentés. Cela ressemble à ceci:
Débutant



Expérimenté



Faites attention à ce que fait un programmeur expérimenté. Il sélectionne des blocs de code, les décompose et les lit en blocs, en mettant en évidence les éléments clés et en analysant leur travail. Le débutant se précipite ligne par ligne, essayant simplement de comprendre ce qui se passe ici. La majeure partie du temps est consacrée à l'élaboration de la situation dans son ensemble et la lecture du code a lieu avec une contre-inspection constante.

La vidéo est assez ancienne, de 2012, et l'enregistrement visait à étudier les processus du cerveau d'un programmeur. Vous pouvez en lire un peu plus ici et ici .

Il est maintenant temps de revenir à la description du fonctionnement des perceptrons. Il s'agit d'une démonstration claire du travail d'un réseau neuronal formé et non formé. Sur la base de sa base de connaissances, un programmeur expérimenté suit le code comme un interprète, souvent sans même s'en rendre compte. On peut aborder la solution de ce problème de la même manière que l'on aborde les problèmes de formation des réseaux de neurones.

Il y a 2 façons d'accélérer la lecture du code:

1. Construisez constamment une base de connaissances de développeur sur l'apparence du code. Cela signifie un apprentissage tout au long de la vie, qui augmente constamment la puissance du réseau.
2. Apportez tout le code à une norme, définissez le même style de code

Bien sûr, il est tout à fait évident que la première méthode est très laborieuse. Dans ce cas, le programmeur doit lire en permanence les référentiels. Et compte tenu du roulement du personnel, de l'émergence de nouvelles technologies et pratiques, cela devient presque impossible. La méthode d'exclusion reste la stylisation du code, ce qui réduira l'effet de la décomposition et ne laissera que l'affect sur la logique métier.

Nombre d'accordeurs de piano

Imaginez qu'une équipe de 5 personnes écrit, comme elle le souhaite, sur tous les modules et composants du système, recevant constamment des tâches qui se chevauchent, ajustant le code de l'autre. Quel est le nombre possible de toutes les options pour écrire une condition si, étant donné que chaque personne écrit à sa manière? 5. Et combien de blocs valides avons-nous? Toutes les constructions, appels de fonctions à argument unique et à arguments multiples, espaces de noms, classes, traits, interfaces, positionnement des blocs, statique, zones de visibilité, etc. Il est prévu que tout le monde utilise un seul style d'écriture, ce qui est différent des styles de tout le monde. Et si une personne a 10 ans? Et 50? Il est clair qu'avec une augmentation du nombre de personnes, la variance diminuera en raison d'un nombre limité de façons d'écrire le même bloc. Et c'est le premier niveau dans lequel nous n'investissons pas l'un des principaux problèmes de programmation - la dénomination des variables. L'effet du multiplicateur et toutes les combinaisons possibles ne sont même pas pris en compte. Ajoutez le style de séparation, le retrait sur les espaces et les onglets, l'amour pour les nouilles, etc. etc. Et de nouveaux spécialistes arrivent constamment et d'anciens partent. En conséquence, vous obtenez un énorme code illisible auquel il est impossible de s'habituer et impossible de développer un réseau neuronal bien formé de la part des programmeurs de l'entreprise.

Notre cerveau est paresseux

Un autre effet intéressant de notre processeur central dans le crâne est la perception extrêmement négative des nouvelles informations. Notre cerveau est très paresseux. Avec une masse d'environ 1,5 à 2% du poids corporel total, le cerveau consomme 25% de toute l'énergie corporelle. L'une des interventions chirurgicales du cerveau les plus gourmandes en ressources a été, est et demeure une concentration d'attention. Vous pouvez garder la concentration maximale pendant 20-25 minutes (salut technique Pomodoro), et pendant ce temps, le cerveau engloutira autant de glucose qu'il engloutirait pendant une journée entière de repos subjectif. Le traitement de nouvelles données est un processus extrêmement gourmand en ressources. Et l'un des principaux objectifs du cerveau est d'économiser ces mêmes ressources. Cela est dû au travail de notre modèle mental. Une sorte de bloqueur psychologique. Cela ressemble à ceci. Vous commencez à apprendre quelque chose de nouveau. Quelque chose de nouveau est difficile à donner et en raison du manque de dynamique tangible de progrès, votre estime de soi commence à décliner en raison de la pensée «Je suis stupide!» Flottant autour du fond. Notre psychisme est organisé de telle manière que toute l'attitude dépend de l'estime de soi, et de notre attitude, à son tour, dépend de notre succès dans la société. Et afin de ne pas briser les ascenseurs sociaux de base sur les dépendances adaptatives, notre cerveau commence à résister aux activités qui réduisent l'estime de soi. En conséquence, vous voulez regarder une série télévisée, lire un livre, aller prendre un café, vous asseoir dans un social. réseaux, etc. N'importe quoi, juste pour ne pas apprendre la théorie même du domaine Landau. Ou corrigez un bogue difficile à reproduire. Ou ... lire du code de mauvaise qualité difficile à comprendre. Un bon exemple de la façon dont le cerveau se comporte conformément aux restrictions dans ce domaine est celui des personnes d'environ 70 à 80 ans qui ne veulent pas apprendre un smartphone ou 2 boutons sur un robot aspirateur. Les ressources s'épuisent. Le cerveau bloque désespérément le processus d'apprentissage et agit sur le pouce. Il y a beaucoup de ces ressources lorsque vous êtes jeune. Avec le temps et en grandissant, ils deviennent de moins en moins. Cela fonctionne de façon assez linéaire. Heureusement, cela est compensé par la puissance croissante de nos réseaux de neurones. Sauf si nous parlons de dégradation ciblée directe, bien sûr.

Quelques stéréotypes

Une idée fausse courante que vous avez peut-être entendue: «Eh bien, je suis un pro, je peux lire n'importe quel code. J'écris rapidement et cool, en résolvant les problèmes de l'entreprise. Et peu importe à quoi ressemble mon code s'il résout le problème. Le reste ne peut tout simplement pas le comprendre rapidement, je n'ai aucun problème avec cela. " Si vous avez un tel encodeur dans votre environnement, vous pouvez lui dire: «Mec, j'ai de mauvaises nouvelles pour toi. Vous affectez toute l'équipe, et cette approche est la raison pour laquelle les autres écrivent plus lentement lorsqu'un programmeur super efficace force rapidement le code. "

Un programmeur super efficace qui écrit sans mise en forme ni standardisation est en fait super efficace en 2 choses:

• Clôture ultra efficace des tâches sans entrer dans la conception et le style.
• Il est super efficace de ralentir tout le monde, car après ses ajouts, les gens essaient depuis longtemps de comprendre ce qui s'est passé ici.

Pourquoi le style de code est nécessaire

Bien que cela doive déjà être évident, il faut en quelque sorte souligner les points principaux.
Style de code:

1. Fournit un développement linéaire du projet et n'affecte pas la quantité de base de code. Si vous avez fourni une écriture historique de code compréhensible, peu importe le nombre de développeurs qui vont et viennent, vous avez toujours une qualité de code égale, ce qui permet au projet de se développer dynamiquement quelle que soit sa taille.

2. Accélère considérablement le processus d'adaptation des nouveaux programmeurs. Si votre code est écrit clairement, un nouveau spécialiste formera rapidement son réseau neuronal pour identifier les blocs et commencer à être utile. Il existe un point d’autosuffisance pour les employés. C'est le point à partir duquel l'employé commence à n'apporter que des avantages. Et si le code est écrit clairement, les nouveaux employés n'ont pas besoin de comprendre la logique métier, ils apprendront seulement à lire votre code. Et plus il le fait rapidement, plus il cessera de poser des tonnes de questions à d'autres spécialistes, ce qui leur prendra du temps. Et le temps des spécialistes qui ont franchi le seuil de rentabilité est beaucoup plus cher pour l'équipe et l'entreprise en termes de valeur potentielle du produit apporté.

3. Supprime la dépendance aux détails. Vous n'aurez pas à trébucher constamment sur l'originalité et le design spécifique de quelqu'un d'autre.

4. Minimise l'effet du bloqueur mental lors de l'apprentissage d'un nouveau code. Votre cerveau est moins résistant car pas besoin de se plonger dans le style de quelqu'un d'autre. Les ressources mentales pour lire un code clair ont besoin de beaucoup moins.

5. Minimise les pertes de réputation. Très bientôt, après son arrivée dans une nouvelle entreprise, le programmeur commencera à partager ses impressions avec d'anciens collègues et amis. Et il dira que tout va bien ici, ou il mettra en évidence les aspects négatifs du travail avec le code. Dans un sens, cela vous donne un bonus RH: si vous voulez que des programmeurs sympas travaillent avec vous, faites un bon projet. Bien que cela ne soit pas toujours important, et dans certaines entreprises, ils ne regardent pas la qualité du code en principe, mais ne regardent que la livraison de fonctionnalités aux ventes, c'est un bon bonus. Ce n'est un secret pour personne qu'une raison fréquente de départ est la fatigue due à la découpe constante d'une base de code de mauvaise qualité.

6. Forme et favorise une culture de développement. La tâche du programmeur est à un niveau inférieur à l’avenir de l’ensemble de l’entreprise, mais il est important de faire comprendre que la compréhensibilité et la lisibilité du code affectent désormais la dynamique du développement futur. Si le code est difficile à lire et non standardisé, peut être refactorisé et mis à l'échelle avec douleur et souffrance, alors avec la croissance de la base de code du projet, la vitesse de développement diminuera. Plus le code est de mauvaise qualité, plus il est difficile d'en écrire un nouveau, plus un produit se développe lentement, plus il est difficile pour une entreprise de croître et plus il est difficile pour vous de payer plus d'argent, car beaucoup d'argent est dépensé pour fournir le cycle de vie du projet avec de nouveaux et nouveaux employés, qui est le principal ils passent du temps à intégrer non pas les avantages pour l'entreprise, mais la classification des médicaments sous lesquels ce code a été rédigé.

Code parfait

Nous comprenons tous que cela n'existe pas. Du point de vue du style de code canonique est le concept de conception de code. Et tout irait bien si c'était vrai. Dans le développement du style de code à longue distance concept plus vaste, qui comprend les principes de développement. La division du code en blocs logiquement isolés dans les classes ou les fichiers fait également référence à la conception. Dénomination, niveaux d'isolement, héritage. Tous ces outils ne sont pas seulement des interactions, mais aussi la conception de votre mécanisme complexe, où chaque brique joue un rôle.

Les concepts changent d'une langue à l'autre. Les détails viennent au premier plan. Mais le fondement reste inchangé. Un code qualité est déterminé par seulement deux critères:

• Le code est anonyme
• Le code se lit comme un livre

Code anonyme

L'état idéal que vous devez trouver dans ce processus est appelé code anonyme. Je suis sûr que beaucoup d'entre vous, après avoir ouvert un projet de travail et un élément aléatoire, peuvent dire sans accroc lequel des collègues a écrit cela. Tout le monde a souvent un style. Quelqu'un aime les nouilles de si, quelqu'un avec et sans éclater des lambdas, quelqu'un aime réduire les variables afin de sauvegarder un caractère. En code anonyme, vous ne pouvez pas faire cela. Dans un code dépersonnalisé idéal, il est impossible d'identifier l'auteur. Et c'est le cas lorsque vous êtes arrivé au point final de votre codestyle.

Lisibilité au niveau du livre

Rappelez-vous 2 principaux problèmes de programmation? Invalidation du cache et dénomination des variables. Nous contournerons le passé sombre des processus de cache et irons directement à notre peine. Nommer des variables, des classes, des objets, des fichiers, des méthodes, des constantes, etc. Ce problème a 2 extrêmes. Noms trop courts et trop longs. Le bon sens nous dit que la logique est quelque part près, près du milieu. Ici, des programmeurs super efficaces frappent à notre porte et nous disent qu'ils s'en moquent. Mais pourquoi devrions-nous théoriser à ce sujet? Dites-moi ce que fait ce code?



Et celui-là?



Le deuxième code est lu directement et facilement. Pas besoin de vraiment comprendre la logique métier pour comprendre la charge fonctionnelle avec une telle dénomination. Dans cet exemple, nous prenons simplement le référentiel entier, puis utilisons le générateur pour créer la collection, puis appliquons le filtre. Vous n'avez même pas besoin de vous plonger dans le code pour comprendre ce qui se passe. Comme lire un livre sur les gros titres. Mais nommer n'est pas tout.

Modèles de conception

Vous êtes interrogé sur les modèles de conception dans presque chaque entretien. Leur objectif public est une solution architecturale reproductible. Leur effet secondaire est la prévisibilité et la cohérence. Au moment où vous passez à une architecture basée sur des modèles de conception, vous formez un système assez prévisible. C'est-à-dire basé sur le nom, vous comprenez facilement le but de la classe ou de l'objet. Que fait le modèle de référentiel? Il s'agit d'une vue de référentiel avec des méthodes d'acquisition de données. Que fait le modèle de générateur? Assemble un objet ou une structure complexe. Et ainsi de suite sur tous les fronts.

Il existe un modèle tel que Command. Que peut-on en faire? Bien sûr, n'exécutez que! Vous n'avez pas besoin d'étudier ce qu'il contient. Il est clair que cela peut être fait. Les modèles de conception vous aident à comprendre le fonctionnement de votre projet. Si vous avez tout bien écrit, vous ne vous demanderez pas: "Que contient mes répertoires?" Par les noms, vous pouvez facilement déterminer quoi et où se trouve.

Disons simplement cela. Toutes les décisions sur les modèles de conception ont été formées, portant à la base la douleur du développeur sur un problème particulier. Cette douleur a déjà été ressentie par quelqu'un, cadrée et a trouvé sa solution sous la forme d'un des modèles architecturaux existants. De plus, tout cela s'est formé sur le fameux SOLID.

SOLIDE

SOLID est un acronyme des cinq principes de la programmation orientée objet. Remarque: 5 principes. Orienté objet. Programmation Ce n'est pas une pratique. Ce n'est pas une recommandation. Ce n'est pas le désir d'un vieux programmeur d'enseigner aux jeunes. , SOLID — . SOLID, 6 , , SOLID — . , , . — . , , : , , . . , .

? ? . , . code style, , SOLID. . . . — -. C'est-à-dire , , , , , , . , .

, code style community . , , , , . , . , . , . , .

code style? ! . , . , . . - open-source based . , PSR , - . symfony2 code style, PSR . , , PHP. , , .

?

, , ? — , , CodeStyle , . , PHPStorm , phpcs codestyle — . , . , , , .

, (), . , ? . . , . 2 Google Sheets . 23% . , 7 , , 20 . . , 20 . 21% . , , .

, , , , 90% , . ? Middle PHP Developer . onboarding , 3-. … - . . onboarding -, , . , 1- Junior PHP Developer. « » . success story.

, , , 25%, onboarding' ⅔. « » , . , . , , , phpstorm Sonar Light.

— , Senior , , . , , . Senior QA Engineer .

, 21-27%. , , - . , 5%, 5 ( , ), 5 69 . , 14 840 – 40 /. phpcs phpstorm? , 50 .

PS: , , ManyChat, .