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