Description
Przez długi czas uważano, że architektura oprogramowania powinna powstać przed rozpoczęciem pisania kodu i pozostać niezmieniona aż do zakończenia projektu. Pojawienie się zwinnych metod tworzenia oprogramowania spowodowało, że taką koncepcję zaczęto podawać w wątpliwość. Niektórzy nawet kwestionowali potrzebę tworzenia architektury, gdyż utrudniała reakcję na zmiany wymagań. Istnieje jednak inne podejście do architektury, zgodnie z którym jest ona ściśle powiązana z fazą programowania i dynamicznie odpowiada na zmiany pojawiające się podczas tworzenia kodu. W ten sposób architektura ewolucyjna, pomimo nieprzewidywalności zmian, zapewnia rozwój projektu we właściwym kierunku.Dzięki tej książce architekci oprogramowania zapoznają się z nowym podejściem do powiązań architektury z czasem. Przekonają się też, że tworzenie architektury ewolucyjnej sprowadza się do trzech głównych zagadnień: funkcji dopasowania, zmian przyrostowych i prawidłowego sprzęgania. W tej książce uwzględniono analizę każdego z tych aspektów, ukazano też mechanizm budowania architektury wspierającej ciągłe zmiany. Szczegółowo wyjaśniono zasady wprowadzania pętli informacji zwrotnej pozwalających całemu zespołowi na spójne rozwijanie systemu w zgodzie z zasadą ciągłego dostarczania. Pokazano metody monitorowania stanu architektury. Sporo uwagi poświęcono problemom danych długowiecznych – jest to często pomijane zagadnienie.W tej książce:Funkcje dopasowania w architekturzeZmiany przyrostowe wprowadzane za pomocą projektowania i operacjiSprzężenie architektury i wprowadzanie zmian bez utraty stabilności systemuDane ewolucyjne oraz zmiany wymogów i architektury w miarę upływu czasuBudowanie architektur ewolucyjnychPraktyczne wdrażanie architektury ewolucyjnej w korporacjiArchitektura korporacyjna: wysoka sztuka projektowania!Spis treści:WstępWstęp (9)Wprowadzenie (11)1. Architektura oprogramowania (15)Architektura ewolucyjna (17)W jaki sposób możemy planować długoterminowo, skoro wszystko wokół zmienia się przez cały czas? (17)W jaki sposób możemy po stworzeniu architektury zabezpieczyć ją przed stopniową degradacją? (21)Zmiana przyrostowa (22)Zmiana kierowana (23)Wielowymiarowość architektury (24)Prawo Conwaya (27)Dlaczego „ewolucyjna”? (31)Podsumowanie (31)2. Funkcje dopasowania (33)Czym jest funkcja dopasowania? (35)Kategorie (38)Atomowe/holistyczne (38)Wywoływane/ciągłe (39)Statyczne/dynamiczne (39)Zautomatyzowane/ręczne (40)Czasowe (41)Zamierzone/wyłaniające się (41)Wyspecjalizowane (41)Wczesne rozpoznawanie funkcji dopasowania (42)Przegląd funkcji dopasowania (44)3. Projektowanie zmian przyrostowych (47)Elementy budulcowe (51)Testowalność (53)Potoki wdrażania (54)Kombinacje poszczególnych kategorii funkcji dopasowania (59)Analiza przypadku: Restrukturyzowanie architektury za pomocą 60 wdrożeń dziennie (61)Sprzeczne cele (64)Analiza przypadku: Dodawanie funkcji dopasowania do usługi fakturowania w firmie Nie Najgorsze Patenty (65)Projektowanie zorientowane na hipotezy i dane (68)Analiza przypadku: Co przenosić? (70)4. Sprzężenie architektury (73)Modułowość (73)Kwanty architektury i ziarnistość (74)Ewoluowalność stylów architektury (78)Bryła błotna (79)Monolity (80)Architektury sterowane zdarzeniami (89)Architektury zorientowane na usługi (95)Architektury „bezserwerowe” (110)Kontrolowanie rozmiaru kwantu (112)Analiza przypadku: Zabezpieczanie przed cyklicznymi zależnościami pomiędzy składnikami (113)5. Dane ewolucyjne (117)Projektowanie ewolucyjnej bazy danych (117)Ewoluowanie schematów (118)Integracja współdzielonych baz danych (120)Nieprawidłowe sprzęganie danych (125)Zatwierdzanie dwufazowe transakcji (125)Wiek i jakość danych (128)Analiza przypadku: Ewolucja trasowania w firmie Nie Najgorsze Patenty (130)6. Tworzenie ewoluowalnych architektur (133)Mechanika (133)1. Identyfikacja wymiarów podlegających ewolucji (134)2. Definiowanie funkcji dopasowania dla każdego wymiaru (134)3. Stosowanie potoku wdrażania do automatyzacji funkcji dopasowania (134)Nowe projekty (135)Modernizowanie istniejących architektur (136)Prawidłowe sprzęganie i spójność (136)Praktyki inżynieryjne (137)Funkcje dopasowania (137)Skutki stosowania modelu COTS (138)Migrowanie architektur (140)Etapy migracji (141)Ewoluowanie oddziaływań pomiędzy modułami (144)Wskazówki dotyczące tworzenia architektur ewolucyjnych (148)Usuń niepotrzebną zmienność (148)Zagwarantuj odwracalność decyzji (150)Przedkładaj ewoluowalność nad przewidywalność (152)Twórz warstwy przeciwdegradacyjne (153)Analiza przypadku: Szablony usług (156)Tworzenie architektur ofiarniczych (157)Minimalizuj wpływ zmian zewnętrznych (159)Aktualizowanie bibliotek i szkieletów (161)Preferuj dostarczanie ciągłe do migawek (162)Wersjonuj usługi wewnętrznie (164)Analiza przypadku: Ewoluowanie systemu oceniania w firmie Nie Najgorsze Patenty (165)7. Pułapki i antywzorce architektury ewolucyjnej (169)Architektura techniczna (169)Antywzorzec: Monopolista (169)Pułapka: Nieszczelne abstrakcje (171)Antywzorzec: Pułapka ostatnich 10% (174)Antywzorzec: Nadużywanie wielokrotnego wykorzystywania kodu (175)Analiza przypadku: Wieloużywalność w firmie Nie Najgorsze Patenty (178)Pułapka: Projektowanie zorientowane na CV (179)Zmiany przyrostowe (180)Antywzór: Nieprawidłowe zarządzanie (180)Analiza przypadku: Zarządzanie wyważone w firmie Nie Najgorsze Patenty (183)Pułapka: Brak szybkości wydawania (183)Kwestie biznesowe (185)Pułapka: Dostosowywanie produktu (186)Antywzorzec: Raportowanie (187)Pułapka: Horyzonty planowania (189)8. Stosowanie architektury ewolucyjnej w praktyce (191)Czynniki organizacyjne (191)Zespoły przekrojowe (191)Zorganizowane wokół umiejętności biznesowych (193)Produkt ponad projekt (194)Radzenie sobie ze zmianami zewnętrznymi (196)Związki pomiędzy członkami zespołu (198)Parametry sprzęgania zespołów (199)Kultura (199)Kultura eksperymentowania (201)Dyrektor finansowy i przygotowywanie budżetu (203)Tworzenie korporacyjnych funkcji dopasowania (205)Analiza przypadku: Firma Nie Najgorsze Patenty jako platforma (206)Od czego zacząć? (206)Łatwo osiągalny cel (207)Największa wartość (207)Testowanie (208)Infrastruktura (208)Analiza przypadku: Architektura korporacyjna w firmie Nie Najgorsze Patenty (209)Stan przyszły? (211)Funkcje dopasowania wykorzystujące sztuczną inteligencję (211)Testowanie generatywne (212)Dlaczego (lub dlaczego nie)? (212)Dlaczego firma powinna zdecydować o tworzeniu architektury ewolucyjnej? (212)Analiza przypadku: Skala wybiórcza w firmie Nie Najgorsze Patenty (215)Dlaczego firma miałaby rezygnować z tworzenia architektury ewolucyjnej? (217)Przekonywanie innych (219)Analiza przypadku: Judo doradcze (219)Kwestia biznesowa (220)”Przyszłość jest teraz…” (220)Szybkie zmiany bez psucia architektury (220)Mniejsze ryzyko (221)Nowe możliwości (221)Budowanie architektur ewolucyjnych (221)Skorowidz (223)
list motywacyjny wstęp, facebook, odpowiedzi matura 2021 angielski podstawowy, arcymistrz szachy, outlook szablon
yyyyy
