Tytuł: | Pragmatyczna refaktoryzacja z użyciem technik Domain Driven Design i archetypów modeli |
Kod: | refactor-DDD-arch |
Kategoria: | Wzorce i Craftsmanship |
Forma: | 50% wykłady / 50% warsztaty |
Czas trwania: | 4 dni |
Odbiorcy: | architekci, 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ę kluczowej części systemu? 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. Zdobywasz konkretną mapę nawigacyjną wraz z narzędziami pozwalającymi 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.
Podczas warsztatu poznasz także sposoby rozmowy z odbiorcami biznesowymi, którzy nie do końca są przekonani do podejścia refaktoryzacji. Pokażemy Ci konkretne metryki biznesowe, budujące wspólne zrozumienie pomiędzy zespołem deweloperskim, a interesariuszami biznesowymi.
Po warsztacie będziesz potrafić identyfikować i naprawiać problemy architektoniczne i implementacyjne wykorzystując podejście Domain-Driven Design, analizować historię repozytorium, metryki i stabilność kodu, także w kontekście podejścia Test-Driven Development, programowania obiektowego/funkcyjnego, modularyzacji i wielu innych.
Trzeciego dnia poznasz wachlarz gotowych modeli biznesowych, do których możesz dążyć/inspirować się podczas refaktoryzacji. Są to sprawdzone, generyczne modele, które upraszczają kod i otwierają go na rozbudowę. Poznasz również techniki, które pozwolą wzbogacać generyczne modele o specyfikę twojego projektu.
Poznaj ekspertów, którzy mogą poprowadzić Twoje szkolenie.
Idea renesansowej pracowni - Bottegi zakłada nieustanną pracę jej członków i dzielenie się jej wynikami.
Artykuł poświęcony technikom odwracania kontroli w ujęciu: problem, idea, motywacja, zastosowanie, technika, kiedy nie stosować.
Artykuł przedstawiający metodę doboru zaślepek (Mock/Stub) dla testów jednostkowych na podstawie paradygmatu CQS.
W jaki sposób dokumentować architekturę systemu? Z jednej strony tak, aby zawrzeć wszystkie potrzebne informacje, z drugiej zaś, aby nie przeładować dokumentacji szczegółami, które czynią ją bezużyteczną.
Artykuł przedstawia meta-model, którym możemy posiłkować się w zmaganiach ze złożoną logiką biznesową. Meta-model będzie praktyczną realizacją drugiej zasady SOLID: Open/closed principle, która pozwala tworzyć rozwiązania otwarte na rozbudowę (rozbudowa to nie to samo co zmiana).
Stosując mapery relacyjno-obiektowe, zwykle nie zastanawiamy się nad problemami związanymi z niespójnością danych wynikającą ze stosowania Lazy Loadingu, granicą spójności obiektów podczas zapisu kaskadowego oraz pułapkami naiwnego blokowania optymistycznego.
Artykuł przedstawia koncepcję Wzorców analitycznych – adresujących rozwiązania na poziomie analizy systemowej. Ilustracją na przykładów jest kilka wybranych, w tym najbardziej popularnym z nich: Party – będą one również alternatywą dla typowych naiwnych książkowych modeli struktur organizacyjnych.
Wiele czasu i energii spędzamy na dyskusjach o wyższości jednego paradygmatu programowania nad innym, o wyższości jednego języka programowania nad innym. W niniejszym artykule chcę przekonać czytelników do tego, aby obok siebie, równorzędnie stosować zarówno paradygmat obiektowy, jak i funkcyjny oraz nie zapominać o proceduralnym.
Do czego może przydać mi się propagacja transakcji inna niż REQUIRED? Jak zachowa się wówczas EnityManager i cache pierwszego poziomu? Jak uniknąć zakleszczeń? Dlaczego moje transakcje tylko-do-odczytu nie są tylko do odczytu? Kiedy oddać sterowanie transakcjami klientom zamiast obsługiwać je aspektowo? Jakie anomalie w spójności danych mi zagrażają?
Artykuł poświęcony technikom utrzymywania testów w długiej perspektywie czasu.
Techniki, które profesjonalny programista powinien mieć w swojej „skrzynce z narzędziami”, czyli m.in. Test Data Builder i Assert Object.
Prezentacja Łukasza Szydło na temat architektury wspierającej Continuous Delivery. Materiały z konferencji 4Developers 2014
Problemy i ich rozwiązania w zakresie: Lazy Loading, Optimistic Locking, generowanie ID, poziomy izolacji transakcji.
Techniki zwiększania czytelności kodu.
W 1970 roku John Conway publikował koncept prostego automatu komórkowego, Game of Life. Dziś, po 37 latach, tych kilka regułek rządzących rozwojem świata komórek jest idealnym przykładem do nauki programowania obiektowego, funkcyjnego, wzorców, testowania oprogramowania, pair programmingu… Dla nas Game of Life stanie się także punktem wyjścia do metod analizy domeny klienta, rozgryzania jej niuansów i niedopowiedzeń ze strony biznesu, czy wreszcie definiowania i ochrony logiki biznesowej tak, aby teoretycznie niewielkie zmiany wymagań nie zrujnowały całkowicie implementacji… W końcu Game of Developer Life to coś więcej niż tylko stosowanie w praktyce znanych frameworków i narzędzi.