🧡 🤸🏻 😏 Développement frontend dans l'entreprise: qu'est-ce que c'est et comment le rendre efficace 🤛 🤷🏿 🔤

Chez KORUS Consulting CIS, nous organisons depuis plus de dix ans le développement de services Web pour nos clients. Nous avons déjà plusieurs dizaines de projets sérieux dans le secteur bancaire, dont certains ont reçu une reconnaissance internationale.

Au cours des deux dernières années, le nombre d'équipes et de projets dans notre entreprise a augmenté à plusieurs reprises, tandis que l'efficacité du développement frontend a également augmenté à plusieurs reprises. Nous avons appris à créer des applications en quelques semaines au lieu de quelques mois.

Nous travaillons constamment au développement de l'infrastructure de notre développement front-end, et aujourd'hui je partagerai quelques développements sur l'organisation de l'unité front-end, qui peuvent être utiles à ceux qui organisent le front-end dans leur entreprise.

Dans cet article, vous découvrirez notre chemin pour répondre aux questions suivantes:

, ;
, ;
;
;
;
.

La partie frontend d'un site ou d'une application est ce que vous voyez dans votre navigateur, cette partie interagit activement avec la partie serveur (backend), qui est située sur n'importe quel serveur, échangeant constamment des données avec lui.

D'un point de vue technique, le front-end de l'application est un ensemble de fichiers, parmi lesquels il y a des fichiers HTML, CSS et JavaScript, des images, etc. Le travail avec CSS et HTML est lié à la composition, JavaScript - à la programmation. Ces deux domaines offrent un grand nombre d'outils et de technologies pour le travail, se développent activement et nécessitent beaucoup de connaissances. Cela est particulièrement vrai pour JavaScript, qui a écrit un grand nombre de frameworks et de bibliothèques pour la création "de plus en plus efficace" d'applications Web.

Quelque part, on m'a demandé de quoi ai-je besoin pour faire des demandes afin qu'elles ne deviennent pas obsolètes pendant plusieurs années?

En tant que programmeur, je peux donner une réponse complètement précise et complètement inutile: HTML, CSS et JavaScript. Que choisir exactement, jQuery, Angular ou React - ce sont les détails.

Si vous approfondissez ces détails, vous pouvez donner une autre réponse tout aussi correcte et inutile: sur n'importe quoi. Oui c'est vrai. L'application peut être écrite sur n'importe quoi, elle fonctionnera, elle pourra être modifiée et développée.

Quelle est la différence?

Pour trouver la réponse, examinons ce que l'entreprise souhaite de l'avant. Je pense que je ne surprendrai personne si je dis que l'entreprise veut obtenir rapidement et à peu de frais un résultat de haute qualité.

Alors, de quoi avez-vous besoin pour faire des applications maintenant, afin que le développement se déroule rapidement, efficacement et ne ruine pas le client?

Vitesse de développement

Un programmeur possédant une vaste expérience avec React sera en mesure d'écrire rapidement une application dans React, ayant une expérience avec Angular donne la vitesse de travail avec Angular, et ainsi de suite. Tout est assez évident. Les frameworks eux-mêmes font gagner du temps de développement en fournissant des solutions aux problèmes et tâches courants. En substance, ces solutions peuvent être très proches les unes des autres, et la différence entre elles peut être dans la syntaxe ou le paradigme de programmation.

La vitesse de développement en utilisant un cadre particulier dépend de l'expérience et des qualifications des programmeurs qui y écrivent, le cadre lui-même est d'une importance secondaire.

La qualité des produits

C'est la même chose ici: c'est bon et mauvais, vous pouvez écrire sur n'importe quel framework. Vous pouvez créer une architecture correcte ou incorrecte n'importe où.

Tout dépend de l'expérience et des connaissances du développeur.

Coût

Tous les principaux frameworks modernes sont gratuits, donc si vous omettez les détails, le coût de développement est le temps que les développeurs ont passé à étudier les exigences, les technologies, à élaborer l'architecture et à écrire du code. Plus le coût de trouver / former ces développeurs.

D'où la conclusion: il faut moins compter sur la technologie que sur les développeurs et l'organisation de leur travail.

Presque n'importe quel framework populaire moderne est assez bon pour créer sur lui presque n'importe quelle application dont les entreprises modernes peuvent avoir besoin.

Par conséquent, il sera question de l'efficacité du front-end en termes d'organisation du développement.

Comment c'était avec nous

En 2017, nous avions des applications sur presque tout ce qui méritait l'attention dans le monde JavaScript: de jQuery aux différentes versions d'Angular et React sur Typescript et Flow. Les mises en page et les développeurs backend / fullstack ont travaillé du côté client de nos applications. Chaque développeur a choisi des outils pour ses tâches, en fonction de sa connaissance des technologies frontales.

Maintenant, je ne peux que spéculer, mais il me semble que le choix des frameworks et des bibliothèques par les développeurs fullstack / backend était quelque chose comme ceci:

"Voyons ce qu'ils écrivent sur Internet ..."

Eh bien, vous comprenez.

Lors du choix d'un framework / bibliothèque, le développeur est limité dans le temps, le plus souvent il n'a pas le temps de déployer indépendamment de nouveaux frameworks pour lui et de faire des applications de test. Par conséquent, il fait en quelque sorte un choix plus ou moins raisonné et suit ensuite dans la direction choisie.

À différents moments, ce choix peut être différent même pour le même développeur (voir les illustrations ci-dessus). En même temps, il ne devient pas moins raisonné. Qu'attendre alors de différents développeurs avec des expériences différentes?

À l'insu de 2017, nous sommes devenus un véritable zoo technologique de pointe.

Frontend en tant qu'unité distincte

Un grand nombre de technologies différentes dans l'entreprise est une source de risque. Un développeur possédant les connaissances nécessaires peut être occupé sur un autre projet, il peut complètement quitter l'entreprise. L'embauche de spécialistes possédant une vaste expérience dans divers domaines n'est pas non plus une tâche facile.

Une documentation de haute qualité peut atténuer les effets négatifs d'une telle diversité, mais cela prend généralement beaucoup de temps pour étudier et vous immerger dans une technologie inconnue.

En 2017, une division front-end est apparue dans notre entreprise, qui répondait aux exigences croissantes sur la qualité de la partie front-end de nos projets et leur quantité, ainsi que pour tenter de stabiliser la diversité des technologies et augmenter l'efficacité du développement.

Ce fut une étape importante pour le développement de notre entreprise: ce que nous faisons maintenant, il serait impossible de le faire avec l'aide de développeurs sans se spécialiser en front-end.

Comment soigner le zoo?

Une variété incontrôlée de technologies rend difficile la prévision de la vitesse et de la qualité du développement en général, alors que le développement commercial l'exige.

Par conséquent, notre prochaine étape a été d'unifier la pile de l'entreprise avec l'aide d'experts de la nouvelle division.

Une pile unifiée est un ensemble strictement limité de bibliothèques et d'outils que les développeurs peuvent utiliser pour résoudre des problèmes commerciaux. Il comprend également des politiques concernant différentes approches de la programmation, par exemple, l'utilisation d'une approche principalement fonctionnelle, ou vice versa, son rejet.

Une seule pile donne au développeur la possibilité de passer rapidement d'un projet à un autre, d'effectuer un examen inter-équipes et de partager efficacement l'expérience et les meilleures pratiques avec ses collègues.

La tâche principale ici n'est pas de décider ce que nous écrivons sur React ou Angular, mais de s'assurer que les développeurs utilisent les mêmes outils pour créer des applications et les mêmes approches pour résoudre les problèmes courants.

Pour référence: notre principal outil est React, mais nous développons également une expertise en Angulaire.

C'est là que le plaisir commence. Forcer dans le monde de la programmation fonctionne très mal.

Par conséquent, au lieu de la coercition, vous devez vous assurer que les développeurs eux-mêmes souhaitent suivre certaines règles de développement.

Pour ce faire, vous avez besoin de:

en quelque sorte fixer, formaliser les exigences de développement;
Encouragez les développeurs à suivre ces directives.

Formaliser une pile est une activité qui nécessite la capacité de garder un équilibre. Il n'est pas nécessaire d'élaborer des règlements détaillés pour tout afin de transmettre les idées de base aux développeurs. De plus, la création et le maintien de spécifications détaillées consomment beaucoup de ressources.

Nous avons résolu le problème de motivation comme suit: il est préférable que toute documentation de donner au développeur une application semi-finie (modèle).

Cela permet aux développeurs de résoudre les tâches plus rapidement et d'impressionner leurs collègues par leur productivité et les encourage en même temps à respecter les règles de base déjà protégées dans le code.

D'une part, des applications similaires donnent au final une augmentation significative de la vitesse de développement en raison de l'accumulation d'expérience, de solutions prêtes à l'emploi, d'un examen plus approfondi et de la possibilité de passer d'un projet à l'autre. D'un autre côté, chaque projet a ses propres particularités, il est donc également important ici de ne pas en faire trop avec la standardisation.

Ce que vous devez mettre dans le modèle de demande

Lors du démarrage de nouveaux projets, les développeurs résolvent généralement les tâches typiques suivantes:

définition de l'architecture, sélection des technologies / outils;
création, assemblage de cadre d'application;
création et configuration de mécanismes communs: gestion des erreurs, fenêtres modales, notifications, routage, requêtes serveur;
définition d'un ensemble d'éléments d'interface;
recherche / création, personnalisation, stylisation des composants d'interface avec les fonctions nécessaires;
traitement des formulaires, validation;
disposition;
mise en place de fonctionnalités sur commande d'un client (logique métier);
examen du code;
la gestion des dossiers.

Laquelle de ces tâches vos développeurs peuvent-ils résoudre en quelques minutes?

Le modèle d'application que nous avons développé ferme les trois premiers éléments de cette liste. Dans ce modèle, nous avons exprimé non seulement nos souhaits pour une seule pile de développement, mais également les règles de base de l'architecture d'application.
Par rapport aux solutions populaires du domaine public (par exemple, create-react-app), notre modèle contient déjà:

structure de dossiers prête à l'emploi;
routeur configuré (routes);
Stockage redux configuré
module de demande de serveur;
des mécanismes prêts à l'emploi pour afficher divers types de chargeurs, de notifications et de fenêtres modales via redux;
module de traitement des erreurs (serveur et utilisateur) avec la sortie des messages à l'utilisateur;
pages de modèle;

modules de modèle de logique métier auxquels les gestionnaires d'erreur, de chargeur et de notification sont connectés.

En substance, il s'agit d'une application prête à la production avec une page qui dit bonjour au monde. En commençant par le café du matin, à l'heure du déjeuner, le développeur peut afficher la première page d'un projet de travail.

Mais alors, un grand nombre d'autres tâches intéressantes (et pas si) attendent le développeur.

Sélection de la bibliothèque de composants

Tout ce qui concerne la mise en page, les composants d'interface (listes déroulantes, calendriers, etc.), les formulaires et la validation, nous avons décidé d'utiliser notre propre bibliothèque. C'était la partie la plus difficile.

En 2017, la bibliothèque principale de l'entreprise était la bibliothèque de composants payants de Kendo, qui fournissait des solutions d'interface utilisateur pour diverses technologies, à commencer par jQuery. Pour diverses raisons, cela ne nous convenait pas et nous avons décidé d'envisager des bibliothèques alternatives, y compris la possibilité de créer les nôtres.

C'est un point très important auquel vous devez faire le bon choix: trouver une autre bibliothèque qui nous convient le mieux ou créer la vôtre. La poursuite de la répartition des ressources de développement et le temps que les équipes consacrent à la création et à la finalisation des éléments d'interface dépendent de ce choix. Dans notre choix, nous sommes partis des considérations suivantes.

;
;
.

( , , );
;
, . ;
, . .

;
;
.

;
, / ( ..);
( , , , ).

En fait, les solutions toutes faites ne sont pas aussi toutes faites. Presque toutes les bibliothèques doivent être préparées à un degré ou à un autre. Si vous devez réaliser un petit projet, vous ne rencontrerez peut-être pas un tel besoin, mais si vous réalisez une sorte de grand projet ou de nombreux petits projets différents, le coût des améliorations peut s'avérer plus élevé que le coût de création de votre propre bibliothèque, qui répond pleinement à vos besoins.

Il s'avère que vous devez choisir entre l'installation de fonctionnalités immédiatement prêtes à l'emploi avec un tas de limitations et le développement de vos propres solutions avec la nécessité d'attendre et de dépenser des ressources supplémentaires pour le développement.

Aucune des options ne nous convenait complètement et nous avons trouvé une autre solution.

Nous avons décidé de faire notre add-on pour la bibliothèque terminée.

Permettez-moi de vous rappeler qu'à cette époque, nous utilisions déjà la bibliothèque Kendo dans sa forme pure, une alternative que nous voulions trouver. C'est ce que nous avons décidé de prendre comme base de notre bibliothèque principale de composants pour les applications sur React. Et notre nouvelle bibliothèque elle-même était une façade sur Kendo. Je vais omettre les détails techniques, je dirai seulement qu'une telle solution nous a permis d'obtenir immédiatement toutes les fonctionnalités de Kendo, et nous avons fait ce qui nous manquait, y compris la correction rapide des bugs, dans la couche entre l'API cliente de la bibliothèque et Kendo.

Cette architecture nous a permis d'étendre rapidement le nombre de composants dus à d'autres bibliothèques et modules, simplement en les intégrant dans notre couche. Pour les clients de bibliothèque (pour les développeurs d'applications), cela ressemblait à une augmentation rapide des fonctionnalités d'une bibliothèque (je vais en discuter en détail dans un article séparé).

Au fil du temps, nous avons remplacé tous les composants par nos propres implémentations et publié la deuxième version de la bibliothèque, où nous avons pris en compte toutes les expériences précédentes, révisé l'API et créé notre propre documentation.

Nous avons décidé de mettre nos réalisations dans le domaine public, bientôt elles pourront être téléchargées et utilisées dans nos projets, suivez les annonces.

Qu'avons-nous finalement obtenu?

Nous avons maintenant plus de 10 développeurs front-end dans plusieurs équipes travaillant sur la même pile et avec un seul ensemble de technologies. Sur une pile, nous avons déjà créé une vingtaine de projets.

Les statistiques montrent que l'efficacité du travail a plus que triplé en deux ans. Les projets sur lesquels nous avions l'habitude de passer de 4 à 6 mois, maintenant nous le faisons en 1 à 2 mois (nous parlons de la partie front-end).

Nous avons commencé à réduire le temps de développement en modifiant la structure des tâches des programmeurs. Voyons comment ils ont changé.

J'ai déjà donné une liste de tâches que les développeurs ont résolues il y a deux ans:

définition de l'architecture, sélection des technologies / outils;
création, assemblage de cadre d'application;
création et configuration de mécanismes communs: gestion des erreurs, fenêtres modales, notifications, routage, requêtes serveur;
définition d'un ensemble d'éléments d'interface;
recherche / création, personnalisation, stylisation des composants d'interface avec les fonctions nécessaires;
traitement des formulaires, validation;
disposition;
mise en place de fonctionnalités sur commande d'un client (logique métier);
examen du code;
la gestion des dossiers.

Parmi ceux-ci, dans notre entreprise aujourd'hui, les développeurs ne sont engagés que dans les trois derniers:

mise en place de fonctionnalités sur commande d'un client (logique métier);
examen du code;
maintenir la documentation du projet.

Le reste est déjà décidé dans le modèle d'application et la bibliothèque de composants.

Cela a affecté non seulement la vitesse de travail, mais aussi en général l'humeur des développeurs. Quoi qu'il en soit, la mise en œuvre de la logique métier est beaucoup plus intéressante que la mise en place de listes déroulantes. Il est également beaucoup plus facile pour le chef de projet d'expliquer au client qu'une semaine de temps de travail a été consacrée au développement de fonctionnalités métier importantes, et non au fait que cela nécessitait l'achèvement d'un petit élément d'interface, bien qu'elles puissent être tout à fait équivalentes en termes de coûts de main-d'œuvre.

Nous continuons à travailler dans la direction choisie et l'une des tâches principales pour un avenir proche est d'augmenter la motivation des développeurs à approfondir leurs compétences dans la pile sélectionnée et à rechercher de nouvelles solutions efficaces. La mise à l'échelle de telles solutions dans l'ensemble de l'entreprise est désormais facile grâce à une bibliothèque et un modèle d'application communs.

Avec des souhaits d'efficacité et à bientôt!

Développement frontend dans l'entreprise: qu'est-ce que c'est et comment le rendre efficace