Fin 2018, le
Panda-Meetup # 9 Frontend a eu lieu à Samara. Lors de cet événement, je me suis essayé dans un nouveau rôle et j'ai fait une présentation. Je m'appelle Evgeny Kholmov. J'ai commencé à programmer il y a plus de 10 ans, en tant qu'étudiant. Depuis 5 ans, je développe des systèmes de services à distance dans de grandes banques russes, dont deux ans en tant que manager. Pendant ce temps, j'ai participé à la création de plusieurs applications d'entreprise russes de premier plan, passant par les épines de solutions architecturales, d'intégration et de processus lourdes. Sur la base de mon expérience dans le développement de plusieurs grandes banques Internet, j'ai expliqué aux invités de la mitap quels avantages ce serait de suivre les règles d'un bon style de développement. Les chiffres exprimés ont impressionné le public. Les participants à la réunion m'ont littéralement submergé de questions. Il est possible que parmi les lecteurs de Habré ce sujet trouve une réponse vivante.
Vous pouvez regarder la vidéo de ma présentation sur Youtube.
Et pour les citoyens de Khabrovsk, j'ai préparé une version texte de mon rapport.
En étudiant les problèmes de lisibilité du code, je suis tombé sur StackOverflow sur un sujet curieux. Il a discuté de l'importance du code lisible par l'entreprise et s'il est plus important que les performances et l'exactitude. En conséquence, selon les membres de la communauté, le critère le plus important était la lisibilité du code.
A cette époque, je n'étais pas intéressé par les problèmes de lisibilité du code - je développais la prochaine banque Internet. Le frontend utilisait HTML5, AngularJS, LESS. Le projet a été développé pour l'une des plus grandes banques de Russie. Je suis passé à ce projet depuis Promsvyazbank, où j'ai développé une banque Internet très similaire: le même segment de clients, le même nombre d'utilisateurs, presque la même pile technologique (HTML5, AngularJS, SCSS). Mais, malgré la forte similitude des projets, la transition a été très difficile pour moi. C'est une question de style. Le code de ces projets était remarquablement différent dans la conception et la lisibilité générale. Si à Promsvyazbank les développeurs ont strictement suivi les directives, alors dans le nouveau projet il n'y avait pas de règles de style claires.
C'est alors que j'ai pu comprendre (et même calculer) les avantages qu'un grand projet apporte à des guides de style stricts. Après avoir analysé les coûts de développement de mon nouveau projet, je suis arrivé à la même conclusion que les lecteurs StackOverflow: la lisibilité est le critère le plus important.
Bonnes règles de style
Pour AngularJS et Angular 2+, un expert bien connu dans le monde du développement frontal, John Papa, a créé des guides de style qui décrivent les règles de bon style lors du développement d'applications angulaires. En travaillant à Promsvyazbank, j'ai découvert ces guides de style. L'équipe les a clairement suivis sur tous les projets. Mais sur le nouveau projet, le code provenait d'entrepreneurs qui ne pensaient pas si sérieusement au style de programmation. Avec ma nouvelle équipe, je suis tombé sur des tâches quotidiennes que j'avais déjà résolues auparavant. Cependant, cela ne m'a donné aucun avantage, mais seulement de la douleur et de la souffrance.
Une histoire de temps perdu ou pourquoi avons-nous besoin de toutes ces règles
Le guide de style de John Papa énumère un grand nombre de règles. Les énumérer à plusieurs reprises n'a aucun sens, ils sont parfaitement présentés dans la
source d'origine . Je me limiterai à quelques exemples qui démontrent de manière colorée les avantages des recommandations d'experts.
Commençons par un simple
Etude de cas. Les utilisateurs de la banque Internet ont affiché des taux de change non pertinents. On m'a confié la tâche de charger les cours en cours au moment de l'opération. Je m'attendais à voir le code responsable du chargement des taux de change dans les services et les composants. Mais, bien sûr, il n'était pas là (sinon je n'aurais rien à écrire). Il s'est avéré que les taux de change étaient extraits et filtrés au niveau du démarrage de l'application, dans le fichier app.run, après quoi ils étaient placés dans le stockage de session. Ce n'est clairement pas la meilleure approche. De plus, de toute façon, pour résoudre le problème, le code devait être retiré de là. Il a fallu une journée entière pour accomplir une tâche simple.
Maintenant, regardez la règle Bootstrapping (Style 02-05) du guide de style.
Placez le code qui sert au lancement de l'application dans un fichier séparé et ne placez pas la logique d'application dans ce fichier. La logique doit être placée dans les services et les composants.
Million d'exemple
Comme vous pouvez le voir ci-dessus, négliger une seule règle peut causer des problèmes. Mais nous aurons des conséquences vraiment graves si nous n'écoutons pas plusieurs recommandations à la fois.
Etude de cas. Notre équipe a reçu la tâche: pour le paiement du logement et des services communaux, ajouter la possibilité d'inclure des montants d'assurance volontaire dans le paiement. Sur le front-end, cela se résumait à une tâche simple: placer une case à cocher sur le formulaire, dont l'inclusion ajouterait des frais d'assurance au montant du paiement. Chez Promsvyazbank, nous avons traité une tâche similaire très rapidement. Mais sur le nouveau projet, tout s'est mal passé.
Étant donné que le code du module de paiement a été extrêmement mal organisé, la décision a duré des mois. À la recherche de l'option la plus appropriée, nous avons reporté cette tâche plusieurs fois et l'avons reprise. Et la banque, quant à elle, a eu des difficultés de paiement en faveur du logement et des services communaux. En fin de compte, nous avons bien sûr réglé le problème. Mais je me demandais combien de mauvais code peut coûter à une organisation par l'exemple d'une tâche aussi simple. J'ai calculé le temps passé par tous les spécialistes impliqués dans la résolution du problème. Armé de statistiques sur les salaires moyens. J'ai calculé et arrondi les pertes associées. En conséquence, je suis arrivé à la conclusion que si nous avions un bon code au départ dans le module de paiement, nous économiserions au moins 5 millions de roubles.
En vérifiant le guide de style de John Papa, j'ai vu que notre module violait plusieurs règles de bon code à la fois. Ayant estimé le degré d'influence de chacune de ces règles, j'en ai identifié trois, dont la violation a surtout ralenti notre travail:
- Règle d'un - J'ai annulé 25% du temps perdu pour avoir enfreint cette règle;
- Responsabilité unique - la dérogation à ce principe a contribué à la perte globale de 35%;
- LIFT - violation de ce groupe d'approches, je pense que 40% d'entre nous sont ceux qui ont le plus ralenti.
Règle d'un
Notre banque en ligne a pris en charge de nombreux paiements, dont certains dans leur modèle étaient complètement différents les uns des autres. Néanmoins, les programmeurs ont essayé de créer un formulaire de paiement «universel» pouvant fonctionner avec toutes les options de paiement.
Sur le formulaire lui-même, de nombreux blocs différents ont été constitués, qui ont été montrés dans certaines conditions et jamais montrés dans d'autres. En même temps, ils étaient servis par une logique commune, ce qui a considérablement gonflé ViewModel'i.
En conséquence, tout cela a conduit au fait que si quelque chose était ajouté à un endroit, il tombait inévitablement à un autre. Au début, il s'est avéré que le choix de la case à cocher n'a pas changé le montant. Nous avons essayé de corriger le champ du montant. Mais il est devenu non modifiable sur tous les autres types de paiements. Nous avons essayé de remplacer le champ de montant par un nouveau. Mais la logique générale de validation est tombée: la case à cocher fonctionne, mais le bouton de paiement n'est pas disponible. Vous êtes dans une situation similaire?
Voyons maintenant ce que dit la règle de la règle d'un.
Chaque élément individuel, tel qu'un composant ou un service, doit être placé dans un fichier distinct. Vous devez vous assurer que le fichier ne se développe pas. Si le nombre de lignes de code dépasse un nombre magique de 400, c'est un signe certain que le composant mérite d'être rompu.
Responsabilité unique
Lorsque nous avons terminé avec le formulaire lui-même, il s'est avéré que les fonctions situées à l'extérieur du formulaire ont cessé de fonctionner. Par exemple, le travail avec les projets de paiement a été endommagé. Des erreurs sont apparues dans l'historique des opérations. Et cela s'est produit parce que d'autres composants que le formulaire de paiement lui-même étaient liés au modèle et au contrôleur de paiement du formulaire. Pire encore, le fait qu'une tentative de réparation de cette fonctionnalité nous ait renvoyé à un formulaire de paiement cassé.
Il s'agissait du cas classique de violation de la responsabilité unique. Ce principe est depuis longtemps inclus dans l'ensemble des programmeurs expérimentés. Et son guide de style recommande explicitement de l'utiliser lors du développement d'applications angulaires.
Appliquer le principe de responsabilité unique (PRS).
LIFT
La chose la plus gênante à laquelle j'ai dû faire face a été de naviguer dans le projet lui-même. La logique était dispersée dans plusieurs fichiers, combinés en une hiérarchie incompréhensible d'héritage et de délégation. D'après les noms de ces fichiers, leur objectif ne suit pas du tout. Les fichiers se trouvent dans différents dossiers. Dans certains dossiers, par exemple, les contrôleurs, parmi des dizaines d'autres fichiers, tout le temps j'ai dû chercher ceux qui sont nécessaires en ce moment. Le nombre d'onglets ouverts dans l'environnement de développement ne correspondait pas à l'écran de l'ordinateur et dans ma tête. Pendant le débogage, atteignant le Nième composant du compte, j'ai déjà oublié quel chemin et pourquoi je suis venu ici. De temps en temps, il était nécessaire d'effectuer une rétro-ingénierie complète avec le débogueur activé pour trouver dans quel dossier de projet le fichier avec une fonctionnalité spécifique était situé. Le sentiment de haine accumulé pour le code brouilla ses yeux et le distraya du travail.
Le guide de style sage connaît également ce problème. Pour le résoudre, un groupe de règles LIFT a été créé. LIFT signifie Locate, Identify, Flat et Try to be DRY. Selon les principes de LIFT, il est nécessaire d'organiser la structure du projet de manière à:
- il était clair où placer les nouveaux composants et où chercher les composants existants (Localiser);
- le but du composant était clair par le nom du fichier (Identify);
- il était facile de naviguer dans les dossiers, d'utiliser la structure la plus plate pour eux (plat);
- Essayez de ne pas répéter votre code, mais pas au détriment d'autres règles (essayez d'être SEC).
L'approche LIFT est complétée par deux autres règles.
Les directives structurelles générales proposent de créer un dossier pour chaque composant individuel et de regrouper tous les fichiers liés à ce composant. Par exemple, il est plus pratique lorsque le fichier payment-form.controller.js ne se trouve pas dans le dossier Contrôleurs, mais dans le dossier payment-form avec payment-form.html et payment-form.css.
La structure Dossiers par fonctionnalité recommande de créer des dossiers séparés avec les noms correspondants pour les fonctionnalités et les domaines du projet. Selon cette règle, le dossier du formulaire de paiement mentionné ci-dessus doit se trouver dans le dossier des paiements avec les autres composants requis pour travailler avec les paiements.
Par conséquent, si les auteurs du code suivaient les règles LIFT, la structure du projet ressemblerait à ceci:
D'accord, cette option pour organiser le code est beaucoup plus pratique pour le lecteur. Et il ferait gagner beaucoup de temps à toute notre équipe.
Les bons programmeurs vont au bar
J'espère que les exemples ci-dessus semblaient suffisamment convaincants pour que le lecteur, qui n'avait pas pensé au style de programmation plus tôt, ait envie de se pencher sur la directive. En général, un code bien lu et maintenu profite non seulement au budget du projet, mais aussi au programmeur lui-même. Le code lisible est plus facile à consulter. Si vous avez besoin de l'aide de vos collègues, ils comprendront rapidement le code lisible. Si vous n'êtes qu'un spécialiste novice, la lisibilité du code est la première chose à laquelle vous devez travailler. Même si vous écrivez du code super correct et parfaitement optimisé, mais absolument illisible et non pris en charge, vous serez certainement respecté dans l'équipe, mais vous ne serez pas invité à la barre après le travail.
Si ce texte vous a fait penser à quelque chose ou vous a rappelé quelque chose de douloureusement familier, je serai heureux de le voir dans les commentaires du post.