Dziś przyszedł czas na zajęcie się typowo “aplikacyjną” częścią naszego projektu. Zdecydowałem, iż pierwszymi aplikacjami jakie stworzymy będą tzw. asystenci kierowcy. Tego typu funkcjonalność została już zaimplementowana na potrzeby poprzedniego projektu HypeFIS. Rozsądnym podejściem byłoby więc re-użycie istniejącego już, działającego i dobrze przetestowanego kodu. W ten sposób znacząco ograniczylibyśmy ilość pracy przeznaczonej na implementację oraz testy. W naszym przypadku wprowadzimy jednak pewne zmiany. W jednym z poprzednich artykułów zwróciłem uwagę na możliwość stworzenia uniwersalnej maszyny stanów do obsługi wszelkich komunikatów. Użycie jej w podsystemie asystentów spowoduje znaczące uproszczenie kodu i zredukuje jego ilość.
Jako “rasowi” developerzy zaczniemy więc od refaktoryzacji kodu 🙂

No ale czym jest ta refaktoryzacja?

Najogólniej refaktoryzacja polega na przekształceniu istniejącego kodu źródłowego lub zmodyfikowaniu architektury, tak aby lepiej dopasować je do zmieniających się wymagań, umożliwić testowanie, uprościć czy uczynić bardziej przejrzystymi.

Dla części osób refaktoryzacja jednoznacznie kojarzy się z przepisaniem kodu “od nowa”. Jest to jej najbardziej drastyczna forma, aczkolwiek w przypadku skrajnie zaniedbanego kodu jedyna, która da zadowalający efekt. W praktyce jednak refaktoryzacja najczęściej przebiega, jako naturalny, iteracyjny proces polepszania jakości kodu źródłowego oraz struktury oprogramowania.

Należy pamiętać iż tego rodzaju działania wiążą się zawsze z ryzykiem wprowadzenia nowych błędów. Dlatego też podstawą skutecznej refaktoryzacji są działające testy lub przynajmniej referencyjny kod, który stanowi punkt odniesienia.

Jak głęboka będzie refaktoryzacja w przypadku naszego kodu?

Bardzo głęboka. Całkowitej przebudowie na pewno musi ulec interfejs użytkownika (inna biblioteka graficzna, widgety, system okien, etc). Również wszelkie interakcje logiki sterującej z otoczeniem ulegają zmianie. Można powiedzieć, że jedyną niezmienioną częścią pozostanie właśnie owa logika, przeniesiona do wyekstrahowanej maszyny stanów.

Czyli w zasadzie niewiele pozostaje? Po co więc refaktoryzacja? Jaki ma ona sens? Nie lepiej napisać kod od nowa?

Absolutnie nie! Należy pamiętać, że zanim zabierzemy się do pracy, musimy przebrnąć przez stary kod, dobrze go zrozumieć. Wówczas nawet jeżeli posuwamy się do bardzo głębokiej przebudowy, dokonujemy jej świadomie. Pisząc “od nowa” zawsze ryzykujemy utratę jakiegoś detalu, drobnego szczegółu, który umknie nam gdzieś w ferworze walki.

Co dokładnie chcemy przenieść ze starego projektu?

Poniżej lista naszych asystentów kierowcy:

• Asystent świateł – informuje o konieczności włączenia świateł mijania (dziennych),
• Asystent odpoczynku – informuje o konieczności zrobienia krótkiej przerwy w czasie dłuższej jazdy,
• Asystent pasów bezpieczeństwa – przypomina o konieczności zapięcia pasów oraz monitoruje ich stan w trakcie jazdy,
• Asystent prędkości – ostrzega o przekroczeniu zadanego limitu dozwolonej prędkości,

Każdy asystent będzie składał się z kilku subkomponentów:

• Maszyny stanów,
• Okna z komunikatem,
• Okna konfiguracyjnego,

Ok, wiem co i jak musimy zrobić. Jutro piąteczek, piątunio 🙂 Chwila przerwy na złapanie oddechu – idealny moment, żeby zająć się asystentem, który powie nam wprost, że… czas na kawę 🙂 !