[JAVA] Refactoring von monosilic-Anwendungen

Die intern entwickelte Anwendung ist "Big Mud Dumpling" % A5% E3% 81% A0% E3% 82% 93% E3% 81% 94) Ich hatte das Problem, dass sich die Entwicklungseffizienz nicht verbesserte. Also habe ich beschlossen, umzugestalten. Während er Bücher wie "Clean Architecture", "Micro Service Architecture" und "Refactoring" studiert, gestaltet er Refactoring. Ich habe es noch nicht abgeschlossen, aber ich werde zusammenfassen, woran ich beim Refactoring gedacht habe.

Organisieren Sie den aktuellen Status monokiler Anwendungen

Ich habe versucht, den Status der Anwendung vor dem Refactoring zu organisieren. Ich habe folgende Probleme.

• Stapelverwaltung mehrerer Subsysteme und Komponenten in einem Git-Repository (Quellcode-Menge ca. 700.000 Zeilen) ――Dies ist das Hauptproblem. Selbst wenn die Funktionsentwicklung für einige Subsysteme geschlossen ist, werden mit dieser Konfiguration alle Module mit CI erstellt und getestet.
• Eine Datenbank wird von allen Subsystemen gemeinsam genutzt
• Leichte Änderungen an DB-Tabellen können sich auf alle Subsysteme auswirken. ――Es braucht Zeit, um zu untersuchen, welche Tabelle geändert werden sollte, um das zu erreichen, was Sie bei der Funktionsentwicklung erreichen möchten.
• Der automatische Test ist zu eng mit anderen als den zu überprüfenden Funktionen verbunden
• Der Testcode hängt von den Details des unteren Moduls ab. Da der Test in einer Position wie einem Integrationstest durchgeführt wird, können verschiedene Tests durchgeführt werden, indem der Produktcode des unteren Moduls geändert wird.
• Es gibt auch einen Test zum Laden von DB-Daten, und die Wartungskosten sind hoch. ――Das Erstellen und Testen mit einem CI dauert ca. 2 Stunden
• Der Hauptgrund ist, dass es nur ein Git-Repository gibt und der Unit-Test-Code an einer Position wie einem Integrationstest implementiert ist. Der Nachteil, die Agilität der Entwicklung zu behindern, überwiegt den Wert der Qualitätssicherung durch automatische Tests.
• Das untere Modul enthält zu viele Details
• Da das untere Modul Details enthält, wird das untere Modul in der Funktionsentwicklung häufig aktualisiert. Darüber hinaus hängt das obere Modul von den Details ab, da die Details im unteren Modul vorhanden sind. Infolgedessen kann es nicht für den Fix geschlossen werden.

Refactoring zum Problem

• Stapelverwaltung mehrerer Subsysteme und Komponenten in einem Git-Repository

• Gegenwärtig werden mehrere Maven-Projekte, die durch "Funktionseinheiten" unterteilt sind, in einem Git-Repository gespeichert, jedoch gemäß dem Prinzip der Einzelverantwortung. Trennen und teilen Sie es in ein anderes Repository.

• Eine Datenbank wird von allen Subsystemen gemeinsam genutzt

• Durch die gemeinsame Nutzung der Datenbank wird eine Tabelle mit mehreren Interessen gefüllt. Daher ist die Anzahl der Spalten in der Tabelle zwangsläufig sehr groß. Dies ist in eine Tabelle unterteilt, in der nur die erforderlichen Spalten für jedes Subsystem extrahiert werden, und das Schema wird für jedes Subsystem aufgeteilt.

• Der automatische Test ist zu eng mit anderen als den zu überprüfenden Funktionen verbunden

• Verstehen Sie die externen Spezifikationen des vorhandenen Testcodes und überarbeiten Sie die vorhandene Implementierung, während Sie den Testcode in einer Form schreiben, die von der Abstraktion des unteren Moduls abhängt.

――Das Erstellen und Testen mit einem CI dauert ca. 2 Stunden

• Durch Refactoring der zentralen Verwaltung des Git-Repositorys und der engen Kopplung zwischen Unit-Test-Code und Implementierung behoben

• Das untere Modul enthält zu viele Details

• [Prinzip der Abhängigkeitsumkehr](https://ja.wikipedia.org/wiki/%E4%BE%9D%E5%AD%98%E6%80%A7%E9%80%86%E8%BB% Überarbeitet, um A2% E3% 81% AE% E5% 8E% 9F% E5% 89% 87 anzuwenden). Die unteren Module sollen grundsätzlich nur aus abstrakten Klassen und Schnittstellen bestehen.

Geschätzter Effekt des Refactorings

• Stapelverwaltung mehrerer Subsysteme und Komponenten in einem Git-Repository

• Unter der Annahme, dass der Build-Testbereich für Quellcodeänderungen etwa die Hälfte beträgt, wird die Build-Testzeit einfach halbiert. Unter der Annahme einer vorhandenen Build-Testzeit von 2 Stunden und eines durchschnittlichen täglichen CI von 5-mal, `5 (Builds) x 2 x 0,5 (durch Refactoring reduzierte Zeit) x 20 (Werktage) = 100 Stunden / Monat Kostensenkung pro Entwickler ist zu erwarten.

• Eine Datenbank wird von allen Subsystemen gemeinsam genutzt

• Bestätigung, dass keine Auswirkungen auf die Funktionsentwicklung bei DB-Änderungen vorliegen ・ Es wird davon ausgegangen, dass die für die Untersuchung von DB-Änderungen erforderliche Zeit 16 Stunden (2 Manntage) beträgt, dh 2 Stunden nach der DB-Teilung. Unter der Annahme, dass die Funktionsentwicklung mit DB-Änderung dreimal im Monat erfolgt, ist "3 (Anzahl der Funktionsentwicklungsereignisse) x 14 (durch Refactoring reduzierte Zeit) = 42 Stunden / Monat" Kostenreduzierung pro Entwickler Sie können es erwarten.

• Der automatische Test ist zu eng mit anderen als den zu überprüfenden Funktionen verbunden

• Angenommen, es dauert 5 Stunden, um den automatisierten Test zu ändern, dh 1 Stunde nach dem Refactoring. Unter der Annahme, dass die Möglichkeit zur Änderung des automatisierten Tests fünfmal im Monat besteht, ist "5 (Anzahl der Funktionsentwicklungsereignisse) x 4 (durch Refactoring reduzierte Zeit) = 20 Stunden / Monat" Kostenreduzierung pro Entwickler Sie können es erwarten.

• Das untere Modul enthält zu viele Details

• Dies wirkt sich auf die Aktualisierungshäufigkeit niedrigerer Module aus. Wenn die unteren Module nur aus Abstraktion bestehen, kann vermieden werden, dass alle oberen Module erstellt werden. Angenommen, das untere Modul wird zehnmal im Monat aktualisiert und nach dem Refactoring einmal im Monat. Unter der Annahme einer Quellcode-Build-Testzeit von 2 Stunden beträgt "2 (Build-Testzeit) x 9 (Aktualisierungshäufigkeit durch Refactoring reduziert) = 18 Stunden / Monat" Kostenreduzierung pro Entwickler Kann erwartet werden.

Was kann aus der Schätzung berücksichtigt werden

Keine der obigen Schätzungen ist korrekt. Eine solche Schätzung kann überhaupt nicht genau vorgenommen werden. Es ist jedoch notwendig, die Vorzüge der Durchführung dieses Refactorings zu vermitteln und darüber nachzudenken, von Vorgesetzten die Erlaubnis zur Durchführung des Refactorings zu erhalten. Und vor allem ** werden die Kosten, die durch das oben berechnete Refactoring gesenkt werden können, für immer bezahlt, sofern kein Refactoring durchgeführt wird, und die Kosten werden weiter steigen. ** **.

Die Kosten, die durch Refactoring gesenkt werden können, werden geschätzt. Dies ist jedoch der Grund, warum die Kosten für Refactoring nicht geschätzt werden. Kosten, die durch Refactoring reduziert werden können, können nur durch Refactoring reduziert werden. Wenn die Kosten für das Refactoring kein unrealistischer Wert sind (z. B. 100 Mannmonate), sollte dies meines Erachtens auch dann erfolgen, wenn dies nicht der Fall ist. Obwohl die Kosten weiter steigen werden, erscheint es unsinnig zu argumentieren, dass wenn die Kosten für das Refactoring 2 Mannmonate betragen, dies getan wird und wenn es 3 Mannmonate sind, wird es nicht getan.

Was ich nach dem Refactoring gefühlt habe

――Sie können das Wissen und die Erfahrung, die Sie als Architekt benötigen, in hoher Dichte erwerben. ―― „Ein guter Architekt kann die Entscheidungspolitik der Implementierung so weit wie möglich verzögern.“ Saubere Architektur _encoding = UTF8 & btkr = 1) wird erwähnt. Um dies zu realisieren, muss beim Refactoring die erforderliche ** "Abhängigkeitskontrolle", "Modulverwaltung" und "Kopplungsgrad" ** überlegt und angewendet werden. Und Sie können den Effekt selbst erleben.

――Sie können zu einem Ingenieur heranwachsen, der vor Ort benötigt wird

• Die Software ändert sich weiter. Weil sich die geschäftlichen Anforderungen weiter ändern. Infolgedessen gibt es überwiegend mehr Situationen, in denen vorhandene Anwendungen erweitert werden, als in Situationen, in denen die Fähigkeit zum Erstellen von Anwendungen von Grund auf demonstriert wird. Daher sind Ingenieure, die die Entwicklungseffizienz verbessern und die Wartungskosten senken können, ohne bereits laufende Anwendungen zu zerstören, in jedem Markt unverzichtbar. Die von solchen Ingenieuren geforderten Fähigkeiten können durch Refactoring erworben werden.

Materialien, auf die beim Refactoring Bezug genommen wird

• Saubere Architektur
• Microservice Architecture
• [Datenbank-Refactoring](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? Dh = 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-OBJEKT-TECHNOLOGIE-Martin-Fowler / dp / 427405019X / ref = sr_1_1? S = Bücher & dh = UTF8 & qid = 1553615256 & sr = 1-1 & Schlüsselwörter =% E3% 83% AA% E3% 83 % 95% E3% 82% A1% E3% 82% AF% E3% 82% BF% E3% 83% AA% E3% 83% B3% E3% 82% B0)