Rozwój oprogramowania z wykorzystaniem Refaktoryzacji

LICZBA DNI: 2 (16h)

KOD KURSU: REFAKT/ADV

# gof

# oop

Autor szkolenia:
Sebastian Malaca

O szkoleniu

DLA KOGO?

Szkolenie skierowane jest do programistów i architektów, którzy pragną poznać techniki rozpoznawania, przeprowadzania oraz planowania złożonych jak i ryzykowanych refaktoryzacji

WYMAGANIA

Uczestnik szkolenia powinien posiadać podstawowe doświadczenie w programowaniu obiektowym (preferowanym językiem jest Java), testowaniu oraz refaktoryzacji

ZALETY

Cele szkolenia

Pisanie wysokiej jakości testów

Znajomość technik rozpoznania problemów, które występują w kodzie

Umiejętność doboru odpowiedniej strategii refaktoryzacji do problemu

Umiejętność refaktoryzacji kodu nieprzetestowanego

Program

  • Rozwój, a tworzenie aplikacji
  • Legacy Code, a Technical Debt
  • Fast feedback
  • Podejmowanie decyzji i odsuwanie ich w czasie
  • Akceptacja jako sposób na radzenie sobie z problemami, których nie rozwiążesz
  • Czy można uniknąć degradacji jakości kodu?
  • Projektowanie aplikacji jako sposób na kontrolę degradacji jakości
  • Prewencja ważniejsza niż leczenie
  • Piramida testów
    • Unit czy Component Test?
    • Testy integracyje
    • Component czy System Test?
  • Test Double Patterns
    • Rodzaje
    • Boundary Objects
    • Niebezpieczeństwa Test Double
  • Jak mierzenie pokrycia kodu może pomóc, a jak zaszkodzić?
  • Kiedy refaktoryzacja ma sens?
  • Niebezpieczeństwa refaktoryzacji
  • Refaktoryzacja, a testowanie
    • Czy testy są niezbędne?
    • Kiedy posiadanie testów szkodzi?
    • Jak poradzić sobie bez testów?
  • Jak rozpocząć refaktoryzację?
    • Poznaj swoje IDE
    • Wizualizacja problemów
    • Implementation-Driven Tests
  • Małe refaktoryzacje obarczone niewielkim ryzykiem
    • Jak nie zmarnować czasu przeznaczone na zrozumienie kodu?
    • Ekstrakcja
    • Zadbanie o widoczność
    • Wyrzuć to, czego nie potrzebujesz
  • Poprawa jakości poprzez zmianę designu
    • Jak testować Singletony?
    • Interfejsy z jedną implementacją – warto czy nie warto?
    • Dlaczego nie łączyć klasy abstrakcyjnej i interfejsu?
    • Refaktoryzacja klas abstrakcyjnych
    • Usuwanie zbędnych interfejsów
    • Dlaczego warto posiadać klasy odpowiedzialne za tworzenie obiektów?
    • Granica pomiędzy kodem produkcyjnym, a testami
    • Exceptions Driven Flow
  • Refaktoryzacje do wzorców
    • Czy zawsze warto?
    • Kiedy warto pozbyć się wzorców?
    • Command, Strategy czy State?
    • Strategy czy Template Method?
    • Chain of Responsibility czy Decorator?
    • Adapter and Boundary Object
    • Fabryka jako sposób kontroli spójności i enkapsulacji
    • Facade jako sposób kontroli spójności i enkapsulacji
    • Facade, a Anti-Corruption Layer
    • Builder
    • Observer
    • Mediator
    • Visitor
  • Jak odzyskać wiedzę domenową?
    • Adapter i Bounded Context
    • Warunki, czyli jak zrozumieć pytanie?
    • Korzyści z wprowadzenia Value Objects
    • Kolekcje czy własne obiekty?
    • Jak odnaleźć utracone informacje i je odzyskać?
  • Eliminacja zdegradowanego kodu, a Strangler pattern
  • Jak się przygotować?
  • Proof of Concept jako sposób na rozpoznanie problemu
  • Minimalizowanie ryzyka wynikającego z potencjalnych błędów
    • Ryzyka wynikające z Feature Branch
    • Feature toggles
    • Jak planować migracje?
    • Jak testować kod bez testów?

POLITYKA COOKIES:

Korzystamy z plików cookies, by móc jak najlepiej dostosować stronę do Twoich potrzeb oraz wyświetlać Ci przydatne i adekwatnych dla Ciebie reklamy w serwisie i poza nim. Możesz kontrolować ustawienia ciasteczek w swoich ustawieniach swojej przeglądarki. Odwiedzając tę stronę, wyrażasz zgodę na wykorzystywanie przez nas plików cookies.