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
Grupa docelowa: developerzy
Logistyka: W siedzibie klienta lub w innym dowolnym miejscu.
Data i dokładny zakres do ustalenia podczas analizy przed-szkoleniowej.

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

Podczas zajęć możesz oczekiwać szczególnych akcentów położonych na poniższe aspekty:

  • 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.

Materiały związane ze szkoleniem

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

Zapytaj o 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ń