| Tytuł: | Pragmatyczna refaktoryzacja z użyciem technik Domain Driven Design |
| Kod: | Craft-refactor |
| Kategoria: | Wzorce i Craftsmanship |
| Forma: | 50% wykłady / 50% warsztaty |
| Czas trwania: | 3 dni |
| Odbiorcy: | developerzy |
| Zapisy: |
Indywidualne zamówienie i dopasowanie dla grupy. |
| Logistyka: |
W siedzibie klienta lub w innym dowolnym miejscu. |
Przekształcenia “Extract Method”, “Replace If with Guardian” oraz “Extract Object” poprawiają czytelność kodu, ale nie ratują projektów, których bazowy model jest zły.
Jak w bezpieczny i pragmatyczny sposób dokonać refaktoryzacji, która przypomina wymianę silnika lecącego samolotu? Poniższy warsztat przedstawia szereg typowych problemów projektowych skategoryzowanych na bazie produkcyjnego, audytorskiego i konsultacyjnego doświadczenia z szeregu projektów z różnych dziedzin biznesowych.
Nie jest to kolejny warsztat, w którym krok po kroku przechodzimy po katalogu typowych “zapachów” kodu i sposobów ich eliminacji. Podczas zajęć analizujemy też architektoniczne problemy, których naprawa wykracza poza standardowe ramy refaktoryzacji, ale których bezpieczne wykonanie może owocować dostarczeniem wartości biznesowej bez 3-miesięcznego przestoju. Uczestnik zdobywa konkretną mapę nawigacyjną wraz z narzędziami pozwalającymi mu skutecznie identyfikować i eliminować wieloletnie problemy występujące w systemie. Wszystko to w sposób bezpieczny, poparty dobrymi praktykami inżynierskimi, Domain-Driven Design oraz możliwością odwrotu.
Na warsztacie uczestnik poznaje sposoby rozmowy z odbiorcami biznesowymi, którzy nie do końca są przekonani do podejścia refaktoryzacji. Zajęcia obfitują w konkretne metryki biznesowe, budujące wspólne zrozumienie pomiędzy zespołem deweloperskim, a interesariuszami biznesowymi.
Po warsztacie, uczestnik m. in. potrafi identyfikować i naprawiać problemy architektoniczne i implementacyjne wykorzystując podejście Domain-Driven Design, analizę historii repozytorium, analizę metryk i stabilności kodu, podejście Test-Driven Development, podejście obiektowe/funkcyjne, modularyzację i wiele innych.
Warsztat może się odbyć wersji od trzydniowej do pięciodniowej. Czwarty lub/i piąty dzień poświęcamy na analizę domenową nowego projektu, która służy jako klamra wiedzy stosowanej przez trzy pierwsze dni w systemie Legacy. Alternatywnie warsztat może odbyć się jako konsultacja na projekcie klienta.
Program Szkolenia
Program jest ramą w jakiej możemy się poruszać merytorycznie - program dla konkretnego szkolenia dedykowanego ustalamy z grupą na podstawie analizy przed-szkoleniowej.-
Typowe przypadki- Co zrobić z duża i nieestetyczną klasą?
- Co zrobić z dużą i estetyczną klasą?
- Jak naprawić odwieczny problem - brak spójności danych?
- Moja klasa/moduł ma bardzo dużo zależności i bardzo dużo logiki biznesowej, jak to podzielić?
- Bazowy model mojego modułu jest niedopasowany do potrzeb biznesu, co zrobić?
- Jak naprawić niewydajne i bardzo złożone odczyty danych?
- W moim projekcie brak jasno wydzielonych granic, jak to naprawić?
- Co zrobić z duża i nieestetyczną klasą?
-
Sprawdzona Ścieżka Refaktoryzacji- Odkrywanie i opisywanie problemu
- Drivery architektoniczne
- Drivery architektoniczne
- “Sprzedawanie” i marketing rozwiązań
- Odbiorca techniczny
- Egoless programming
- Egoless programming
- Odbiorca biznesowy
- Wektor nowej funkcji biznesowej
- Wektor nowej funkcji dla nowych klientów
- Wektor nowej funkcji dla jednego z nowych klientów
- Odwracanie zmian
- Wektor nowej funkcji biznesowej
- Odbiorca techniczny
- Lokalizacja prawdziwych problemów
- Zbieranie i interpretowanie metryk
- Wykrywanie punktów krytycznych
- Identyfikacja “zapachów”
- Kod stabilny vs kod zmieniany
- Analiza historii repozytorium
- Podejście Domain-Driven Design
- Zbieranie i interpretowanie metryk
- Planowanie zmian
- Efekt “Brzydkiego Kaczątka”
- Problem “You are never done”
- Efekt “Brzydkiego Kaczątka”
- Wprowadzanie zmian
- Refaktoryzacja mechaniczna/taktyczna
- Refaktoryzacja architektoniczna/strategiczna
- Refaktoryzacja mechaniczna/taktyczna
- Wdrażanie zmian
- Cykle i mikrocykle
- Cykle i mikrocykle
- Obserwacja efektów
- Bezpieczny odwrót
- Bezpieczny odwrót
- Odkrywanie i opisywanie problemu
-
Refaktoring ciągły- Wsparcie ze strony IDE
- Identyfikowanie szwów
- Wspólne zrozumienie i Edukacja
- Code Review
- ArchUnit i inne narzędzia
- Code Review
- Wspólne zrozumienie i Edukacja
- Konwencje jako driver architektoniczny
- Refaktoring bez znajomości problemu biznesowego
- Jak to robić bezpiecznie?
- Jak to robić bezpiecznie?
- Wsparcie ze strony IDE
-
Refaktoring przygotowujący- Nowe funkcje biznesowe
- Naprawa obecnych funkcji biznesowych
- Naprawa atrybutów jakościowych
- Budowanie zaufania
- Metryki biznesowe jako element marketingu refaktoryzacji
- Nowe funkcje biznesowe
-
Wdrażanie zmian- Testy
- Odkrywanie szwów
- Technika ułatwiania testów poprzez obniżanie szwów
- Testy charakterystyki systemu
- Testy i szwy jako odkrywanie granic modułów i uwalnianie potencjałów biznesowych
- Odkrywanie szwów
- Problem Big Bang Release
- Technika Step by Step
- Parallel Models jako jedyny sposób bezpiecznej strategicznej refaktoryzacji
- Bezpieczny odwrót
- Logi
- Zaawansowane metryki
- Samoleczący się system
- Możliwość codziennego budowanie zaufania do interesariusza projektowego
- Bezpieczny odwrót
- Testy
-
Wykorzystanie Domain-Driven Design- Hermetyzacja tego CO system powinien robić w serwisy aplikacyjne
- Hermetyzacja tego JAK i DLACZEGO system się tak zachowuje w Building Blocks DDD
- Praca nad słownictwem domenowym
- Zarządzanie wartością jest łatwiejsze niż encją
- Odkrywanie Value Objects, Agregatów oraz Polityk
- Polityki - hermetyzacja zmienności poza stabilnym interfejsem
- Rozwijalność i czytelność systemu poprzez trójpodział logiki
- Operations
- Policy
- Decision Support
- Operations
- Podejście funkcyjne
- Hermetyzacja złożoności w jednym miejscu
- Podejście "od domeny" zamiast podejścia "od procesu"
- Separacja modelu pod kątem podatności na zmiany i niestabilności
- Hermetyzacja tego CO system powinien robić w serwisy aplikacyjne
-
Wprowadzanie zmian- Poziomy modelu
- Zmiana API
- API publiczne vs API prywatne
- API publiczne vs API prywatne
- Coupling, Coupling Logiczny i Data Coupling
- Poziomy modelu
-
Modelowanie Domeny (tylko w wersji 4 dniowej)- Odkrywanie złożoności za pomocą Event Stormingu
- “As Is” vs “To Be”
- Analiza problematycznych miejsc
- Identyfikacja problematycznych miejsc w kodzie
- Odkrywanie słownictwa domenowego
- Destylacja archetypowych problemów
- Modularyzacja do Bounded Contextów
- Mapowanie do obecnego systemu
- Mapowanie do obecnego systemu
- Destylacja agregatów
- Mapowanie do obecnego systemu
- Mapowanie do obecnego systemu
- “As Is” vs “To Be”
- Odkrywanie złożoności za pomocą Event Stormingu
Pobierz program w formacie PDF
Trenerzy
Poznaj ekspertów, którzy mogą poprowadzić Twoje szkolenie.