Pour les expérimentés, nos conseils peuvent paraître évidents. Mais pour les débutants, nous recommandons fortement la lecture. Prenez le temps de traduire ces idées dans vos projets afin de ne pas dépenser encore plus en refactoring sans fin plus tard.
Des idées similaires peuvent être exprimées dans presque tous les domaines de développement, mais nous en parlerons en utilisant l'exemple des projets dans React.
En partant de zéro, vous réfléchissez à la meilleure façon de tout organiser pour que plus tard, ce ne soit pas atrocement douloureux en raison des retouches sans fin. Dans les projets personnels pour animaux de compagnie, vous pouvez clôturer tout ce que vous voulez - puis vivre avec vous-même. Mais dans le travail d'équipe, vous devez agir de manière à permettre aux collègues de mieux comprendre l'essence et de plonger dans les détails. Ceux. Ne réinventez pas les approches de développement - il vaut mieux s'en tenir à des pratiques bien établies et reconnues par l'industrie.
Pensez à taper
Indépendamment des libertés des langages de développement, le typage statique est très utile sur les grands projets à long terme. Si, pour une raison quelconque, il est impossible d'utiliser le typage statique sur un tel projet, alors même JSDoc aidera considérablement à maintenir la qualité du code.
Mais nous n'allons pas vous conseiller fortement de toujours utiliser la saisie. Ci-dessus, ce n'est pas en vain qu'une réserve a été faite sur les grands projets, car taper c'est, avant tout, aider l'équipe. Mais l'organiser et le maintenir (le même type de changement en fonction des changements sur le backend) nécessite certaines ressources. Dans un petit projet à court terme où travaillent 1 à 2 personnes, cet investissement est inutile. Mais ils sont nécessaires lorsque l'équipe est nombreuse et va s'agrandir.
Si l'utilisation de la saisie est justifiée, nous vous recommandons de commencer les types dès le début, sinon vous devrez passer beaucoup plus de temps sur ce travail. Même si aucune API n'est prête et que vous ne connaissez pas le modèle de données, créez au moins des stubs pour que le type générique n'apparaisse nulle part.
Au fur et à mesure que le projet se développe, la dactylographie doit être respectée, même si tous les délais sont épuisés depuis longtemps. Ensuite, vous vous remercierez pour ce perfectionnisme.
Divisez le code en blocs, mettez en évidence la logique
Le code ne doit pas être regroupé. Il vaut la peine de considérer la hiérarchie dans la structure du projet - décomposer le code en modules et blocs, diviser les composants en intelligents et stupides. Il est plus pratique de maintenir et de développer une telle structure que de rechercher des particules de cette logique dans un gros tas, surtout si ces particules sont interconnectées. Peut-être que ce conseil ne s'applique pas uniquement au frontend.
Les avantages de ce principe étaient très clairement visibles sur le projet avec de grands formulaires, dont nous avons récemment parlé ( https://habr.com/ru/company/maxilect/blog/511322/ ). Dans ce projet, les vérifications de bloc et la visibilité de ces blocs étaient initialement liées. Mais lorsque nous avons rassemblé toutes les communications des champs en un seul endroit, il est devenu beaucoup plus facile de suivre les changements de logique. Et surtout, nous avons pu réutiliser le code dans un nouveau projet similaire.
Il n'y a pas de norme unique pour la structure d'un projet - ici, vous devez vous fier à vos connaissances. Il existe deux approches qui peuvent fonctionner pour de nombreux projets: le type de fichier d'abord et la fonctionnalité d'abord.
Pour trouver un point de départ pour trouver une structure qui vous convient, nous vous recommandons de vous référer à la documentation. Les meilleures pratiques y sont généralement décrites. Par exemple, React et Redux dans leur documentation proposent des standards pour organiser la logique et la structure des fichiers d'un projet. Avec un peu d'expérience, vous pouvez expérimenter et vous écarter des normes si cela vous permet de contourner certaines restrictions pour un projet particulier, mais dans la plupart des cas, ce n'est pas nécessaire. Et, bien sûr, n'oubliez pas les principes «de base» tels que SOLID. Bel article sur la façon d'appliquer ces principes dans React:https://habr.com/ru/company/ruvds/blog/428079/ . Bon article sur l'architecture propre: https://habr.com/ru/post/499078/ .
Sur l'organisation de la base de code dans React et les problèmes associés, il existe une bonne collection de matériaux, bien que non mise à jour depuis longtemps: https://github.com/markerikson/react-redux-links/blob/master/project-structure.md .
Formuler une convention de codage
L'architecte qui planifie initialement le projet en fonction du chemin le long duquel l'application va se développer a certains modèles en tête. Il vaut la peine de les exprimer explicitement sous la forme d'un passeport de projet, en le complétant avec les règles d'écriture du code, par exemple, ce qui peut et ne peut pas être inclus dans un module séparé (en général, c'est une question plutôt philosophique). Un tel «passeport» aidera les développeurs à déterminer à l'avance comment écrire, afin de ne pas réécrire plus tard. Cela peut réduire le temps d'examen et aider à standardiser les approches de codage, ce qui est particulièrement utile lorsqu'un projet est en cours de traitement par des travailleurs distants ou des équipes réparties.
Restez fidèle au paradigme choisi
Si au début vous avez décidé d'adhérer à une approche, par exemple, la conception de sites Web atomiques, vous ne devriez pas l'abandonner dès que les délais commencent à expirer. Le soutien initié et abandonné d'un paradigme est parfois presque pire que son absence totale. Si vous «laissez libre cours au chaos» un peu, il sera extrêmement difficile de rétablir l'ordre - vous devrez passer du temps à revenir au paradigme. Et vous ne pourrez pas rapidement «sauter» à un autre, car un désordre informe se formera déjà dans le projet.
Le rejet du paradigme pour des raisons de timing ou d'autres facteurs, c'est comme changer de cheval à un croisement. C'est douloureux et déconseillé. Mais s'il n'y a pas d'issue, vous devez couvrir la plupart de votre application avec des tests. Et ici, nous passons au conseil suivant ...
Se souvenir des tests
Les tests sur un projet ne doivent pas seulement l'être. Ils doivent travailler. Et il est nécessaire de les inclure dans le projet dès la première étape - dès le début du développement. Sinon, à un certain moment, vous pouvez modifier quelque chose dans l'application, puis sortir des dates de sortie, en restaurant les performances de différentes parties du projet, qui ne sont couvertes que par des tests manuels.
Laissez les tests être petits au début et ne vérifiez rien du tout. Mais il vaut bien mieux les développer au fur et à mesure que les fonctionnalités se développent, que de passer une semaine plus tard à rembourser cette «dette technique». En termes de temps passé, la première approche est plus efficace. En passant, beaucoup en sont bien conscients, mais laissent les tests pour plus tard.
Je voudrais également mentionner l'intégration et les tests de bout en bout.
Les tests d'intégration doivent être exécutés chaque fois que vous corrigez des bogues ou ajoutez de nouvelles fonctionnalités pour vous assurer que les ajustements n'ont rien affecté. Sur nos projets, nous essayons de les lancer automatiquement lorsque nous téléchargeons les résultats de notre travail (nous l'avons implémenté via un hook). Les tests n'ont pas fonctionné - vous ne devez pas télécharger les modifications dans le projet. Vous devez d'abord tout réparer.
Mais les tests d'intégration ne concernent que le frontend. Les tests de bout en bout sont plus lents et testent l'interaction de l'application avec tous les éléments dépendants. Ces tests simulent les actions des utilisateurs. Ici, nous ne nous moquons de rien, mais attendons vraiment les réponses du backend et vérifions les interactions au sein de tout l'écosystème du projet en utilisant Cypress (nous pouvons également recommander Puppeteer comme analogue).
Réfléchissez avant de mettre à niveau, mais n'abandonnez pas
Dans le monde frontal, tout change très rapidement - les versions de framework se remplacent, des bibliothèques plus performantes apparaissent. Cela vaut la peine de les garder à jour, mais pas fanatiques.
Tout comme la saisie, dont nous avons parlé ci-dessus, toute mise à jour coûte des ressources (c'est-à-dire indirectement de l'argent). Mais il y a quelques éléments qui rendent impossible la désactivation complète des mises à jour.
Premièrement, même les bibliothèques les plus performantes prennent parfois fin. Dans cette situation, vous devrez opter pour des analogues plus prometteurs.
Deuxièmement, travailler avec l'ancienne pile technologique inspire rarement les développeurs. Si vous réalisez que l'équipe ne peut pas rester sur une épine dorsale poussiéreuse, ou si vous remarquez qu'une pile obsolète affecte de manière critique l'afflux de nouveaux développeurs, vous devrez mettre à jour.
Les rafraîchissements doivent être pris dans le cadre de l'ordre naturel des choses. Mais avant de changer une bibliothèque ou de mettre à jour un framework, vous devez toujours faire des recherches.
La nouvelle version vous convient-elle? Comment organiser la transition en général? Et bien sûr, vous devez tout planifier à l'avance.
Les mises à jour sont extrêmement difficiles s'il n'y a pas de tests sur le projet. Même une petite bibliothèque de dates peut couvrir de nombreuses parties différentes d'un projet, et sa mise à jour conduit à des tests de régression complets. Avec la croissance du projet, il ne sera pas possible de le faire efficacement, n'ayant que des tests manuels dans l'arsenal.
Tu vas bien maintenant?
La mesure de l'efficacité avec laquelle vous développez votre projet peut être le rapport entre le temps passé à développer de nouvelles fonctionnalités et le temps passé sur les bogues. Selon l'approche, cet indicateur peut être plus ou moins, nous ne nous engageons donc pas à fixer des niveaux «cibles». Vous pouvez comparer vous-même la situation avant et après toute transformation.
En plus des caractéristiques non numériques, telles que «la satisfaction du développeur du projet», il existe un indicateur tel que le moment où une nouvelle personne rejoint le projet. C'est une caractéristique de la façon dont un projet est clairement décrit par la documentation, les tests et la convention de codage.
Et rappelez-vous, il vaut mieux laisser derrière vous un meilleur code qu'il ne l'était avant vous. Ne générez pas de dette technique, sinon cela gênera le développement du projet plus tard.
Peut-être avez-vous vos propres conseils? Laissez dans les commentaires!
PS Nous publions nos articles sur plusieurs sites sur le Runet. Abonnez-vous à nos pages sur la chaîne VK , FB , Instagram ou Telegram pour connaître toutes nos publications et autres actualités de Maxilect.
PPS L'image de titre du concours Playhouse récemment tenu.