J'ai lu beaucoup de choses sur Internet. Il est vraiment difficile de trouver quoi que ce soit sur l'architecture logicielle JAVA. Cependant, l'architecture du développement logiciel est fondamentalement la même. Par conséquent, j'ai recherché de nombreux articles sur l'architecture logicielle dans d'autres langues sur Internet. Là encore, permettez-moi de parler de mon point de vue sur l'architecture logicielle, notamment sur l'architecture des projets JAVA. Ce n’est peut-être pas exact, mais c’est aussi mon résumé de ces dernières années.
1. Essayez de ne pas envisager la réutilisation en dehors du projet
Beaucoup de gens pensent qu'il est préférable d'améliorer la réutilisabilité des logiciels. Cependant, la situation réelle de chaque projet sera différente lors de la conception d'un certain module ou d'une certaine méthode dans le projet, une trop grande considération de la réutilisation en dehors du projet augmentera inévitablement le nombre. des projets. La complexité augmente le temps de développement. Certains diront peut-être que cela réduira le coût du prochain projet. Quel est le prochain projet ? Quels sont les besoins ? Quels sont les facteurs d’influence sous différents aspects ? Qui saurait tout cela à ce moment-là. Si vous souhaitez vraiment réutiliser, vous devez extraire les pièces réutilisables une fois le projet terminé, les modifier et les optimiser et les utiliser comme actifs réutilisables de l'entreprise, plutôt que comme un vœu pieux dans le projet en cours. Envisager la réutilisabilité en dehors du projet. Il s'agit d'une erreur courante commise par de nombreux programmeurs qui débutent dans le domaine des logiciels. Souvent, plus ils y réfléchissent, plus le logiciel qu'ils créent ne parvient pas à obtenir l'effet de conception et ne parvient pas à remplir les fonctions de base ou. Processus logiques de code. Beaucoup, les fonctions du programme ne sont pas parfaites et ainsi de suite.
2. Vérifiez fréquemment la structure du projet
L’architecture du projet est généralement déterminée avant le début de la mise en œuvre du projet et constitue une conception globale. Cependant, à l’heure actuelle, la compréhension des exigences du projet et l’estimation de la complexité en sont encore à un stade initial. Si l'architecture ne peut pas être améliorée ainsi que la compréhension du projet pendant le processus de développement du projet, les membres du projet développeront inévitablement le projet selon une mauvaise architecture. Par conséquent, l’architecture du projet doit être vérifiée fréquemment et les refactorisations nécessaires doivent être effectuées.
3. Refactorisation
Certains disent qu’après avoir tant écrit, le réviser n’est pas une perte de temps. Il n'aurait peut-être pas pensé qu'un après-midi de refactoring pourrait accélérer le développement au cours des prochains mois. Le temps gagné est inimaginable. De plus, grâce au refactoring, vous pouvez généralement penser à des méthodes plus simples pour remplacer l'implémentation existante. Cette expérience peut également simplifier le développement d'autres modules.
4. Évitez la surintégration et laissez chaque module faire son propre travail.
Un exemple courant de développement OA est qu'il existe généralement de nombreuses approbations dans les systèmes d'entreprise, et de nombreuses personnes penseront immédiatement à intégrer les approbations dans un module universel. Cela ne pose aucun problème, mais le problème habituel est que trop de personnes placent le traitement métier après l'approbation dans la logique métier du module d'approbation. En fait, ce sont les modules métier de chaque module métier, et l'approbation doit uniquement être effectuée. être terminé une fois l'approbation terminée. Cependant, quant à ce qu'il faut faire une fois l'approbation terminée, laissez le module qui effectue ce processus le gérer lui-même.
5. Évitez d’être trop flexible
La conception et le code ne sont pas toujours aussi flexibles que possible. Un exemple courant est que lors de l'utilisation de génériques, des classes ou des méthodes peuvent fonctionner sur différents objets. Cependant, dans l'architecture à trois niveaux couramment utilisée en JAVA, si une série de classes est initialement destinée à fonctionner sur une entité spécifique, cela n'est pas nécessaire. pour le spécifier comme type générique, puis le spécifier pour utiliser une classe d'entité spécifique lors de son utilisation. Cela semble superflu.
6. Réduisez la cerise sur le gâteau
L'absence d'actualisation de la page, les effets d'affichage plus froids, etc. sont tous la cerise sur le gâteau pour le système d'entreprise. Si l'interface métier est très compliquée à cause de cela, cela entraînera une série de problèmes dans le traitement métier. Aussi belle que soit l’interface, elle ne sert à rien lorsque vous continuez. Lorsqu'il s'agit d'un conseil, ne tenez compte des autres que si vous voulez vous assurer que le processus métier se déroule correctement. Une condition préalable à cela est une communication nécessaire avec les utilisateurs. En d'autres termes, les projets mis en œuvre par JAVA se concentrent sur le traitement métier. Ce n'est que lorsque le traitement métier est bien réalisé que la beauté de l'interface et le sens visuel de l'utilisateur peuvent être pris en compte.
7. Divisez de manière appropriée
C'est similaire à 4. Essayez de réduire au maximum la complexité de chaque module et de convertir le travail mental en travail physique. Un exemple courant est qu'un formulaire a généralement les fonctions d'ajout, de modification, de suppression et d'affichage. Cependant, les trois premières opérations ne sont généralement effectuées que par des personnes à un certain point de fonction, dans un état spécifique et avec des autorisations spécifiques (peut-être uniquement dans la seule interface du système). Cependant, les opérations de visualisation seront réparties dans tous les coins du projet. Si ces quatre opérations sont placées dans la même interface, même si le nombre d'interfaces peut être réduit, ce qui augmentera, c'est la complexité de cette interface. traitées. Faites les jugements nécessaires pour définir les paramètres en lecture seule pour les éléments d'interface. L'augmentation de la complexité est exponentielle, et si vous divisez la vue, la charge de travail sera linéaire. Même si vous devez créer 10 interfaces de vue, la complexité sera. plus élevé que le précédent, il est beaucoup plus facile de le transformer en 10*10, et il peut également être composant.
8. Maintenir une bonne communication avec les clients
De nombreuses personnes ne prêtent pas attention au maintien de la communication avec les clients. De nombreux architectes pensent que la communication avec les clients n'est nécessaire que pendant la phase de demande du projet. C'est une très mauvaise habitude, car les exigences des clients changeront avec le temps. dans l'environnement. Ce n'est qu'en maintenant une bonne communication avec les clients sur une base régulière que nous pouvons comprendre les changements dans les besoins des clients le plus rapidement possible, ajustant ainsi notre plan de structure de projet pour répondre aux besoins des clients dans les plus brefs délais.
9. La connexion entre l'architecture du projet et l'architecture de la base de données
Beaucoup de gens pensent qu'une base de données n'est pas nécessaire lors du développement d'un projet, tant qu'elle est implémentée en mémoire. Personnellement, je pense que c'est une très mauvaise habitude de développement. Bien que la base de données soit déterminée en fonction des besoins spécifiques du projet. Cependant, si un projet ne prend pas du tout en compte l'architecture de la base de données pendant le processus d'architecture, il est probable que les éléments implémentés dans le projet seront difficiles à enregistrer dans la base de données ou que la conception de la base de données sera très problématique, ce qui augmentera virtuellement le difficulté de développement du projet. De plus, ne pas prendre en compte la base de données pendant le processus de développement du projet peut entraîner des problèmes tels que l'échec de la mise en œuvre d'une certaine logique métier, la perte de données, etc. une fois le projet lié à la base de données.
Bien sûr, de nombreuses personnes ont des opinions architecturales différentes en fonction de leurs différents styles architecturaux, et mon opinion n'est peut-être pas correcte. J'espère que tout le monde pourra apprendre quelque chose de mon travail, et j'espère également que tout le monde pourra partager son point de vue sur l'architecture.