Share
L'organisation peut faire ou défaire la maintenabilité d'une application. Avec des applications plus petites, l'organisation est plus évidente. Cependant, à mesure que l'application grandit et que le nombre de développeurs d'applications et d'ingénieurs front-end produisant du code augmente, l'organisation peut devenir plus confuse. Dans cet article, nous allons passer en revue quelques concepts de base pour organiser les applications de manière à ce que la recherche du code pertinent soit un processus efficace et systématique..
JavaScript doit être ciblé de manière efficace.
Prenons un instant pour examiner la manière dont les équipes Rails et Wordpress organisent leurs projets. Les chances sont, vous avez probablement travaillé avec l'un ou l'autre de ceux-ci. Les deux frameworks ont une structure par défaut.
Lors de la génération d'une application Rails, Rails gère la plupart des besoins organisationnels principaux pour vous. Comme il est basé sur MVC, la configuration par défaut de Rails comprend un dossier intitulé "app", qui contient les dossiers model / view / controller. Il fournit également les "assistants" et les "expéditeurs", les extensions de contrôleur permettant de combler les lacunes entre les contrôleurs et les modèles..
Rails génère également quelques autres éléments au même niveau que le dossier "app", tels que la configuration, la journalisation, les bases de données, le cache / mise en cache, les tests, etc. Les dossiers de l'application et les dossiers publics sont particulièrement intéressants pour cette discussion. Le dossier public est l’endroit où sont servis les actifs statiques, y compris les fichiers HTML, CSS et JavaScript non dynamiques..
Lorsque vous travaillez avec Wordpress, la dénomination et la structure sont beaucoup moins évidentes.
… L'application est conçue pour les utilisateurs…
Les conventions sont exposées via la documentation. En particulier, les développeurs travaillent probablement dans un thème situé dans le répertoire wp-content / themes /. Ce thème contient un tableau de fichiers avec des noms spéciaux, principalement basés sur des vues. UNE functions.php Le fichier agit en tant que "contrôleur", dans lequel un développeur peut insérer des fonctions afin de les séparer des vues. Cependant, les thèmes Wordpress brouillent souvent les frontières entre logique et présentation. Par exemple, les requêtes de base de données sont implicites par nom de fichier, mais sont souvent manipulées en les modifiant avant de parcourir les résultats renvoyés. Cette manipulation ne résume pas de la même manière qu’un contrôleur (et, bien entendu, Wordpress n’est pas proche de MVC, nous ne pouvons donc pas nous attendre à ce type d’organisation)..
Ces deux cadres sont extrêmement populaires et utilisent tous les deux leur propre structuration implicite. Ils exigent absolument que les développeurs comprennent le fonctionnement du système pour être efficaces. Dans nos propres applications, nous devrions tenir compte de ce paradigme organisationnel et créer une approche systématique pour la structuration des applications. Cela se déroule très différemment pour chaque application.
Les frameworks mentionnés ci-dessus ne nécessitent pas que les développeurs définissent la structure; ils sont "pré-câblés" pour fonctionner d'une manière spécifique.
Une raison importante pour laquelle les frameworks robustes font souvent abstraction de ces configurations et fournissent des structures par défaut est que les gens commencent à développer une norme de communauté basée sur la structure par défaut.
Ne pas ignorer les normes lors de l'organisation de votre application!
Si vous connaissez Rails, vous pouvez probablement consulter un référentiel Github et savoir s’il s’agit d’une application Rails uniquement par la structure de dossiers. Rails dispose d’une norme documentée..
Ne pas ignorer les normes lors de l'organisation de votre application! Il est fort probable que si vous organisez une application au niveau de l'entreprise, vous utilisez des mini-applications modulaires et discrètes basées sur des services. Par exemple, il se peut que vous disposiez de plusieurs applications construites avec un ou plusieurs frameworks différents, ou que vous les fassiez rouler à la main et que vous travailliez ensemble, exposant ainsi les API qui fournissent des points d'ancrage aux autres services. Chacune de ces applications discrètes respecte probablement les normes du cadre sur lequel elle a été construite; ces normes existent parce qu'elles correspondent à la manière dont ce cadre a été conçu. Si vous essayez de changer ces normes dans une application discrète, vous finirez probablement par perdre plus de temps à configurer que réellement construire une application de travail.
En pratique, cela signifie que les éléments exposés d’un service à un autre doivent fonctionner de manière uniforme et que les éléments internes à un service doivent fonctionner de la manière la mieux adaptée à ce service particulier, probablement en fonction du cadre ou de la structure. pile technologique sur laquelle le service fonctionne.
Rappelez-vous qu'à la fin de la journée, l'application est conçue pour les utilisateurs, qui ne savent ni n'apprécient la séparation des services discrets..
Au lieu de cela, ils comprennent l'application et l'expérience comme une seule et même pièce, et cette dernière bénéficiera principalement de l'uniformité au niveau supérieur.
Alors qu'est-ce qui doit être uniforme?
à mesure que l’application se développe… l’organisation la plus confuse peut devenir.
Les itinéraires (structures d'URL) sont l'un des facteurs de définition les plus importants du fonctionnement d'une application Web. Il est important que vos itinéraires suivent une structure uniforme. Par exemple, lors de l'affichage d'un "compte utilisateur" avec une URL telle que / utilisateur / 5 où 5 est l'ID de clé primaire de l'utilisateur, vous ne devez pas utiliser un pluriel pour un autre objet singulier, tel que / widgets / 16. Au lieu de cela, il devrait être / widget / 16. Cela aide non seulement les développeurs à être cohérents, mais apporte également clarté et uniformité aux utilisateurs. Peu importe ce que vous choisissez pour la structure de votre itinéraire, à condition que ce soit cohérent au niveau de l'utilisateur.
C’est un élément extrêmement important pour le développement interne, et encore plus pour le développement de produits / services logiciels lorsqu'une API est exposée au public. Si vos appels d'API ont des traits de soulignement comme séparateurs de mots, n'utilisez pas ailleurs une clé camelCase ou une touche séparée par un tiret dans votre API. Si vous utilisez le mot "count" pour signifier "renvoyer ce nombre d'objets", n'utilisez pas un mot comme "count_per_page" pour désigner la même chose ailleurs dans la même API (ou dans une API associée). C'est une conception d'API bâclée. Développez une syntaxe standard et respectez-la. Notez que cela est souvent pris en charge par une conception de route bien exécutée dans les API REST..
De manière générale, lorsque vous utilisez des "foo widgets" (objets ou actions arbitraires) dans votre application, veillez à utiliser la même terminologie dans toutes vos applications. Par exemple, s'il peut être courant dans Rails d'utiliser le répertoire "public", vous avez le contrôle sur ce qui se trouve à l'intérieur de celui-ci..
Ne pas utiliser un dossier "js" pour un framework et un dossier "scripts" pour un autre framework.
N'appelez pas les modèles de données "orange_items" dans un cadre et "OrangeItems" dans un autre, à moins que le langage ou le cadre ne le demande explicitement pour une raison fonctionnelle. Même dans ce cas, assurez-vous qu’il existe un système et une "grammaire" cohérents et que les différences entre les services bien documenté et justifié. Ces types de signaux et d’uniformité faciliteront grandement la compréhension des classifications d’objets dans une application..
La mise en miroir des itinéraires vers des dossiers et des fichiers aide grandement à garder une application organisée. Par exemple, vous pouvez avoir des dossiers pour CSS, JavaScript et Images dans vos dossiers "publics" ou "statiques". La création d'une structure de dossiers qui correspond à vos itinéraires, vues, contrôleurs ou autres structures similaires peut aider à garder votre CSS modulaire. Vous pouvez ensuite utiliser un outil tel que CodeKit pour concaténer ces fichiers en un seul fichier minifié. Bien sûr, vous pouvez aussi avoir un global.css pour les règles qui s'appliquent à l'ensemble de l'application. Voir ci-dessous pour un exemple (.rb est pour Ruby, mais cela peut aller pour n'importe quelle organisation cadre de MVC).
- root / - app / --- modèles / ---- foo.rb ---- bar.rb ---- baz / ----- widget.rb --- views / ---- global. html.erb ---- foo.html.erb ---- bar.html.erb ---- baz / ----- widget.html.erb --- contrôleurs ---- foo.rb - - bar.rb - public - CSS --- global.css --- foo.css --- bar.css --- baz / ---- widget.css - JS --- global.js - - foo.js --- bar.js --- baz / ---- widget.js - Images / --- global / ---- image.jpeg --- foo ---- image.jpeg --- barre ---- image.jpeg --- baz / ---- widget / ----- image.jpeg
On peut rapidement voir qu'il ne serait pas difficile de trouver des CSS, JavaScript, modèles, etc. spécifiques pour une section spécifique de l'application..
Les itinéraires (structures d'URL) sont l'un des facteurs de définition les plus importants du fonctionnement d'une application Web..
La meilleure façon de penser à cela est de séparer vos fichiers en "zones" de votre site. Par exemple, vous avez peut-être une application qui comprend une zone "admin" et une zone "profil". Vous pouvez créer un global.css fichier pour contenir les objets / règles qui s'appliquent aux deux zones (y compris une réinitialisation, certaines règles de typographie, couleurs, etc.), puis créer des fichiers spécifiques qui s'appliquent aux différentes zones pour les règles de style de contenu non partagées. Ainsi, lorsqu'un développeur travaille sur une page spécifique, il reste dans un ou deux fichiers et sait exactement où trouver les bons fichiers..
Un autre moyen efficace de contrôler vos fichiers statiques consiste à les nommer en fonction de leurs tâches. Par exemple, créer un reset.css, une typographie.css, une dimensions.css, une couleurs.css, etc. Cette méthode présente des avantages et des inconvénients, en particulier pour les CSS. Il garde votre CSS concentré sur les règles de présentation. Toutefois, il faudra probablement répéter les sélecteurs sur plusieurs fichiers et les rouvrir pour définir différents types de règles de style. La seule façon d'éviter cela consiste à nommer vos classes / ID uniquement par style plutôt que par sémantique, telle que class = "ombre moyenne à cinq colonnes de texte vert". Sinon, vous finirez par faire quelque chose comme ceci:
Dans typographie.css
.semantic-widget color: # 232323; text-shadow: 1px 1px #fff; taille de police: 1.2em; hauteur de ligne: 1.1em; famille de polices: sans-serif; poids de la police: 300;
Dans dimensions.css
.semantic-widget width: 20%; marge: 0 2,5%; rembourrage: 10px;
Ce qui bien sûr n'est pas aussi sec que possible.
L'organisation d'applications plus petites (avec moins de ces objets "widgets") peut toujours bénéficier de la séparation par type de règle.
Toutefois, si votre application comporte de nombreux types d’objets, zones d’application, etc., vous devez probablement choisir de séparer vos fichiers CSS en zones (la stratégie de mise en miroir décrite plus haut)..
Nommer les fichiers JavaScript par leurs fonctions est un peu plus pratique, mais seulement si vous tirez parti des déclencheurs d'événements (un modèle pub / sous). Prenons l'exemple suivant:
Accentsconagua
$ .getJSON ("/ messages / all.json", function (data) // faire des trucs); Vous voudrez peut-être faire pas mal de choses dans ce rappel. Vous souhaiterez peut-être envoyer une notification à l'utilisateur et mettre à jour une liste de messages. Si vos fichiers sont séparés par des fonctionnalités, vous pouvez avoir un notifications.js et un messages.js fichier qui gère ces fonctions particulières. Dans le rappel de cet appel ajax JSON, vous "publiez" un événement dans le reste de l'application. Ensuite, dans vos fichiers de notifications et de messages, vous pouvez "vous abonner" à l'événement et y répondre en conséquence..
dans événements.js:
$ .getJSON ("/ messages / all.json", fonction (messages) $ ("corps"). trigger ("messages reçus", messages);); dans messages.js:
$ ("body"). on ("receive_messages", function (événement, messages) // itérence dans les messages et ajout à une liste); dans notifications.js
$ ("body"). on ("receive_messages", function (événement, messages) // send_notification peut être une fonction locale permettant d'envoyer des notifications // à l'utilisateur, ainsi qu'un type de notification, un entier; pour Par exemple, dans ce cas //, "1" peut simplement signifier que la notification est une alerte "de succès" send_notification ("Messages reçus avec succès!", 1);); Il y a quelques points à garder à l'esprit à propos de vos fichiers statiques. Cet article suppose que vous concaténez vos fichiers statiques de manière appropriée. Mais qu'est-ce qui est approprié?
Alors, pourquoi feriez-vous cela, demandez-vous? Principalement pour tirer parti du cache du navigateur.
La concaténation à la volée, par exemple, ne vous permet pas de tirer parti du cache du navigateur. L’autre avantage de cette approche est de ne charger que ce dont vous avez besoin. Si vous avez toute une section "admin" que 95% de vos utilisateurs ne voient jamais, ils ne devraient pas avoir à télécharger le CSS pour cette section..
Développer une syntaxe standard et s'y tenir.
Semblable à CSS, JavaScript doit être défini de manière efficace..
Les gains doivent toujours être gérés avec soin; si votre javascript est suffisamment petit pour justifier la concaténation dans un seul script, ne vous sentez pas obligé de charger du code JavaScript modulaire dans votre produit final..
Comme indiqué brièvement ci-dessus, si le nombre d'utilisateurs accédant à une page spécifique est négligeable, ne placez pas le fichier CSS / JS dans les fichiers statiques de votre application globale. Les fichiers statiques administratifs doivent également rester séparés. Si votre application prend en charge les comptes d'utilisateurs, envisagez de divulguer les fichiers statiques du côté non autorisé (marketing) de l'application. Une fois qu'un utilisateur s'est connecté, il s'est déjà engagé à participer à toutes les applications de votre application. Les premières impressions font tout, et charger un tas de CSS et de JavaScript non utilisés ne fera que dégrader les performances d'une première impression..
Si vous utilisez effectivement un cadre, utilisez la structure existante de ce cadre. Si votre infrastructure ne dispose pas d'une structure existante ou d'une structure très simple (Sinatra et CodeIgniter en sont d'excellents exemples), envisagez de reproduire la structure des autres composants de l'application. Si vous commencez à partir de zéro, jetez un coup d'œil aux autres projets que les personnes ont réalisés dans le cadre que vous utilisez et dans d'autres cadres utilisant le même langage. Par exemple, si votre structure fonctionne sur MVC mais n’a pas de configuration par défaut pour l’emplacement de ces éléments, il est probable qu’il existe un nom. convention qui utilise les mots-clés Model, View et Controller.
En fin de compte, l’organisation au niveau de l’entreprise se compose de quatre choses principales:
