Je programme depuis douze ans et j'ai travaillé avec de nombreux langages. Ceux-ci incluent , , , , et enfin . Chaque langage ou framework a ses propres règles. Par exemple, utilise pour les noms de fonction. C C++ Java Python C# JavaScript Rust la casse serpent Cependant, il existe certaines règles, outils et modèles que j'ai appris à apprécier. Je les intègre dans mes applications frontend. Ces règles résonnent davantage en moi et rendent le codage plus fluide. En voici quelques-unes que je privilégie particulièrement : Programmation fonctionnelle Mon premier conseil vient du C, le premier langage que j'ai appris. Tu te souviens quand on écrivait ? Rien que d'y penser, ça me donne des frissons. Lorsque React est passé aux composants fonctionnels, cela a rendu le code non seulement plus facile à lire, mais également plus facile à tester. React with classes Il s'aligne également mieux sur les principes de la programmation fonctionnelle. Cette approche fonctionne très bien avec les frameworks frontend car ils se concentrent souvent sur la création de morceaux de code réutilisables. L'utilisation de la programmation fonctionnelle dans le développement frontend a toujours été une stratégie utile pour moi pour comprendre ce concept et aussi pour créer de nouvelles fonctionnalités frontend. Suivre les principes de la programmation fonctionnelle est indispensable dans chacune de mes applications frontales. Si vous n'êtes pas familier avec la programmation fonctionnelle, je vous recommande fortement de l'explorer . Ce point n'est pas au début de cette liste sans raison. Les avantages qu'il peut apporter à votre processus de développement sont considérables. davantage Formateurs de code Quand j'ai commencé à programmer, je n'ai pas prêté beaucoup d'attention au formatage du code. Je suppose que tout a commencé à l'université où j'apprenais le C++ sur mon super avec un thème blanc. IDE CodeBlocks En regardant , je peux voir que je n'ai utilisé que des espaces pour le formatage. Je n'ai utilisé aucun outil pour m'en occuper automatiquement. mon ancien code de 2016 sur GitHub Maintenant, je me rends compte que c'était une erreur. Si vous pouvez automatiser quelque chose dans votre projet, vous devriez certainement le faire. Maintenant, je configure toujours et au début de chaque projet. Si vous ne voulez pas passer beaucoup de temps là-dessus, vous pouvez utiliser des configurations préfabriquées comme celle d' . Prettier ESLint Airbnb Croyez-moi, vous ne le regretterez pas ! Oh et n'oubliez pas de mettre en place dans votre IDE une action de formatage automatique sur l'enregistrement de fichier ! Actions pré-commit Maintenant que vous avez des formateurs géniaux, automatisons-les ! Je ne me souviens pas très bien quand j'ai commencé à utiliser les hooks de pré-commit, mais ils m'ont été d'une grande aide dans mes projets. Pourquoi formater manuellement alors qu'il peut être automatisé avant chaque commit ? Des outils comme et rendent cette automatisation possible. husky lint-stage Kebab-cas pour les noms de fichiers Même si a de nombreux fans et critiques, j'aime me concentrer sur le positif. Angular est souvent le premier choix pour les grandes entreprises et les grandes applications. Je pense que bon nombre des décisions prises dans Angular visaient à faciliter la maintenance. Angular C'est pourquoi j'ai décidé d'utiliser kebab-case pour tous mes projets frontaux. Il offre quelques avantages, comme : : Je n'ai pas à me soucier d'utiliser pascal-case, camel-case ou snake-case (si vous préférez). Avec le kebab-case, il n'y a qu'une seule option. Simplicité : si vous travaillez en équipe, l'adoption d'une convention de nommage unique comme kebab-case peut aider à garantir que tout le monde est sur la même longueur d'onde et que le projet reste organisé. N'oubliez pas que vous pouvez forcer l'utilisation de kebab-case via la règle eslint en utilisant le package : Cohérence unicorn 'unicorn/filename-case': [ 'error', { case: 'kebabCase', }, ], : différents systèmes d'exploitation traitent les noms de fichiers différemment. Par exemple, Windows ne se soucie pas des majuscules, contrairement à Linux. En utilisant kebab-case, qui utilise des lettres minuscules et des traits d'union, j'évite tout problème. Compatibilité multiplateforme : il y a un problème avec le renommage d'un fichier de minuscules en majuscules dans git. En utilisant kebab-case, je n'ai pas à m'en soucier. Pas de problèmes de git J'aime garder les choses simples. Si je peux me faciliter la vie et en tirer des avantages, je suis tout à fait d'accord. Utilisation de balises pour les types de fichiers Une autre chose que j'ai empruntée à Angular est la façon dont ils nomment les fichiers. Angular recommande de nommer les fichiers d'une manière qui reflète leur fonction et leur type. Je trouve que cela me facilite la navigation et la compréhension de la structure d'un projet. Dans Angular, le nom de fichier comporte généralement trois parties : la zone de fonctionnalité, le rôle du fichier et le type de fichier. Par exemple, indique que le fichier est un composant de la fonctionnalité et qu'il s'agit d'un fichier TypeScript. est un service pour . heroes.component.ts heroes heroes.service.ts heroes Je ne suis pas un grand fan des , mais j'utilise une structure similaire pour mes composants React. Voici un exemple : services my-component ├── my-component.component.tsx ├── my-component.type.ts ├── my-component.style.css ├── my-component.spec.tsx └── my-component.story.mdx J'utilise également ce modèle pour mes crochets et mes fonctions. Ce patron m'apprend aussi à mettre mes tests à côté des fichiers qui s'y rapportent. Automatiser la génération de code Le modèle que j'ai mentionné précédemment est très utile, mais nous pouvons l'améliorer encore avec l'automatisation. automatiquement, et j'utilise toujours pour faire de même. Le système de modèles de Plop est très puissant, mais surtout, il permet de gagner du temps. Angular CLI permet aux utilisateurs de générer du code plop Avec l'automatisation, je n'ai pas besoin de passer beaucoup de temps à réfléchir à la structure de base d'un composant. Cette tâche peut être automatisée, ce qui me permet de me concentrer sur ce que je veux vraiment faire. Utiliser un 'Domaine' Je ne vais pas expliquer en détail ce qu'est un ici. Si vous souhaitez en savoir plus, je vous conseille de lire . En ce moment, je travaille avec une équipe de développeurs full-stack, et nous avons constaté qu'avoir une couche dans notre projet frontend est vraiment utile. domain cet article de domaine C'est là que nous plaçons tous nos principaux types et opérations. Il sert de "source de vérité" dans notre application. Si vous voulez voir comment je gère les "domaines" dans mes applications, vous pouvez consulter . J'y passe beaucoup de temps à décrire ce sujet. cet article Tester votre architecture Dans notre travail avec , nous avons déjà rencontré un problème où la logique se mélangeait sur plusieurs couches, comme l'utilisation d'un type défini dans le référentiel à l'intérieur de notre domaine. C'est interdit du point de vue de l'architecture propre, mais tout le monde fait des erreurs. Kotlin C'est alors que nous avons découvert , un outil de test unitaire de notre architecture. Il vérifie essentiellement si nous adhérons correctement à notre architecture. ArchUnit Si vous maintenez une certaine architecture, il peut être utile d'avoir un outil pour vérifier si elle n'a pas été cassée à un moment donné. Un outil comme peut être inestimable à cet égard. dependency-cruiser Et cela conclut ma liste essentielle de modèles d'autres langages et frameworks pour améliorer vos projets frontaux. J'espère que vous avez trouvé ces informations utiles et qu'au moins une de ces stratégies vous a inspiré à la mettre en œuvre dans votre propre travail !
