Читать книгу Mikroserwisy. Wzorce z przykładami w języku Java - Chris Richardson - Страница 16

Głównym problemem związanym z aplikacją FTGO jest to, że jest zbyt skomplikowana. Jest za duża, aby mógł ją w pełni zrozumieć jakikolwiek programista. W rezultacie naprawianie błędów i prawidłowe wdrażanie nowych funkcjonalności stało się trudne i czasochłonne. Przekraczane są terminy.

Rysunek 1.2. Przypadek monolitycznego piekła. Duży zespół programistów FTGO dokonuje zmian w jednym repozytorium kodów źródłowych. Ścieżka od zatwierdzenia kodu do produkcji jest długa i uciążliwa oraz wymaga ręcznego testowania. Aplikacja FTGO jest duża, złożona, zawodna i trudna w utrzymaniu

Co gorsza, ta wzrastająca złożoność jest zwykle spiralą spadkową. Jeśli kod jest trudny do zrozumienia, programista może nie wprowadzić poprawnych zmian. Każda zmiana powoduje, że kod jest coraz bardziej złożony i trudniejszy do zrozumienia. Czysta, modułowa architektura pokazana wcześniej na rysunku 1.1 nie odzwierciedla rzeczywistości. FTGO stopniowo staje się potworną, niezrozumiałą, wielką kulą błota.

Mary pamięta, że niedawno uczestniczyła w pewnej konferencji. Spotkała na niej programistę, który pisał narzędzie do analizy zależności między tysiącami plików JAR w ich aplikacji składającej się z wielu milionów linii kodu. W tym czasie narzędzie to wydawało się być czymś, co FTGO mogłoby wykorzystać. Teraz już nie jest tego taka pewna. Mary sądzi, że lepszym podejściem jest migracja do architektury, która lepiej jest dostosowana do złożonej aplikacji: mikrousługi.