[JAVA] Refactoring d'applications monosiliques

L'application développée en interne est ["Big Mud Dumpling"](https://ja.wikipedia.org/wiki/%E5%A4%A7%E3%81%8D%E3%81%AA%E6%B3 % A5% E3% 81% A0% E3% 82% 93% E3% 81% 94) J'ai été confronté à un problème que l'efficacité du développement ne s'est pas améliorée. J'ai donc décidé de refactoriser. Tout en étudiant des livres tels que "Clean Architecture", "Micro Service Architecture" et "Refactoring", il refactore. Je ne l'ai pas encore terminé, mais je vais résumer ce à quoi j'ai pensé lors de la refactorisation.

Organiser l'état actuel des applications monociles

J'ai essayé d'organiser l'état de l'application avant de refactoriser. J'ai les problèmes suivants.

• Gestion par lots de plusieurs sous-systèmes et composants dans un référentiel git (le montant du code source est d'environ 700000 lignes) --C'est le problème majeur. Avec cette configuration, même si le développement de la fonction est fermé à certains sous-systèmes, vous finirez par construire et tester tous les modules avec CI.
• Une base de données est partagée par tous les sous-systèmes
• De légères modifications apportées aux tables de base de données peuvent affecter tous les sous-systèmes. ――Il faut du temps pour déterminer quelle table doit être modifiée pour atteindre ce que vous voulez réaliser dans le développement de fonctions.
• Le test automatique est trop étroitement associé à des fonctionnalités autres que celle que vous souhaitez vérifier
• Le code de test dépend des détails du module inférieur. Le test étant implémenté dans une position comme un test d'intégration, divers tests peuvent être réalisés en modifiant le code produit du module inférieur.
• Il existe également un test qui charge les données de base de données et les coûts de maintenance sont élevés. ――Il faut environ 2 heures pour construire et tester avec un CI
• La raison principale est qu'il n'y a qu'un seul référentiel git et que le code de test unitaire est implémenté dans une position comme un test d'intégration. L'inconvénient d'entraver l'agilité du développement l'emporte sur le mérite de l'assurance qualité par des tests automatiques.
• Le module inférieur contient trop de détails --Parce que le module inférieur contient des détails, le module inférieur sera fréquemment mis à jour lors du développement des fonctions. De plus, le module supérieur dépend des détails car les détails existent dans le module inférieur. Par conséquent, il ne peut pas être fermé au correctif.

Refactoriser le problème

• Gestion par lots de plusieurs sous-systèmes et composants dans un référentiel git

• Actuellement, plusieurs projets maven divisés par «unité fonctionnelle» sont stockés dans un référentiel git, mais selon le principe de responsabilité unique Séparez et divisez en un autre référentiel.

• Une base de données est partagée par tous les sous-systèmes

• En partageant la base de données, une table est remplie d'intérêts multiples. Par conséquent, le nombre de colonnes dans le tableau est inévitablement énorme. Celui-ci est divisé en un tableau dans lequel seules les colonnes nécessaires sont extraites pour chaque sous-système, et le schéma est divisé pour chaque sous-système.

• Le test automatique est trop étroitement associé à des fonctionnalités autres que celle que vous souhaitez vérifier --Comprendre les spécifications externes du code de test existant et refactoriser l'implémentation existante tout en écrivant le code de test sous une forme qui dépend de l'abstraction du module inférieur.

――Il faut environ 2 heures pour construire et tester avec un CI

• Résolu en refactorisant la gestion centralisée du référentiel git et en couplant étroitement le code de test unitaire et l'implémentation

• Le module inférieur contient trop de détails

• [Principe de l'inversion des dépendances](https://ja.wikipedia.org/wiki/%E4%BE%9D%E5%AD%98%E6%80%A7%E9%80%86%E8%BB% Refactorisé pour appliquer A2% E3% 81% AE% E5% 8E% 9F% E5% 89% 87). Les modules inférieurs visent essentiellement à se composer uniquement de classes abstraites et d'interfaces.

Effet estimé du refactoring

• Gestion par lots de plusieurs sous-systèmes et composants dans un référentiel git

• En supposant que la plage de test de construction pour les modifications du code source est d'environ la moitié, le temps de test de construction est simplement divisé par deux. En supposant un temps de test de construction existant de 2 heures et un IC quotidien moyen de 5 fois, `5 (builds) x 2 x 0,5 (temps réduit par refactoring) x 20 (jours ouvrables) = 100 heures / mois de réduction des coûts par développeur.

• Une base de données est partagée par tous les sous-systèmes --Confirmation de l'absence d'impact sur le développement des fonctions impliquant des changements de DB. ・ Il est supposé que le temps nécessaire pour enquêter sur les changements de DB est de 16 heures (2 jours-homme), ce qui sera 2 heures après la division de DB. En supposant que le développement de fonction avec changement de base de données se produit 3 fois par mois, 3 (nombre d'occurrences de développement de fonction) x 14 (temps réduit par refactoring) = 42 heures / mois de réduction des coûts par développeur Vous pouvez vous y attendre.

• Le test automatique est trop étroitement associé à des fonctionnalités autres que celle que vous souhaitez vérifier

• En supposant qu'il faut 5 heures pour modifier le test automatisé, soit 1 heure après la refactorisation. En supposant que la possibilité de modifier le test automatisé se produit 5 fois par mois, 5 (nombre d'occurrences de développement de fonctions) x 4 (temps réduit par refactorisation) = 20 heures / mois de réduction des coûts par développeur Vous pouvez vous y attendre.

• Le module inférieur contient trop de détails

• Cela affecte la fréquence de mise à jour des modules inférieurs. Si les modules inférieurs sont composés uniquement d'abstraction, il est possible d'éviter la situation de construction de tous les modules supérieurs. Supposons que le module inférieur soit mis à jour 10 fois par mois et qu'après refactorisation, il le sera une fois par mois. En supposant un temps de test de construction du code source de 2 heures, 2 (temps de test de construction) x 9 (fréquence de mise à jour réduite par refactoring) = 18 heures / mois de réduction des coûts par développeur Peut être attendu.

Que peut-on considérer à partir de l'estimation

Aucune des estimations ci-dessus n'est exacte. Une telle estimation ne peut pas être faite avec précision au départ. Cependant, il est nécessaire de transmettre les mérites de cette refactorisation et de penser à obtenir l'autorisation d'effectuer la refactorisation auprès des supérieurs. Et surtout, ** les coûts qui peuvent être réduits par le refactoring calculé ci-dessus continueront d'être payés pour toujours à moins que le refactoring ne soit effectué, et les coûts continueront d'augmenter. ** **

Le coût qui peut être réduit par le refactoring est estimé, mais c'est la raison pour laquelle le coût du refactoring n'est pas estimé. Les coûts qui peuvent être réduits par la refactorisation ne peuvent être réduits que par la refactorisation. Cela signifie que si le coût de la refactorisation n'est pas une valeur irréaliste (comme 100 mois-homme), je pense que cela devrait être fait. Bien que le coût continue d'augmenter, il semble absurde d'affirmer que si le coût de la refactorisation est de 2 hommes-mois, cela sera fait, et s'il s'agit de 3 hommes-mois, cela ne sera pas fait.

Ce que j'ai ressenti après la refactorisation

――Vous pouvez acquérir les connaissances et l'expérience dont vous avez besoin en tant qu'architecte à haute densité. ―― «Un bon architecte peut retarder au maximum la politique de prise de décision de mise en œuvre» Clean Architecture ? _encoding = UTF8 & btkr = 1) est mentionné. Pour réaliser cela, il s'agit de refactoriser de penser et d'appliquer les ** nécessaires "contrôle des dépendances", "gestion des modules" et "degré de couplage" **. Et vous pouvez ressentir l'effet par vous-même.

――Vous pouvez devenir un ingénieur requis sur le terrain

• Le logiciel continue de changer. Parce que les exigences des entreprises continuent d'évoluer. En conséquence, il y a beaucoup plus de situations dans lesquelles les applications existantes sont étendues que dans des situations où la capacité de créer des applications à partir de zéro est démontrée. Par conséquent, les ingénieurs capables d'améliorer l'efficacité du développement et de réduire les coûts de maintenance sans détruire les applications déjà en cours d'exécution sont indispensables sur tous les marchés. Les compétences requises de ces ingénieurs peuvent être obtenues grâce à la refactorisation.

Matériaux auxquels il est fait référence lors de la refactorisation

• Architecture propre
• Architecture des microservices
• [Refactoring de la base de données](https://www.amazon.co.jp/%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3 % 82% B9% E3% 83% BB% E3% 83% AA% E3% 83% 95% E3% 82% A1% E3% 82% AF% E3% 82% BF% E3% 83% AA% E3% 83 % B3% E3% 82% B0-% E3% 82% B9% E3% 82% B3% E3% 83% 83% E3% 83% 88-W-% E3% 82% A2% E3% 83% B3% E3 % 83% 96% E3% 83% A9% E3% 83% BC / dp / 4894715007 / ref = cm_cr_arp_d_product_top? Ie = UTF8)
• [Refactoring](https://www.amazon.co.jp/%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3% 83% AA% E3% 83% B3% E3% 82% B0% E2% 80% 95% E6% 97% A2% E5% AD% 98% E3% 81% AE% E3% 82% B3% E3% 83% BC% E3% 83% 89% E3% 82% 92% E5% AE% 89% E5% 85% A8% E3% 81% AB% E6% 94% B9% E5% 96% 84% E3% 81% 99% E3% 82% 8B% E2% 80% 95-OBJECT-TECHNOLOGY-Martin-Fowler / dp / 427405019X / ref = sr_1_1? S = books & ie = UTF8 & qid = 1553615256 & sr = 1-1 & keywords =% E3% 83% AA% E3% 83 % 95% E3% 82% A1% E3% 82% AF% E3% 82% BF% E3% 83% AA% E3% 83% B3% E3% 82% B0)