Praca z kodem „legacy”: strategie, naprawa błędów, refaktoryzacja oraz narzędzia wspomagające.

Tytuł: Praca z kodem „legacy”: strategie, naprawa błędów, refaktoryzacja oraz narzędzia wspomagające.
Kod: ccpp-legacy C++
Kategoria: C i C++
Forma: 40% wykłady / 60% warsztaty
Czas trwania: 3 dni
Odbiorcy: developerzy
Zapisy: Indywidualne zamówienie i dopasowanie dla grupy.
Logistyka: W siedzibie klienta lub w innym dowolnym miejscu.

Szkolenie prezentuje pragmatyczne podejście do pracy z kodem „legacy”.

Przedstawione strategie i narzędzia pozwalają przełamać strach przed zmianami w zastanym kodzie, przez co ułatwiają bezpieczne modyfikacje oraz refaktoryzację kodu kładąc szczególny nacisk na testowanie.

W oparciu o rzeczywiste przykłady, uczestnicy zdobywają wiedzę i praktykę w metodycznym podejściu do zmian w zaniedbanym kodzie.

Szkolenie przeznaczone jest dla programistów C++ rozwijających lub utrztmujących kod w (najczęściej) odziedziczonych projektach. Zdobyta wiedza przekłada się w praktyczny sposób na jakość dostarczanych zmian mierzoną w szerszej perspektywie czasu.

Wyróżniki szkolenia

  • Szkolenie prowadzone przez trenera ze dużym doświadczeniem w pracy z kodem legacy
  • Konstrukcja techniczna szkolenia umożliwia nabycie praktycznych umiejętności wprowadzania szeroko rozumianych zmian w kodzie legacy
  • Rzeczywiste przykłady

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.

  1. „Legacy Code” – czy to tylko kod odziedziczony?
    1. Definicja LC – "oddzielenie ziarna od plew”
      1. „Wiedza plemienna” – znajomość funkcjonalności i wymiana wiedzy w projekcie
      2. Kod niepokryty testami
      3. „Zapachy kodu” – zbiór najczęstszych błędów/praktyk w zaniedbanym kodzie
        1. Długa metoda – brak kohezji
        2. Powielanie kodu – „nie ma to jak powielać te same błędy”
        3. Eksplozja kombinatoryczna – „siostra powielania, czyli robię to samo na innych danych”
        4. Osobliwe rozwiązanie – „cichy brat powielania, czyli zrobię to samo ale w nieco inny sposób”
        5. Złożoność warunków – „bo trzeba napisać tak by nikt inny tego nie był w stanie zrozumieć”
        6. Rozrzucanie rozwiązania – strach przed zmianami w kilku miejscach
        7. Klasa bóg – „klasa może i robi wszystko”
        8. Leniwa klasa – „klasa nie zarabia na siebie”
        9. Obnażanie się – „wszystko w public”
    2. Rodzaje zmian w LC ze szczególnym ujęciem kalkulacji ryzyka na rzecz świadomego dobrania rozwiązania do klasy problemu
      1. Przyczyny wprowadzania zmian
        1. Naprawa błędów
        2. Rozszerzanie funkcjonalności
        3. Refaktoryzacja
      2. Kalkulacja i minimalizacja ryzyka
        1. Jasne określenie punktu widzenia klienta
        2. Ocena klasy problemu i stopnia komplikacji wprowadzanej zmiany
        3. Stopień opłacalności różnych rozwiązań w świetle testów
        4. Regresja – wpływ dokonanej (często jednostkowej) zmiany na szereg pozostałych funkcjonalności oraz na lokalną i globalną architekturę
        5. Nowe testy – koszt napisania i utrzymania vs. posiadanie i bezpieczeństwo kolejnych modyfikacji
  2. Metodyki wprowadzania zmian – „jak to zrobić by nie napsuć”
    1. Naprawa błędów ze szczególnym uwzględnieniem wskaźników i tablic
      1. Podejście naiwne
      2. Podejście „imperatywne” – wykorzystanie mechanizmów języka i kompilacji na rzecz bezpieczeństwa i jakości wprowadzonych poprawek (mała refaktoryzacja).
    2. Rozszerzanie funkcjonalności
      1. Podejście naiwne
      2. Rozszerzania funkcjonalności w oparciu o refaktoryzację
  3. Wstęp do refaktoryzacji
    1. Czym jest dobra refaktoryzacja?
    2. Kiedy (nie)można lub (nie)należy dokonać refaktoryzacji?
    3. Narzędzia wspomagające
      1. Cppcheck – sprawdzenie poprawności kodu bez uruchamiania go
      2. CPD – wykrywanie zduplikowanego kodu (wstęp do refaktoryzacji właściwej)
      3. CCCC – „lokalny” stopień złożoności kodu
      4. Valgrind – analiza sterty (memcheck), śledzenie wskaźników (ptrcheck), sprawdzenie wielowątkowości (hellgrind)
    4. Strategia – testowanie punktem wyjścia na rzecz tworzenia bezpiecznych wysp i późniejszego scalenia ich w jeden pokryty testami kontynent
  4. TDR – Test Driven Refactoring
    1. Identyfikacji newralgicznych punktów kluczem do sukcesu
    2. Pokrycie testami newralgicznych punktów
      1. Łamanie zależności zewnętrznych i lokalnych
      2. Pisanie testów i wprowadzania mock’ów z uchwyceniem najczęściej popełnianych błędów
    3. Skutki cząstkowego podejścia
  5. Refaktoryzacja właściwa – budowa mikro/makro architektury w oparciu o wzorce
    1. Upraszczanie kodu
      1. Ekstrakcja metod
      2. Zastępowanie wyrażeń warunkowych wzorcem strategii
      3. Zmiana upiększeń w dekorator
      4. Zastępowanie wyrażeń zmian stanu klasami stanu
    2. Tworzenie obiektów
      1. Metody tworzące egzemplarze zamiast naiwnych konstruktorów
      2. Operacja tworzenia obiektów w fabryce
      3. Klasy builder do hermetyzacji obiektów kompozytowych
      4. Inline singleton – a może zło wcielone
    3. Uogólnianie kodu
      1. Metoda szablonowa – wprowadź dziedziczenie na rzecz polimorfizmu
      2. Kompozyt – zamiana relacji jeden do wielu
      3. Obserwator dla notyfikacji
      4. Adapter – unifikacja interfejsów
      5. Interpreter – obsługa niejawnych języków
    4. Ochrona
      1. Zastępowanie typów prostych klasami „value object”
      2. Akumulacja
      3. Gromadzenie danych w parametrze zbierającym
      4. Gromadzenie danych przy użyciu inspektora (visitor)
  6. Wnioskowanie i zabezpieczenia
    1. Ocena wprowadzonych zmian
      1. Wyniki testów oraz ich pokrycie
      2. Statyczna analiza kodu
      3. Code Review – część procesu dostarczania zmian z szeregiem zalet
    2. Pętla refaktoryzaji
      1. Czym jest?
      2. Kiedy ją przerwać?
    3. Testy i ich regresyjność
      1. Reżim wykonywania testów: jednostkowych, modułowych, funkckjonalnych i integracyjnych
      2. Wstęp do CI – „Contineous Integration” – testy ciągłą i integralną częścią produkcji kodu


Pobierz program w formacie PDF

Trenerzy

Poznaj ekspertów, którzy mogą poprowadzić Twoje szkolenie.

Roman Ulan

trener

1. Nie bój się myśleć! 2. Nie bój się eksperymentować! 3. Nie bój się pytać!

Materiały związane ze szkoleniem

Idea renesansowej pracowni - Bottegi zakłada nieustanną pracę jej członków i dzielenie się jej wynikami.

Zamów szkolenie

Imię i nazwisko:
Firma:
E-mail:
Nr tel:
Temat:
Wiadomość:

Jeżeli preferujesz osobisty kontakt to zawsze możesz zadzwonić.

Iwona Sobótka

Koordynatorka szkoleń


Twoje dane osobowe przetwarzamy, aby udzielić odpowiedzi na Twoje pytanie. Administratorem Twoich danych osobowych jest Bottega It Minds Sławomir Sobótka. Przysługuje Ci prawo wniesienia sprzeciwu wobec przetwarzania, prawo dostępu do danych, prawo żądania ich sprostowania, usunięcia lub ograniczenia ich przetwarzania. Szczegółowe informacje dotyczące przetwarzania Twoich danych osobowych znajdują się TUTAJ.