Blog

Zdziwiony? Ja też byłam, gdy czytałam artykuł naukowy o roli architekta w ciągłym dostarczaniu oprogramowania (bibliografia, notka o „wolnym tłumaczeniu”), a tu zaraz obok takich zasad jak „Małe i niezależne jednostki wdrożeniowe”, „Zbieraj logi”, „Izoluj zmiany” czy „Testowalność wbudowana w architekturę” stoi jak byk „Nie skupiaj się zbyt mocno na reużywalności”. Toż wiadomo, że reużywalność to cudowna sprawa! Że piszesz raz, a używasz w nieskończoność. Że oszczędza czas i pracę, obniża koszty utrzymania, zwiększa produktywność itd. itp. Otóż nie wiadomo, bo artykuł w tytule miał jeszcze dopisek „z perspektywy praktyków”, a ulubionym zdaniem inżynierów jest „to zależy”.

Kiedy „to zależy” przeradza się w „Nie taka duplikacja zła, jak ją malują”?

• gdy utrzymanie kontaktów między zespołami przerasta korzyści z płynące z wykorzystywania jednolitego frameworku. Każda zmiana pociąga za sobą szereg spotkań i zatwierdzeń. Terminy wprowadzenia nowych wersji produktów muszą być ściśle synchronizowane. Czasami po prostu lepiej jest, aby każdy poszedł własną drogą, we własnym tempie.
• gdy znacznie cierpi testowalność – używanie gotowych komponentów z jednej strony jest dobre, bo nie wymyślamy koła od nowa, jedyne co musimy utrzymywać to konfiguracja. Z drugiej strony tracimy możliwość testowania jednostkowo, więc weryfikowanie konfiguracji odbywa się za pomocą powolniejszych testów integracyjnych lub akceptacyjnych.
• gdy w imię reużywalności tracimy z oczu używalność – nasz kod jest zbyt generyczny (ale za to jaki reużywalny ;) i konfiguracja sprawia użytkownikowi trudności. Zamiast używać naszego cudu, zwraca się w stronę „nowej, lekkiej” biblioteki.

YANGI

Z programistycznego punktu widzenia warto pamiętać o zasadzie YAGNI i zasadzie starych wyjadaczy o duplikacji.

YAGNI(You aren’t gonna need it, pol. Nie będziesz tego potrzebował) przekonuje, iż nie warto być jasnowidzem i wykonywać pracę, co do której nie mamy pewności, że będzie potrzebna. Lepiej poczekać, aż zajdzie konieczność implementacji danej funkcjonalności. Zatem, zamiast tworzyć od razu bardzo ogólne rozwiązanie, lepiej zaimplementować tylko to, co konieczne. Jeśli będziemy stosować dobre praktyki programistyczne, to rozszerzenie nie zaburzy całego obrazu, a w ostatecznym rozrachunku prawdopodobnie napracujemy się mniej.
Zasada starych wyjadaczy o duplikacji mówi, że dwa razy to przypadek, ale trzy to już wzorzec. Inaczej mówiąc, jak powieliłeś kod raz, to nie tragedia, ale jeśli powtarza się trzy razy, to refaktoryzacja jest mocno wskazana. Szczerze, jak pierwszy raz ją usłyszałam, to nie byłam przekonana, ale w praktyce oszczędza mnóstwo czasu i nerwów ;) Ta zasada ma dużo wspólnego z YAGNI – obie uczą cierpliwości.

Jak umiejętnie zaimplementować reużywalność?

Na koniec przykład umiejętnego zaimplementowania reużywalności. Linux jest jak budowla z klocków lego, a każdy z tych klocków jest dobrze zdefiniowany, niezależny, ale też nieduży. Autorzy oparli się pokusie zrobienia narzędzia do wszystkiego i na przykład, zamiast móc wyświetlać zawartości pliku jednym narzędziem z zaawansowaną konfiguracją (czytaj miliardem przełączników), mamy do dyspozycji parę poleceń m.in.: cat, tac, tail, less, more. Chociaż w wielu miejscach ich funkcjonalności pokrywają się, każde ma swoją niszę, każde jest potrzebne.

Podsumowując, nawet coś, co na pierwszy, a nawet i na drugi rzut oka wydaje się być drogą do ziemi obiecanej, może zwieźć nas na manowce, jeśli przestaniemy podchodzić do rzeczywistości krytycznie.