Organisation et maintenance de grandes bases de code: bibliothèque principale, données, interface utilisateur, documentation et wiki, tests, composants hérités et composants tiers ... comment suivre et maintenir l'ordre de tout ce contenu? L'organisation des fichiers dans les bases de code peut être une tâche difficile.
Ne vous inquiétez pas - nous pouvons le faire! Cet article passera en revue les systèmes les plus couramment utilisés pour les petits et les grands projets et offrira certaines meilleures pratiques faciles à suivre.
Comme avec presque toutes les tâches liées à la gestion de projet - documentation, soumission de logiciels, déploiement - vous bénéficierez grandement d'une approche consciente et programmatique. Cela réduira non seulement les problèmes actuels, mais vous fera également gagner un temps précieux, ainsi que votre équipe, lorsque le contenu doit être rapidement accessible et examiné à l'avenir.
Vous pouvez certainement vous rappeler le nom de la fonction de tout ce que vous écrivez en ce moment et trouver rapidement les fichiers que vous avez besoin pour éditer et dire clairement ce qui fonctionne et ce qui ne fonctionne pas - ou ce que vous pensez. Mais pouvez-vous dire la même chose au sujet du projet sur lequel vous avez travaillé l'année dernière?Admitons: les projets logiciels peuvent durer des mois, voire des années d'inactivité. Un fichier de réadme simple peut faire beaucoup de choses pour vos collègues ou vous avenir. Mais considérons d'autres façons de créer un projet et de créer des règles de base pour nommer des fichiers, de traiter la documentation du projet et, dans une certaine mesure, organiser un flux de travail efficace qui résiste à l'épreuve du temps.
comprendre les choses
Nous établirons une "ligne de base" pour les documents d'un projet d'organisation - une logique qui nous servira dans de nombreuses situations dans le cadre du développement logiciel.est le nom du jeu. Assurez-vous de comprendre (et de discuter ou de discuter) quelles sont les règles et de les suivre après le consensus.
Il s'agit d'une liste de référence des fichiers que presque tous les projets logiciels devraient avoir:
Auteurs: L'attribution de la personne impliquée dans la rédaction du code.
Certains exemples pourraient être:
Internationalisation (I18N) et localisation (L18N)
Nous voulons restreindre la création de répertoires pour garder les choses gérables, que ce soit dans le répertoire racine (les principaux composants seront situés ici) ou récursivement (dans chaque répertoire). Sinon, nous pouvons finir par passer beaucoup de temps à parcourir régulièrement des fichiers dans des répertoires bien organisés.
Veuillez exclure ces
de l'arbre sourceDonnées. Vous pourriez être tenté d'avoir un répertoire / répertoire dans l'arborescence source pour les fichiers CSV, etc., surtout s'ils ne prennent que quelques kilobytes. Mais que se passe-t-il s'ils prennent des mégaoctets ou même des gigaoctets (qui n'est pas rare de nos jours)? Voulez-vous vraiment les soumettre à votre code comme vous le feriez avec votre base de code? Non.
Fichier binaire. Vous ne voulez pas que le rendu vidéo ou les exécutables compilés soit situé à côté du code source. Ce ne sont pas des fichiers de développement, ils n'appartiennent pas du tout ici. Comme les fichiers de données, ils peuvent finir par prendre beaucoup d'espace.
Paramètres. Ceci est un autre grand tabou. Vous ne devez pas placer les informations d'identification, les mots de passe ou même les jetons de sécurité dans votre base de code. Nous ne pouvons pas couvrir une solution à ce problème ici, mais si vous êtes un développeur Python, envisagez d'utiliser Python Decouple.
Considérons une application Web - un logiciel qui s'exécute sur un serveur Web auquel vous pouvez accéder via un navigateur, que ce soit sur un bureau ou un appareil mobile. Et en supposant qu'il s'agit d'une application Web qui fournit un abonnement pour accéder à une sorte de service premium - des rapports exclusifs, des conseils de voyage ou des vidéos.
<code>├── .elasticbeanstalk ├── .env ├── billing ├── changelog.txt ├── locale │ ├── en │ └── zh_Hans ├── members ├── readme.txt ├── static │ ├── fonts │ ├── images │ ├── javascript │ └── styles ├── templates │ ├── admin │ └── frontend ├── todo.txt └── tools</code>
Il s'agit d'une structure d'application Web de base avec la prise en charge de deux langues (chinois anglais et simplifié (répertoire local). Il existe également deux composantes principales, la facturation et les membres.
Si vous êtes un peu plus familier avec le développement du site Web, le contenu des dossiers statiques et des modèles peut sembler familier. Peut-être que le seul élément inhabituel pourrait être .ElasticBeanStalk, qui stocke les fichiers de déploiement pour Amazon Web Services (AWS), et .env, qui stocke uniquement les paramètres de projets sur site tels que les informations d'identification de base de données. Le reste, comme Readme et Todo, nous en avons discuté. Le répertoire des outils est un répertoire intéressant. Ici, nous pouvons stocker des scripts, par exemple, la réduction de la base de données, le contrôle de l'état de paiement ou rendre les fichiers statiques à cache - en grande partie, tout ce qui n'est pas l'application elle-même mais contribue à le faire fonctionner.
En ce qui concerne la dénomination, si nous nommons le répertoire d'images en tant qu'images / ou img /, ou nommez le répertoire des styles en tant que styles / ou css /, ou nommez le répertoire JavaScript / comme js /, il n'y a pas de différence. L'essentiel est que la structure est logique, et nous suivons toujours une certaine convention, qu'il s'agisse d'un long nom descriptif ou court.cas 2: application de bureau
Laissez-nous maintenant considérer une application que vous pouvez télécharger et installer sur votre ordinateur. Et supposons que l'application nécessite des entrées, telles qu'un fichier CSV, puis rendez une série de rapports.
Structure de fichiers
<code>├── .gitignore ├── data ├── doc ├── legacy │ ├── dashboard │ ├── img │ └── system ├── LICENSE ├── README ├── tests ├── thirdparty ├── tools │ ├── data_integration │ └── data_scraping ├── ui │ ├── charts │ ├── css │ ├── csv │ ├── dashboard │ ├── img │ │ └── icons │ ├── js │ ├── reports │ └── summaries ├── VERSION └── wiki</code>
Legacy / dossier est utilisé pour une partie de l'application qui est sur le point d'être interrompu, mais fournit toujours certaines fonctionnalités qui peuvent être utiles jusqu'à ce qu'elle soit complètement refactorisée dans un nouveau système. Par conséquent, il fournit un bon moyen de séparer l'ancien code du code actuel.
Un nouvel ajout ici est Tests /, qui fournit un endroit pour assurer la qualité à l'aide de tests unitaires, et tiers /, un endroit pour stocker les bibliothèques externes requises par le logiciel.
Notez qu'il existe des doc / et wiki / dossiers, qui peuvent ressembler à un double. Cependant, il est également tout à fait possible d'avoir un dossier de documents pour l'utilisateur final et un wiki pour l'équipe de développement - même raisonnable.
La bonne nouvelle qui mérite d'être répétée est: même si vous travaillez seul, vous devez être organisé. J'espère que cet article vous fournit quelques idées que vous pouvez commencer à appliquer immédiatement à votre workflow pour éviter la confusion à mesure que le nombre de fichiers dans votre application augmente.
Comme mentionné précédemment, les directives peuvent changer de temps à autre, car (presque) chaque projet est différent, tout comme l'équipe. Idéalement, vous ou votre équipe déciderez comment construire un projet - ajoutez un petit document pour décrire les raisons de cette structure - puis vous vous en tiendrez à ces règles à partir de maintenant.
N'oubliez pas que pour de nombreuses directives ici, peu importe si vous choisissez un tableau de bord ou un soulignement pour nommer un fichier (sélectionnez l'un des nombreux sujets). La clé est la cohérence.
Il y a de nombreux avantages à organiser des documents de projet de manière structurée. Tout d'abord, il améliore la lisibilité et la maintenabilité du code. Lorsque les fichiers sont organisés logiquement, il est plus facile pour les développeurs de comprendre la base de code et d'apporter des modifications sans casser les fonctionnalités existantes. Deuxièmement, il améliore le travail d'équipe. Lorsque plusieurs développeurs travaillent sur le même projet, une structure de fichiers bien organisée garantit que tout le monde sait où trouver un extrait spécifique. Enfin, il accélère le processus de développement. Les développeurs passent moins de temps à rechercher des fichiers et plus de temps à écrire et à optimiser le code.
La structure optimale d'un fichier de projet dépend de la nature et de la complexité du projet. Pour les petits projets, une structure de répertoire simple peut être suffisante. Cependant, pour les projets plus grands avec plusieurs composants, vous pourriez avoir besoin d'une structure plus complexe. Considérez des facteurs tels que le langage de programmation que vous utilisez, le cadre ou la bibliothèque que vous utilisez et les préférences de l'équipe. Il est important de rendre la structure flexible afin qu'elle puisse se développer à mesure que le projet se développe.
Il existe plusieurs stratégies pour organiser le code. Une méthode courante consiste à regrouper les fichiers par fonction. Cela signifie que tous les fichiers liés à une fonction spécifique sont enregistrés dans le même répertoire. Une autre façon consiste à regrouper les fichiers par type, tels que la division des fichiers CSS, JavaScript et HTML en différents répertoires. Certains développeurs préfèrent utiliser une approche hybride, combinant des éléments des deux stratégies. La clé est de choisir une stratégie qui a du sens pour votre projet et votre équipe.
à mesure que la base de code se développe, il est important de vérifier et de refactor régulièrement la structure des fichiers. Cela peut inclure la division des fichiers volumineux en fichiers plus petits et plus gérables ou réorganiser les répertoires pour mieux refléter l'état actuel du projet. Les outils d'automatisation peuvent aider à identifier les zones de la base de code qui deviennent maladroites ou difficiles à maintenir. Les avis réguliers de code peuvent également aider à garantir que le nouveau code est conforme à la structure de fichiers établie.
Les conventions de dénomination jouent un rôle crucial dans l'organisation des documents. Les noms de fichiers descriptifs cohérents facilitent la compréhension de ce que chaque fichier contient en un coup d'œil. Cela peut considérablement accélérer le processus de développement, en particulier lorsqu'il s'agit de grands projets ou de travailler avec des équipes. Les conventions de dénomination doivent être convenues au début du projet et restent toujours cohérentes.
Pour vous assurer que tous les membres de l'équipe suivent la politique de votre organisation de fichiers, il est important de documenter clairement votre politique et de rendre le document accessible. Les examens de code réguliers peuvent également aider à appliquer la politique. Envisagez également d'utiliser un outil d'automatisation qui peut vérifier s'il est conforme aux règles de votre organisation de documents.
Oui, vous pouvez modifier les politiques d'organisation des fichiers au milieu du projet, mais cela devrait être fait avec prudence pour éviter de perturber le flux de travail. Avant d'apporter des modifications, discutez de la nouvelle stratégie proposée avec votre équipe et assurez-vous que tout le monde comprend les raisons du changement et comment la mettre en œuvre. Il est important de mettre à jour également les documents pertinents pour refléter la nouvelle politique.
Lors de l'organisation des fichiers de projet, le traitement des dépendances peut être un défi. Une façon consiste à enregistrer toutes les dépendances dans un répertoire séparé. Cela facilite les gérer et les mettre à jour. Certains langages de programmation et gestionnaires de packages fournissent également des outils pour gérer les dépendances qui automatisent la majeure partie du processus.
Certaines erreurs courantes qui devraient être évitées lors de l'organisation des fichiers de projet incluent: ne pas planifier la structure de fichiers à l'avance, sans suivre des conventions de dénomination cohérentes, et non d'enregistrer les politiques d'organisation des fichiers et la vérification irrégulière et le refactorisation des structures de fichiers. Éviter ces erreurs peut aider à garder la base de code soignée, organisée et facile à naviguer.
Il existe de nombreuses ressources disponibles pour apprendre les meilleures pratiques pour l'organisation de documents. Les tutoriels en ligne, le codage de bootcamps et des forums de développeurs peuvent fournir des informations précieuses. De plus, l'étude de la structure du dossier d'un projet open source peut fournir des exemples pratiques de la façon d'organiser efficacement les fichiers de projet.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
le fichier HTML s'ouvre vide
paramètres de compatibilité du navigateur Edge
Quel est le format du document ?
Introduction aux composants Laravel
Comment basculer entre pleine largeur et demi-largeur
méthode js pour générer des nombres aléatoires
Introduction aux types d'interfaces de disque dur
Représentation binaire des nombres négatifs
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
