Refaktoryzacja Robert Pająk

Plan Wprowadzenie Demo Podsumowanie, czyli trochę teorii

Definicja Refaktoryzacja - zmiana wewnętrznej struktury oprogramowania, sprawiająca, że kod staje się łatwiejszy do zrozumienia i tańszy w utrzymaniu. Zmiana ta nie wpływa na obserwowalne zachowanie programu. Refaktoryzacja to sprzątanie Lepiej pracuje się w przygotowanym środowisku pracy

Czym powinna być refaktoryzacja Ta sama funkcjonalność Lepsza struktura Ryzyka (przy złej refaktoryzacji): Wprowadzenie trudno wykrywalnych błędów Można się zapędzić i utknąć w czarnej dziurze Strata czasu

DEMO Case: Wypożyczalnia filmów Obliczanie i wyświetlanie kosztów za wypożyczenia. Program pobiera dane na temat wybranych filmów i czasu, w którym zostały wypożyczone. Istnieją trzy typu filmów. Poza opłatą system wyznacza punkty stałego klienta.

Case: Wypożyczalnia filmów (1/2) Przed zmianą Po ekstrakcji metod

Case: Wypożyczalnia filmów (2/2) Przed zmianą Po dodaniu funkcjonalności

Dlaczego refaktoryzacja jest ważna Ulepszenie projektu Poprawa czytelność Identyfikacja błędów Przyspieszenie programowania Ułatwia wprowadzanie kolejnych zmian

Jak refaktoryzować Metafora 2 kapeluszy Solidny pakiet samosprawdzalnych testów Krokowo (testowanie -> mała zmiana) Zgodnie z zasadami OOAD (np. SOLID) Wykorzystanie wzorców projektowych „Czyszczenie” kodu Single responsibility principle the notion that an object should have only a single responsibility. Open/closed principle the notion that “software entities … should be open for extension, but closed for modification”. Liskov substitution principle the notion that “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”. See also design by contract. Interface segregation principle the notion that “many client specific interfaces are better than one general purpose interface.” Dependency inversion principle the notion that one should “Depend upon Abstractions. Do not depend upon concretions.” Dependency injection is one method of following this principle.

Kiedy refaktoryzować Zasada do trzech razy sztuka Przed dodaniem nowej funkcjonalności Po wykryciu błędu Podczas inspekcji kodu (ang. code review) Projektowanie a Refaktoryzacja Wydajność a Refaktoryzacja Problemy z refaktoryzacją Bazy danych Zmiany interfejsu Wydajność dopiero na końcu. Optymalizacja często zaciemnia kod. Zasada 90/10. Korzystanie narzędzi profilujących, w celu krytycznych ścieżek

Literatura http://martinfowler.com/refactoring/ „Refaktoryzacja. Ulepszanie struktury istniejącego kodu”, Martin Fowler, Kent Beck… „Kod doskonały. Jak tworzyć oprogramowanie pozbawione błędów. Wydanie II”, Steve McConnell „Czysty kod. Podręcznik dobrego programisty”, Robert C. Martin „Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku”, GoF „UML i wzorce projektowe. Analiza i projektowanie obiektowe oraz iteracyjny model wytwarzania aplikacji. Wydanie III”, Craig Larman

Pytania? robert.pajak@hotmail.com