Jaka jest główna przyczyna braku refaktoryzacji?

Czy próbowałeś kiedykolwiek znaleść źródło problemu zamiast nieustannej walki z jego konsekwencjami? Bo kiedy pracujemy nad zniwelowaniem objawów nie znając przyczyny – to problem powraca jak bumerang. Więc gdzie jest przyczyna rosnącego długu technicznego i braku na czasu na Czysty Kod? Dlaczego nie wykonujemy refaktoryzacji kodu na bieżąco? A potem jest już za późno i tylko marudzimy, że trzeba by cały projekt napisać od nowa…

Czysty Kod to wyzwanie dla każdego projektu, zespołu oraz programisty. No i przecież można by od razu napisać ten Czysty Kod i po kłopocie. Tymczasem kiedy nad projektem pracuje wielu programistów. to każda osoba ma nieco inny styl programowania. Dodatkowo każda osoba inaczej rozumie pojęcie Czystego Kodu. A jeszcze programiści często zmieniają pracę. Wtedy na ich miejsce przychodzą kolejni z innymi pomysłami dotyczącymi jakości kodu…

Jak więc odnalazłem główną przyczynę braku Czystego Kodu?

Przez pierwsze 10 lat byłem wyłącznie programistą. Wtedy widziałem świat raczej poprzez technologię niż potrzeby biznesowe klienta. W związku z tym podczas moich szkoleń szkoleń najważniejsze dla mnie były aspekty techniczne refaktoryzacji kodu. Uczestnicy szkoleń byli bardzo zadowoleni z nacisku na prawie wyłączne aspekty techniczne dotyczące Czystego Kodu które mogli poznać .

Z czasem pytałem uczestników moich warsztatów jak zastosowali zdobytą wiedzę z refaktoryzacji w praktyce. Byłem ciekawy czy wprowadzili do zespołu nawyk dbania o czysty kod poprzez refaktoryzację.

Niestety uczestnicy moich szkoleń prawie zawsze mieli jakąś wymówkę.

Wtedy zacząłem szukać wspólnej części tych problemów. Przekonywanie programistów, menedzerów, analityków itd. – że warto to niekończąca się opowieść (jak i dosyć stary film). Co prawda od tego zacząłem – bo każdy lubi udowadniać swoją rację – ale z małym powodzeniem.

Następnie zacząłem się moje prawdziwe poszukiwania, co jest współnym podłożem dla tych wszystkich problemów. Kiedy te wszystkie wyzwania nie będą blokować refaktoryzacji? I chyba znalazłem! Otóż wszystkie te wymówki łączy jedno. Jest to błędne założenie, że refaktoryzacja to osobna, dodatkowa czynność.

Jakie konsekwencje pociąga za sobą to błędne założenie?

Jeżeli refaktoryzcja kodu jest uznawana za dodatkową rzecz, to zawsze znajdzie się wymówka aby ją pominąć. Bo przecież skoro to osobna rzecz, to nie jest niezbędna…

Klient przecież czeka “tylko” na funkcjonalność…

Klient czeka na fukcjonalność która dostarczy wartość biznesową. Żaden klient nie czeka na refaktoryzację kodu! A więc po co?

Ale czy programiści nie oczekują jakości aby móc kontunuować projekt zamiast szukać nowej pracy z powodu bałaganu w zastanym kodzie? Czy naprawdę tylko klient jest ważny a komfort pracy programisty już nie? Czy komfort pracy programistów z Czystym Kodem może zostać pominięty w imię klienta?

Refaktoryzacja to nie etap w procesie tworzenia oprogramowania…

Skoro refaktoryzacja nie jest obowiązkowa, to nie dodawajmy jej do procesu tworzenia oprogramowania. A wtedy pomijamy refaktoryzację kodu z automatu i z “czystym sumieniem”. Zapewne (na początku) napisanie kodu będzie szybsze. Będziemy mogli powiedzieć że “taki mamy process… więc to nie moja wina, że nie się nie dzieje”

Tymczasem czy moglibyśmy pominąć refaktoryzację jeżeli byłaby osobną i widoczną kolumną po “przeglądzie kodu” w na tablicy Kanban / Scrum? Może to być także bardziej ogólna kolumna jak “rework” – np. dodanie brakujących testów. Proces jest od tego, aby zapewnić obecność poszczególnych kroków.

Potrzebna byłaby zgoda managera…

Skoro co coś dodatkowego, to ktoś powinien wyrazić na to zgodę. Bo przecież to zajmie nam czas czyli będzie dodatkowo kosztować. A tak zawsze mogę powiedzieć, że ja to bardzo chciałbym refaktoryzować, ale manager nie pozwala…

Ale czy pytamie się o zgodę będzie potrzebne jeżeli refaktoryzacja jest częścią procesu i dobrych praktyk w zespole? Przecież to manager odpowiada za zgodność procesu z uzgodnionymi standardami w firmie.

Potrzebny byłby czas…

“Nie mamy czasu na poprawianie kodu” – ile razy to słyszałem… A ja wtedy się pytam – “Czy także nie macie czasu na poprawianie błędów zgłoszonych przez klienta?”

Czy lepiej zapobiegać czy leczyć? Czy lepiej działać proaktywnie, bo można przewidzieć problemy które się pojawią? A wtedy i tak zabiorą nam czas i pieniądze czy tego chcemy czy nie… Być może proaktywnie spędzimy mniej czasu i pieniędzy pracując wcześniej nad jakością kodu i architektury?

Refaktoryzacja to dodatkowe koszty…

To prawda. Zgadzam się w 100%. Refaktoryzacja do Czystego Kodu wymaga czasu i pieniędzy.

Ale czy brak Czystego Kodu i bałagan jest tani? Czy poprawianie błędów jest za darmo? Czy poprzez brak refaktoryzacji rzeczywiście oszczędzimy pieniądze w dłuższym okresie czasu?

Boję się konsekwencji porażki

Jeżeli pracuję nad czymś dodatkowym, co nie jest konieczne to chcę koniecznie osiągnąć sukces. Tymczasem refaktoryzacja to podróż i poszukiwanie lepszego kodu. Czasem próba zamiany kodu kończy się niepowodzeniem i koniecznością cofnięcia zmian.

Jeżeli więc wyciągasz wnioski z porażek i błedów to się rozwijasz. A sumie to tylko wtedy bo każdy kto działa popełnia błędy. Tak więc refaktoryzacja która zakończyła się niepowodzeniem może być lekcją, aby następnym razem zaproponować nowe pomysły zmian w kierunku Czystego Kodu. A czy Twój pracodawca wspiera rozwój poprzez eksperymenty które czasem są nieudane?

Rady dla programistów

Zaczynaj od refaktoryzacji

Oceń jakość kodu zastanego nad którym będziesz pracować. Być może już teraz jest on mało czytelny. Wtedy podążająć za obecną architekturą – dodając dodatkowe warunki i wydłużając metody – pogorszysz tylko sprawę. Wykonaj więc refaktoryzację np. do wzorców projektowych. Wówczas dodanie nowej klasy wzorca strategi lub komendy będzie proste i czytelne.

Kończ na refaktoryzacji

Czesto konieczność refaktoryzacji jest niewidoczna przed dokonaniem zmian w kodzie. I bardzo dobrze, bo dzięki temu unikamy wczesnego “over-engineeringu”! Ale być może właśnie po implementacji kolejnych zmian i pokryciu ich dodatkowymi testami łatwo będzie wykonać refaktoryzację do Czystego Kodu.

Refaktoryzuj w trakcie programowania

Wiele refaktoryzacji to drobne poprawki, które wykonasz na bieżąco w ciągu kilku sekund. Są to esktrakcja metody, zmiennej, pola lub ich wchłonięcie. Podobnie zmiana nazwy metody czy zmiennej. Korzystaj z tych funkcjonalności na bieżąco, ponieważ są zautomatyzowane w wielu środowiskach jak IntelliJ, Ecplise czy Rider.

Powodzenia!