Note : Dans l’ensemble de cette page, la fonctionnalité Folders de Client-First est traduite par Dossier. Vous retrouverez donc les deux appellations afin de bien assimiler les fonctions et bénéfices vs le nom de la fonctionnalité dans le designer Webflow.
Intro
La majeure partie de cette documentation traite des stratégies que nous pouvons adopter pour utiliser et optimiser les dossiers de classe personnalisées.
Les projets sont différents.
- Les projets ont des exigences différentes.
- Les projets varient en termes de design et de mise en page
- Les projets peuvent avoir des stratégies de maintenance post-projet différentes.
Ces facteurs sont à prendre en compte dans notre stratégie de nomination des dossiers lors d'un projet.
La fonctionnalité Folders a été conçue pour apporter une certaine flexibilité dans la façon de nommer et d'organiser les classes de son projet. Gardez à l'esprit que Client-First est "Une convention de nomination des classes unique pour chaque projet". Nous le pensons quand nous le disons. Pour que cette affirmation soit vraie, nous avons besoin de flexibilité dans notre système d'organisation des dossiers.
Souvent, il n’y a pas de bon ou de mauvais choix dans la nomination des classes. Il y a seulement des nominations plus ou moins efficaces.
Il est possible de tirer le meilleur parti de Webflow lorsque notre stratégie de développement est adaptée au projet que nous développons.
Exemples ci-dessous
Nous présentons ci-dessous plusieurs stratégies de nomination des classes avec différents modèles d'organisation des dossiers.
Il est important de comprendre que nous ne devons pas utiliser toutes les stratégies dans un seul projet. Nous pouvons utiliser plusieurs stratégies, mais pas toutes.
Les conventions de nomination doivent être unifiées lorsque nous appliquons notre système de dossiers. Tout comme les fichiers de notre ordinateur, il est préférable d'avoir une certaine structure pour unifier l'organisation des fichiers.
Nous recommandons d'avoir un plan pour la convention de nomination des dossiers avant de commencer à développer.
Examinons chaque exemple et expliquons dans quelles circonstances nous pouvons l'utiliser.
Les types d’organisation de dossiers (Folders)
Un seul Dossier (Folder)
Un niveau de dossier, un nom de dossier général
Utile pour créer des composants qui ne sont pas spécifiques à une page ou un contenu.
Lorsque le nom est général, il est plus facile de comprendre que le dossier est utilisé de manière globale dans le projet.
Une nomination générale est idéale pour les éléments récurrents du projet.
one-folder_nom-de-l-element
Un niveau de dossier, un nom de dossier spécifique
Utile pour créer tout type de dossier personnalisé, quelle que soit la taille du projet.
Ajoutez le nom de la page pour donner un contexte quant à sa relation avec celle-ci.
Ajoutez des mots-clés spécifiques au contenu pour fournir plus d'informations sur l'objectif de la classe.
La nomination spécifique fonctionne bien pour les petits sites Web personnalisés qui ne nécessitent pas une organisation globale poussée.
La nomination spécifique est idéale pour les sections, les composants et les éléments créés pour une certaine page ou dans un cas précis.
one-specific-folder_nom-de-l-element
Un niveau de dossier, un nom de page comme nom de dossier
Utile pour créer un dossier de classes spécifiques pour une page spécifique.
Si nous créons une nouvelle page, et que cette page possède des composants personnalisés différents du reste du site, nous pouvons organiser ces composants dans un dossier de page unique.
Un dossier de page est une bonne stratégie lorsqu'il n'y a pas beaucoup de classes personnalisées pour la page, et que les classes personnalisées sont créées pour la page dont elles portent le nom.
page-folder_nom-de-l-element
Important : N'utilisez pas l'organisation en dossiers par nom de page si vous réutilisez cette classe sur d'autres pages. Cela conduira à un système de classes non organisé et confus. Au lieu de cela, si nous utilisons une classe sur plusieurs pages, utilisez la stratégie "Un niveau de dossier, un nom de dossier spécifique". Lorsque nous utilisons la stratégie du nom de page, nous devons utiliser la classe uniquement sur la page en question.
Un niveau de dossier, un nom de page comme préfixe de l'élément
Utile pour créer des variations uniques d'un composant par page tout en restant dans la structure du dossier du composant.
Par exemple, les mêmes styles sont appliqués à tous les sliders (carrousels) du projet. La page d'accueil présente une variation unique du style des flèches (du slider). Cette variation n'est pas suffisante pour que le composant devienne un slider spécifique ou pour créer un dossier totalement différent spécifiquement pour cette variation. Il a le même style que les autres sliders, à quelques exceptions près.
Nous souhaitons continuer de gérer tous les sliders (carrousels) dans le dossier (Folder) slider_.
Nous pouvons utiliser un préfixe de page comme premier mot clé de cet identifiant d'élément pour définir le but de la nouvelle classe dans le dossier slider_folder.
Nous identifions l'instance de la page d'accueil sans créer un nouveau dossier pour notre composant slider.
un-dossier_nom-page-element
slider_culture-pane
Pouvons-nous utiliser une classe combinée (combo class) à la place ? slider_pane is-culture
Oui, une classe combinée peut être utilisée à la place de cette stratégie. Une classe combinée peut également être une bonne décision.
Pour certaines raisons, nous ne souhaitons pas utiliser l'implémentation d'une classe combinée pour cette variante. Par exemple, nous n'avons pas besoin d'hériter des styles de slider_pane. Plus d'informations sur l'utilisation judicieuse des classes combinées (combo class) dans la Stratégie des Classes [Partie 2].
Dossier imbriqué
Utile pour les plus gros sites dont les exigences en matière d'organisation sont plus complexes.
L'utilisation de deux niveaux de dossiers, ou dossiers imbriqués, ne doit pas nécessairement être une stratégie appliquée à l'ensemble du site pour chaque élément.
Nous pouvons utiliser des dossiers imbriqués seulement dans quelques dossiers. Nous pouvons aussi les utiliser pour un cas d'utilisation spécifique.
Ce n'est pas parce que nous disposons de la puissance des dossiers imbriqués que nous devons toujours les utiliser. N'imbriquez les dossiers que lorsque vous avez un avantage organisationnel évident.
Dossiers imbriqués, dossier de page en premier
Utile pour identifier un ensemble de composants en utilisant d'abord le nom de la page.
Si les composants de chaque page sont uniques et que nous voulons les trouver en fonction de leur page, cette stratégie peut nous aider.
Si nous considérons les pages de notre site Web comme le meilleur moyen d'organiser les composants, cette stratégie peut nous aider.
dossier-page_dossier-mot-cle_nom-de-l-element
Dossiers imbriqués, dossier par mots-clés en premier
Utile pour identifier un composant d'abord par mot-clé, puis par nom de page.
Si la même catégorie de composant a des variations uniques sur de nombreuses pages différentes, nous pouvons vouloir utiliser le composant comme organisation de base.
En naviguant vers le dossier du composant, nous pouvons voir toutes les pages où le composant a des instances uniques.
dossier-mot-cle_dossier-page_nom-de-l-element
Dossiers imbriqués, toutes les organisations
Nous nous épanouissons dans la flexibilité.
Ci-dessus, nous voyons des cas d'utilisation clairs, mais il est un fait que toutes les décisions de nomination ne sont pas claires. Parfois, nous pouvons nous adapter parfaitement à l'une des stratégies ci-dessus. Parfois, nous devons faire quelque chose de différent pour répondre à notre cas d'utilisation.
Nous pouvons utiliser des dossiers pour n'importe quoi. Il n'y a pas de règles strictes en ce qui concerne les conventions de nomination des classes personnalisées.
Toute organisation est acceptée tant que l'objectif de la stratégie d'organisation est clair.
n-importe-quoi_n-importe-quoi_nom-de-l-element
Nom de la page dans le nom de la classe
La décision d'ajouter un nom de page à un nom de classe est puissante. Nous allons passer en revue ci-dessous les questions à se poser pour chaque projet.
Nous pouvons donner plus de clarté et de contexte à nos composants en y ajoutant le nom de la page. Cela nous permet de nous dire, et dire au prochain développeur, que cette classe est spécifique à une page.
Il est également possible de fournir autant de contexte en n'utilisant pas le nom de la page pour nos composants. Nous pouvons nous dire, et dire au prochain développeur, que cette classe n'est pas spécifique à une page et peut être utilisée globalement sur n'importe quelle page.
Des options flexibles en utilisant le nom de la page
- Les noms de page peuvent figurer dans le nom du dossier.
- Les noms de page peuvent figurer dans l'identifiant de l'élément.
- Les mots-clés peuvent être mélangés avec les noms de page dans le nom du dossier et l'identifiant.
Grâce à cette flexibilité, nous pouvons organiser nos projets en fonction de nos besoins.
N'oubliez pas que l'ajout du nom de la page n’est pas obligatoire, mais qu’il est de notre décision. Notre objectif final est de créer un projet organisé et facile à gérer. Il doit aussi permettre à l'utilisateur suivant de pouvoir modifier efficacement le projet Webflow. Si le contexte du nom de la page nous aide à mieux organiser le projet, alors ajoutez le nom de la page.
Pour prendre de meilleures décisions concernant l'utilisation des noms de page, nous pouvons nous poser les questions suivantes :
Cet élément est-il stylisé pour cette page uniquement ?
Si une classe est créée pour une page particulière, il est préférable d'utiliser le nom de cette page dans le nom de la classe.
La classe a pour but spécifique de faire [quelque chose] à un élément sur cette page particulière.
L'ajout du nom de la page donne un contexte à l'objectif de cette classe.
Nous présentons ici trois exemples de noms de page dans le nom de la classe. Chaque exemple présente deux options de dénomination : un niveau de dossier et deux niveaux de dossier.
composant-de-la-page_nom-de-l-element ou page_composant_nom-de-l-element
1. home-slider_arrow ou home_slider_arrow
2. team-slider_arrow ou team_slider_arrow
3. portfolio-slider_arrow ou portfolio_slider_arrow
Avec le nom de la page dans le nom de la classe, nous pouvons supposer que cette classe est spécifique à cette page. Elle n'entrera pas en conflit avec d'autres pages. Nous pouvons modifier la classe en sachant que nous modifions cette instance uniquement sur cette, spécifique, page.
S'agit-il d'un élément réutilisable tout au long du projet ?
Si vous souhaitez réutiliser des composants et des éléments dans l'ensemble du projet, il est préférable de ne pas utiliser le nom de la page dans ces noms de classe.
Il est peut-être préférable d'utiliser le mot-clé comme nom de dossier de niveau de base.
Nous ne voulons pas définir nos composants comme spécifiques à une page si le composant n'est pas spécifique à une page.
Si la classe est destinée à être utilisée ailleurs dans le projet, ou a le potentiel d'être utilisée ailleurs dans le projet, il n'est peut-être pas préférable d'utiliser le nom de la page.
Nous présentons ici plusieurs exemples d'éléments réutilisables qui ne sont pas spécifiques à une page. Leur dénomination est suffisamment générale pour préciser qu'ils sont réutilisables.
sujet-specifique_nom-de-l-element
slider_arrow
header_image-right
subscribe_form-input
clients-logos_row
Lorsque la nomination est très générale et qu'aucun nom de page n'est présent, nous pouvons faire davantage de suppositions en tant que nouveau développeur accédant au projet.
La classe slider_arrow est très générale et peut probablement être utilisée sur tous ou la plupart des carrousels. Avec les numérotations du panneau Styles, nous pouvons voir qu'elle est utilisée 2 fois sur cette page et sur 4 autres pages. Nous disposons de suffisamment d'informations pour supposer qu'il s'agit d'un élément réutilisable dans notre projet.
Si nous développions une nouvelle page dans le projet, nous pourrions utiliser cette classe sans la renommer. Nous serions également sûrs de ne pas modifier accidentellement d'autres instances avec des styles propres à la nouvelle page.
Le fait de nommer une classe avec un mot-clé général donne un contexte aux influences de cette classe sur le projet entier.
Quand utiliser le nom de la page (ou un mot-clé spécifique) comme préfixe de l'élément ?
Poursuivons avec l'exemple de la section précédente. Nous avons notre dossier slider_ qui est destiné à être utilisé dans l'ensemble de notre projet.
Imaginons qu'il y ait une variation du slider sur l'instance de la page témoignages. Le design des flèches de la page de témoignages est différent. Il s'agit d'une variation unique par rapport au slider_arrow par défaut. Tout est différent.
Ce slider de témoignages partage tous les styles du slider de base (global), à l'exception des flèches. Puisqu'il s'agit d'une variation mineure par rapport à l'ensemble du composant, il n'est pas utile de tout renommer testimonials-slider_component. Nous voulons toujours utiliser les styles du slider de base (gloabl) pour garder une certaine cohérence dans l'ensemble du projet.
La variation n'est pas assez importante pour créer un composant unique ou un nouveau dossier. Nous avons seulement besoin de flèches personnalisées pour la page de témoignages.
Nous pouvons utiliser des classes combinées ou une nouvelle classe personnalisée avec le nom de la page comme préfixe de l'élément.
Tout d'abord, nous allons présenter l'approche de la classe personnalisée.
Cette image montre le composant slider avec deux classes spécifiques aux témoignages. Nous ne créons pas un dossier unique. En revanche, nous ajoutons des précisions sur l'élément à l'intérieur du dossier slider_.
Les deux éléments, slider_testimonials-arrow et slider_testimonials-arrow-trigger utilisent le mot “testimonials” comme premier mot clé du nom de l'élément.
Le mot-clé "testimonials" nous indique que l'élément slider est spécifique à une instance de la page témoignages (testimonials).
Je ne sais pas si un élément est un nom de page ou un mot clé
Les noms de pages peuvent être confondus avec les mots-clés - ou les mots-clés avec les noms de pages.
Il peut arriver que le nom d'une page ne soit pas parfaitement clair par rapport à celui d'un mot-clé. Malgré tout, les principes de nomination nous aident à maintenir une stratégie d'organisation.
Par exemple, la classe testimonials_slider utilise "testimonials" comme mot-clé ou nom de page ?
Nous pouvons avoir une page client avec un slider de témoignages (testimonials).
Nous pouvons avoir une page de témoignages (testimonials) avec un slider.
Cette classe peut être présente sur de nombreuses pages et peut représenter un slider qui contient plusieurs types de témoignages (testimonials).
En tant que développeur du projet, nous savons peut-être ce que signifie la classe testimonials_. Cependant, les personnes qui consultent le site après nous peuvent ne pas comprendre parfaitement l'utilisation de cette classe.
Il n'existe pas de solution miracle pour identifier le mot-clé et sa signification pour chaque classe. Il est difficile de rendre chaque classe de notre projet 100% claire, quelle que soit la convention de nomination utilisée.
Cependant, nous voulons atteindre la plus grande clarté possible. C'est pourquoi le système "Client-First" existe.
Parfois, il y a des conflits de nomination, et ce n'est pas grave.
Tant que nous créons des noms qui donnent le plus de contexte possible à la classe, nous suivons le principe Client-First et fournissons un niveau puissant d'organisation à notre projet.
Un dossier vs. deux dossiers
L'utilisation des dossiers dans Client-First doit avoir un objectif.
Ce n'est pas parce que nous pouvons utiliser les dossiers imbriqués que nous devons toujours le faire. La taille de notre projet et le niveau d'organisation requis doivent être les deux principaux facteurs de décision concernant l'utilisation des niveaux d'imbrication des dossiers.
Si notre dossier testimonials_ comporte 100 éléments différents répartis sur plusieurs instances, il peut être judicieux d'utiliser un dossier imbriqué pour organiser davantage ces classes. Il peut être utile de disposer d'une "couche" supplémentaire d'organisation pour ces 100 éléments différents.
Si notre dossier clients_ contient 12 éléments, il n'est peut-être pas utile d'avoir un dossier imbriqué. Devons-nous organiser davantage ces 12 éléments ? Peut-être, mais probablement pas.
La décision d'utiliser un ou deux niveaux de dossiers pour notre projet nous appartient entièrement.
Comprenez que nous pouvons avoir des parties de notre projet qui utilisent un niveau de dossier et d'autres parties qui utilisent deux niveaux de dossier. Nous pouvons personnaliser le nombre de dossiers de la manière que nous voulons.
Exemple utilisant l'analogie de l'ordinateur
Prenons un exemple en utilisant l'analogie du dossier informatique.
Exemple : Nous avons un fichier excel avec tous nos résultats d'examens universitaires. Nous devons organiser ce fichier sur notre ordinateur.
> Nous avons des dossiers de niveau de base "École", "Travail", "Loisirs" et "Personnel".
>> Dans le dossier "École", nous avons "Primaire", "Université", "Master".
>>> Dans le dossier "Université", nous voyons notre fichier "university-test-scores.xls".
Il s'agit d'une structure de dossiers qui convient à un grand nombre d'ordinateurs personnels. Les différentes parties de notre vie sont classées et imbriqués dans des dossiers spécifiques.
Dans notre dossier "École", il y a des centaines de fichiers dans chacun des dossiers "Primaire", "Université" et "Master".
Si vous tentez de regrouper tous les fichiers dans un seul dossier appelé " École ", vous risquez de ne pas être organisé.
Si nous voulions trouver des fichiers spécifiques à "Université", ce serait difficile des les trouver si les trois niveaux de scolarité se trouvaient dans un seul et même dossier.
Trouver un fichier parmi des centaines de fichiers serait difficile. La création du deuxième niveau de dossiers nous donne une organisation plus profonde qui fonctionne bien dans ce cas d'utilisation.
Imaginez maintenant l'ordinateur personnel d'un jeune lycéen. Il n'a pas de travail ou d'activité secondaire. Il n'a que "École" et "Personnel".
Il y a moins de fichiers sur l'ordinateur du lycéen que sur celui de l'étudiant en master qui utilise son ordinateur depuis l'école primaire.
Pour notre jeune lycéen :
> Nous avons des dossiers de niveau de base "École" et "Personnel".
>> Dans le dossier "École", nous avons 12 fichiers. L'élève n'a pas beaucoup de fichiers pour l'école. Nous pouvons facilement trouver notre fichier "geography-test-scores.xls" parmi ces 12 fichiers.
Si nous suivions la structure des dossiers de l'étudiant en master pour ces 12 fichiers, trouver le fichier pourrait être plus difficile.
Il faudrait davantage de clics et de réflexion sur la façon dont les dossiers sont organisés. Si nous n'avons pas besoin d'un dossier imbriqué pour créer une organisation supplémentaire, nous ne devrions pas utiliser de dossier imbriqué.
Les dossiers imbriqués doivent nous aider à travailler plus vite, pas plus lentement.
Bibliothèques de composants
Les bibliothèques de composants, comme la Relume Library, peuvent bénéficier de dossiers imbriqués - ou peut-être de nombreux dossiers imbriqués.
Les dossiers apportent une amélioration organisationnelle massive aux bibliothèques de composants de toutes tailles. Nous allons montrer un exemple de ceci avec un cas d'utilisation de bibliothèque de composants.
Dans une bibliothèque de composants, nous pouvons vouloir organiser les classes de la manière suivante :
slider1_component
slider2_component
slider3_component
grid1_component
grid7_component
logo-row1_component
logo-row2_component
Il n'y a pas de manière spécifique pour nommer les composants dans une bibliothèque de composants afin qu'ils soient spécifiques à une instance.
Une bibliothèque de composants vise à créer des composants réutilisables qui peuvent être utilisés partout dans notre projet.
Si une bibliothèque de composants comporte 100 composants, nous verrons 100 dossiers dans notre système de dossiers virtuels. Cette liste peut ne pas être facile à parcourir.
L'ajout d'un tiret du bas / underscore (_) permet de mieux organiser nos composants pour gérer les variations et les différentes options.
Les mêmes classes ont été réécrites pour inclure un dossier imbriqué avec le numéro de variation.
slider_1_component
slider_2_component
slider_3_component
grid_1_component
grid_7_component
logo-row_1_component
logo-row_2_component
Admirez le résultat obtenu par cette convention de nomination.
Nous pouvons organiser tous nos composants dans des dossiers de premier niveau. Lorsque nous cliquons dans chaque dossier, nous voyons combien de variantes d'options sont disponibles. Chaque variation est clairement définie et organisée dans son dossier.
Pour les très grandes bibliothèques de composants comportant de nombreuses variations, il peut être judicieux d'utiliser trois niveaux de dossiers - des dossiers imbriqués.
La puissance de l'extension Finsweet pour renommer
Une fois que le composant est dans notre projet principal, nous pouvons renommer le dossier entier avec l’extension Chrome Finsweet Extension.
En utilisant l'extension Finsweet, nous pouvons renommer en gros / massivement (bulk) n'importe quel nom de dossier.
Cela signifie que nous pouvons copier layouts_grid_1_ dans notre projet et renommer en masse chaque élément de ce dossier en team-grid_. Ce changement de nom de dossier en masse prend quelques secondes dans l'extension.
Pour plus d'informations sur les capacités de Finsweet Extension, voir la page Folders (Dossiers).
Utiliser le mot-clé du composant
La version initiale V1 de Client-First définissait les composants comme suit :
Par exemple, l'inscription à une newsletter, une grille avec les membres de l'équipe, un calculateur de prix, une grille à 3 colonnes réutilisable ou une liste de clients.
Dans Client-First, les composants ont toujours été définis comme utilisant un trait de soulignement dans le nom de la classe.
Tout ceci est encore vrai. Dans cette mise à jour des dossiers, nous serons plus spécifiques lorsque nous utiliserons des composants - et plus précis lorsque nous utiliserons des tirets du bas (underscore) !
V1 Version initiale
tiret du bas dans le nom de la classe = composant
V2 avec les Dossiers (Folders)
tiret du bas dans le nom de la classe = Dossier
[nom-du-dossier]_composant = composant
L'utilisation du tiret du bas dans les dossiers pour le nom de la classe ne signifie pas nécessairement que le dossier est un composant. Nous utilisons désormais l’underscore pour l'organisation ou le regroupement d'éléments dans les dossiers.
Les composants ont maintenant une classification spécifique. Si nous voulons qu'un élément soit un composant, nous utilisons le mot "component" (composant) pour identifier l'élément.
L'utilisation du mot-clé "component" nous indique que ce dossier représente un composant, c'est-à-dire un groupe d'éléments de page qui créent un élément d'interface utilisateur (UI) complet.
Nous pouvons considérer les composants comme une structure complète que nous pouvons copier-coller. Nous copions la structure complète à partir de la classe _component.
Par exemple, nous pouvons avoir un slider clients sur notre site Web. Nous considérons ce carrousel (slider) comme un composant. Dans le wrapper parent de tous les éléments du slider client, nous ajouterons notre mot-clé component. Par exemple :
client-slider_component
client-slider_mask
client-slider_grid
client-slider_arrow
Cela nous indique que le dossier clients-slider_ est un component
Tout ne doit pas nécessairement être un composant. Des structures telles que l'inscription à une newsletter, une grille avec les membres de l'équipe, un calculateur de prix, une grille à 3 colonnes réutilisable ou une liste de clients sont toutes d'excellents exemples de composants.
Parfois, nous voulons utiliser des dossiers pour des regroupements autres que des composants.
Par exemple, un dossier de guide de style. Si notre projet Webflow utilise un guide de style, nous aurons probablement besoin de créer des classes pour le guide de style. Les classes du guide de style (Style Guide) peuvent se trouver sur une seule page. Les classes peuvent être utilisées sur plusieurs pages.
Pour organiser les classes de notre guide de style, nous pouvons les placer dans un dossier spécifique à des fins d'organisation.
styleguide_structure
styleguide_content
styleguide_item
styleguide_sidebar
Notre page de guide de style n'est pas un composant. Il s'agit simplement d'une organisation d'éléments.
Ajouter le mot-clé _component est toujours optionnel. En tant que développeurs, nous décidons d'ajouter un "tag" component comme identifiant de l'élément du nom de la classe.
Arbre de décision pour les dossiers (Folders)
Il y a de nombreuses décisions à prendre lorsque nous organisons notre projet.
Certaines de ces décisions peuvent être prises avant de commencer le développement.
De nombreuses décisions seront prises au fur et à mesure du développement.
Au début, les décisions relatives à la nomination des dossiers peuvent prendre beaucoup de temps. La pratique permet de prendre des décisions de nomination rapides et intelligentes.
Comprenez que la prise de décisions concernant l'attribution de noms aux dossiers est une chose que nous améliorerons au fur et à mesure que nous continuerons à utiliser Client-First.
Notre vitesse et notre précision s'amélioreront au fur et à mesure que nous continuerons à utiliser la fonction Folders (Dossiers) dans nos projets.
Dans l'arbre de décision, que vous pouvez téléchargez ici, nous allons examiner un exemple de décision d'attribution de nom à l'élément "slider pane" d'un slider dans notre projet.
Il se peut que la lecture de ce graphique ait pris quelques minutes. Nous n'aurons pas besoin de quelques minutes pour prendre des décisions concernant chaque nom. Si nous continuons à appliquer cette logique aux décisions relatives à la nomination de notre classe, nous prendrons ces décisions plus rapidement.
Nous pouvons rapidement prendre ces décisions complexes avec de la pratique, des essais et des erreurs.
Vous avez une question à laquelle vous n'avez pas trouvé de réponse dans la documentation ? N'hésitez pas à me la poser sur Linkedin.