Podstawy Refaktoryzacji

title

Podstawy refaktoryzacji

author

Leszek Albrzykowski (NobleProg Ltd)

Kody źródłowe dla omawianych wzorców: http://svn.nobleprog.com/training/php/Refactoring/

Definicja ⌘

Zmiany kodu niewpływające na jego funkcjonalność.

Definicja - Martin Fowler ⌘

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.

Martin Fowler

Czemu ma służyć? ⌘

Jakiego efektu spodziewamy się po refaktoryzacji?

• Efekty mierzalne w krótkim czasie

Czemu ma służyć? ⌘

Jakiego efektu spodziewamy się po refaktoryzacji?

• Efekty mierzalne w krótkim czasie
• Efekty mierzalne w długim czasie

Koszt refaktoryzacji ⌘

Estymujmy wykres funkcji trzech zmiennych:

• Koszt
• Czas
• Jakość

dla:

• Systemu, którego kod poddany jest refaktoryzacji po jego uruchomieniu

Koszt refaktoryzacji ⌘

Estymujmy wykres funkcji trzech zmiennych:

• Koszt
• Czas
• Jakość

dla:

• Systemu, którego kod poddany jest refaktoryzacji po jego uruchomieniu
• Systemu, który zostaje stworzony od nowa

Kiedy kod podlega refaktoryzacji? ⌘

Refaktoryzacja jest procesem ciągłym. Podczas refaktoryzacji nie zmienia się funkcjonalność kodu ale poprawia się jego jakość. Estymujmy wykres funkcji, która odzwierciedla zmiany funkcjonalności względem czasu.

Refaktoryzacja a TDD ⌘

Zgodnie z założeniami TDD, następuje po stworzeniu kodu realizującego funkcjonalności "opisane" przez testy jednostkowe. Patrząc na system z perspektywy cyklu życia oprogramowania, refaktoryzacja występuje na etapach rozwoju oraz utrzymaniu (pielęgnacji systemu). Poniżej opisujemy kroki wytwarzania produktu zgodnie z TDD:

• Utworzenie testów jednostkowych na podstawie wymagań użytkownika końcowego (klient, biznes, Product Owner etc.)
• Stworzenie kodu, którego zadaniem jest spełnienie funkcjonalności opisanej przez testy. Na tym etapie kod realizuje zakładane funkcjonalności jednak jest niskiej jakości i trudny do dalszego rozwoju.
• Refaktoryzacja utworzonego kodu.

Cykl ilustruje schemat: [1]

Refaktoryzacja a DDD ⌘

Na "wyższym" poziomie, jednym ze wzorców refaktoryzacji jest przejście z kodu proceduralnego na obiektowy. Tutaj konieczne jest zwrócenię uwagi na model dziedziny (ang. Domain Model):

An object model of the domain that incorporates both behavior and data.

At its worst business logic can be very complex. Rules and logic describe many different cases and slants of behavior, and it's this complexity that objects were designed to work with. A Domain Model creates a web of interconnected objects, where each object represents some meaningful individual, whether as large as a corporation or as small as a single line on an order form.

Martin Fowler

Refaktoryzacja a zasada KISS ⌘

KISS - Mając wiedzę na temat wzorców projektowych i wzorców refaktoryzacji możliwe jest uproszczenie kodu systemu.

Refaktoryzacja a zasada DRY ⌘

DRY - Podobnie jak wyżej, dzięki odpowiedniej wiedzy jesteśmy w stanie zredukować nie tylko powtarzające się linie kodu ale też powtarzające się funkcjonalności realizowane przez różne klasy.

Refaktoryzacja a jakość ⌘

W zależności od przyjętych kryteriów, jakość kodu jest jednym ze składników ogólnie przyjętych norm jakości produktu. Jakość jest jednym z najważniejszych czynników związanych z procesem tworzenia oprogramowania. Aby zrozumieć znaczenie jakości warto zaznaczyć, że np. zarówno w metodyce PRINCE2 (jeden z Tematów) jak i Scrum (chociażby Code reviews) zajmuje istotne miejsce.

Code smell ⌘

A code smell is a hint that something has gone wrong somewhere in your code.

Wnioski - Korzyści ⌘

• Ułatwienie procesu pielęgnacji i dalszego rozwoju systemu

Wnioski - Korzyści ⌘

• Ułatwienie procesu pielęgnacji i dalszego rozwoju systemu
• Zapobieganie redundancji kodu

Wnioski - Korzyści ⌘

• Ułatwienie procesu pielęgnacji i dalszego rozwoju systemu
• Zapobieganie redundancji kodu
• Ułatwienie podczas dokumentowania systemu

Wnioski - Korzyści ⌘

• Ułatwienie procesu pielęgnacji i dalszego rozwoju systemu
• Zapobieganie redundancji kodu
• Ułatwienie możliwości dokumentowania systemu
• Tworzenie kodu zgodnie z przyjętymi standardami, co ułatwia jego zrozumienie

Wnioski - Korzyści ⌘

• Ułatwienie procesu pielęgnacji i dalszego rozwoju systemu
• Zapobieganie redundancji kodu
• Ułatwienie możliwości dokumentowania systemu
• Tworzenie kodu zgodnie z przyjętymi standardami co ułatwia jego zrozumienie
• Ułatwienie w utrzymaniu (zachowaniu) odpowiednich warstw systemu

Na jakie problemy refaktoryzacja nie jest rozwiązaniem ⌘

• Zła architektura systemu

Na jakie problemy refaktoryzacja nie jest rozwiązaniem ⌘

• Zła architektura systemu
• Niezrozumienie wymagań klienta

Na jakie problemy refaktoryzacja nie jest rozwiązaniem ⌘

• Zła architektura systemu
• Niezrozumienie wymagań klienta
• Brak kompetentnego zespołu

Na jakie problemy refaktoryzacja nie jest rozwiązaniem ⌘

• Zła architektura systemu
• Niezrozumienie wymagań klienta
• Brak kompetentnego zespołu
• Brak kompetentnego kierownika projektu (ale też czasami - używając nomenklatury metodyki PRINCE2 - komitetu sterującego a nawet organizacji jeśli mówimy o mikroprzedsiębiorstwach)

Na jakie problemy refaktoryzacja nie jest rozwiązaniem ⌘

• Zła architektura systemu
• Niezrozumienie wymagań klienta
• Brak kompetentnego zespołu
• Brak kompetentnego kierownika projektu (ale też czasami - używając nomenklatury metodyki PRINCE2 - komitetu sterującego a nawet organizacji jeśli mówimy o mikroprzedsiębiorstwach)
• Brak systematyczności - niekiedy koszt przepisania systemu jest niższy niż jego refaktoryzacji

Na jakie problemy refaktoryzacja nie jest rozwiązaniem ⌘

• Zła architektura systemu
• Niezrozumienie wymagań klienta
• Brak kompetentnego zespołu
• Brak kompetentnego kierownika projektu (ale też czasami - używając nomenklatury metodyki PRINCE2 - komitetu sterującego a nawet organizacji jeśli mówimy o mikroprzedsiębiorstwach)
• Brak systematyczności - niekiedy koszt przepisania systemu jest niższy niż jego refaktoryzacji
• Nieprawidłowy wybór technologii