Wstyd powiedzieć ale dopiero teraz, jakieś 15 lat za późno, przeczytałem książkę “Refaktoryzacja – ulepszanie struktury istniejącego kodu” napisaną przez: Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts. Czytałem ją w bardzo dobrym polskim tłumaczeniu z 2011 roku autorstwa Justyny Walkowskiej roku wydanym przez Helion.

Książka ta czytana w roku 2015 jest dosyć specyficzna, ponieważ została napisana w 1999 (16 lat temu) ale główne jej przesłania pozostały bez zmian. Z łezką w oku czytałem o Javie w wersji 1.0 i 1.1, przykładach kolekcji na klasie Vector oraz kompilacji plików źródeł programem javac :-). Książka opisuje czasy kiedy zintegrowane środowiska programistyczne (IDE) dopiero powstawały, a opisywanie przekształcenia robiło się ręcznie, np. wyszukując wystąpienia zmiennej tekstowym grep’em. Z kolejną łezką w oku przypominałem sobie czasy przed Eclipse, jak kodowało się w XEmacs’ie… Młodsi czytelnicy mogą być nieco przerażeni.

Mimo powyższej specyfiki pewne rzeczy są ponadczasowe: lista objawów złego kodu (zwana tutaj wdzięcznie “zapaszkami”) jest praktycznie niezmienna od lat – te same problemy widzę w kodzie zarówno początkujących programistów, jak i tych którzy trochę “zaniedbają” swój projekt.

Drugą ponadczasową rzeczą są możliwe do zastosowania przekształcenia, zebrane w logiczny i przejrzysty katalog, każde z nich ładnie nazwane i opisane: wstępem, instrukcją oraz przykładem – oczywiście w większości przypadków instrukcja nie ma już sensu, ponieważ mechanizmy wbudowane w IDE robią wszystko po wydaniu jednego polecenia. Z mojej perspektywy “doświadczonego” programisty istotne jest nie to że są one mi nieznane, bo praktycznie każde z nich robiłem, mimo że nazw niektórych bym się nie domyślił. Najistotniejsze jest to, że jest to świetny słownik którego mogłem używać do opisywania problemów i zaleceń w przeglądach kodu innym programistom, zamiast tłumaczyć wszystko od początku. Innymi słowy, gdybyśmy ja (recenzent) i autor nieprawidłowego kodu przeczytali wcześniej tą książę, to zamiast opowiadać 15 minut machając rękoma i rysując schematy klas, mógłbym powiedzieć “zastosuj Zastąpienie Instrukcji Warunkowej Polimorfizmem” i wszystko byłoby jasne. Szach i mat.

Trzecią ponadczasową rzeczą opisywaną w książce są relacje pomiędzy programistą a kierownikiem i/lub managerem i odpowiedź na pytania: czy i kiedy refaktorować, jak to powiedzieć przełożonym i jak to umieścić w harmonogramie projektu. Tutaj nic się nie zmieniło przez dekady…

Żeby jeszcze bardziej zachęcić do przeczytania tej książki, poniżej przedstawiam kilka cytatów które szczególnie przypadły mi do gustu:

• “Co powiedzieć kierownikowi? […] – nie przyznawaj się” – jest to stanowisko skrajne z którym w ogólności się nie zgadzam, jednak rozwinięcie dobrze opisuje problem,
• “komentarze w kodzie […] są często używane jako dezodorant, który ma zamaskować problem” – chleb nasz powszedni :-),
• “gdy testerzy podczas testów funkcjonalnych znajdą błąd […] programista przed jego usunięciem powinien dodać test jednostkowy który go wykrywa” – gdy tylko miałem taką możliwość starałem się działać według tej zasady, oczywiście w odniesieniu do błędów B/E, a nie drobnostek wizualnych na F/E,
• “przestrzegam przed używaniem typu double do reprezentacji finansów w komercyjnym oprogramowaniu” – niby oczywistość ale powtarzam to niemal każdemu młodszego programiście i, co ciekawe, zdarza mi się to znaleźć również w “prawdziwym” oprogramowaniu od renomowanych producentów ;-),
• “refaktoryzacja sprawia, że nigdy nie musisz przepraszać, po prostu naprawiasz” – wyrwane z kontekstu wygląda nieco dziwnie, ale sens tego jest taki że współcześnie refaktoryzacje trzeba traktować jako naturalny fragment pracy programisty,
• “Jeżeli ktoś (recenzent artykułu, słuchacz prezentacji) informuje że ‘nie rozumie’ (lub po prostu nie rozumie), to wina leży po stroni prezentera. To do niego należy odpowiedzialność za rozwój i odpowiednie zakomunikowanie idei.” – idealnie opisuje to moje motto że o skomplikowanych sprawach należy mówić prosto, bo niepotrzebne komplikowanie przekazu sprawia że dwoje nawet inteligentnych osób może się po prostu nie zrozumieć,
• “zaczynasz projekt od zera […] oraz rozumiesz problem, do którego rozwiązania ma służyć system oraz inwestor zgadza się opłacać prace do chwili, w której Ty uznasz, że program działa zadowalająco, to masz wielkie szczęście. Taki scenariusz […] jednak w większości przypadków pozostaje w sferze marzeń.” – to brutalna rzeczywistość z którą nie mogą pogodzić się idealiści, szczególnie młodzi wiekiem,
• “Refaktoryzacje można porównać do ćwiczeń i zdrowej diety […] Niektórzy długo dobrze sobie radzą bez [niej] i nie ponoszą żadnych obserwowalnych konsekwencji.” – to dobrze ilustruje problem unikania refaktoryzacji i porządków, po prostu nasz kod “tyje”, a problem spostrzegamy gdy nie możemy się już ruszać.

Zachęcam do przeczytania tej książki (zaliczanej przez Helion do “Kanonu informatyki”) zarówno początkujących programistów jak i weteranów tego zawodu.