Kent Beck: TDD. Sztuka tworzenia dobrego kodu

5
457

Być może stali czytelnicy (mam takich?) pamiętają, że jakiś czas temu obkupiłem się w literaturę. Gdy ostatnio sprawdzałem został już tylko tysiąc stron, więc niedługo pewnie przyjdzie czas na nowe zakupy 🙂

Ostatnio spędziłem kilka dni na nadmorskiej plaży i z braku literatury fantastycznej postanowiłem wziąć na warsztat dzieło Kenta Becka – „TDD. Sztuka tworzenia dobrego kodu.” Pana Becka poznałem oczywiście dużo wcześniej. Jego nazwisko przewija się często przy tematach związanych z Agile czy Extreme Programming. Jego lista osiągnięć jest o wiele większa – spójrzcie choćby na Wikipedię – imponujące życie zawodowe. To, oraz fakt, że cały czas mam ogromną nadzieję, że wreszcie zrozumiem o co tyle szumu z tym całym TDD sprawiły, że bardzo cieszyłem się na myśl o tym że wreszcie ktoś kompetentny wyłoży mi wszystko jak kawę na ławę i w końcu mnie także olśni.

Bystry czytelnik po takim wstępie już wie, że niestety rozczarowałem się.

I nawet nie wiem od czego mam zacząć. Przede wszystkim może opowiem trochę o moim postrzeganiu TDD – otóż znam definicję, procedury z tym związane (red-green-refactor(blue wg Uncle Boba)), korzyści, jakie wszyscy wymieniają, ale nigdy jeszcze nie widziałem kogoś stosującego to podejście w rzeczywistym projekcie (nie amatorskim)  oraz nigdy nie widziałem dużego zestawu testów, który nie powodowałby problemów przy dalszych pracach nad kodem. Mimo to wierzę, że w końcu ktoś mi to pokaże – pewnie dlatego właśnie kupuję książki jak ta dziś opisywana.

Jednak nawet Kent Beck ze swoim profesjonalizmem na jakichś 200 stronach nie potrafił przekonać mnie do TDD i powoli tracę nadzieję, że komukolwiek się to uda 🙁

Jakie mam zarzuty wobec tej pozycji?

Autor bierze jako przykład system w którym należy zaimplementować m.in. dodawanie do siebie różnych walut. Przez pierwszych 30 stron pisania testów dochodzi do stanu, który był oczywisty dla każdego kto nie ma pojęcia o TDD, a ma choćby nikłe o projektowaniu oprogramowania. To chyba mój główny zarzut wobec TDD – gdy zwolennicy tego podejścia opowiadają o nim, to chodzi tam zawsze o pisanie testu testującego minimalny wycinek wymagań przed napisaniem linijki kodu produkcyjnego, następnie dopisanie tegoż kodu, refaktoryzację i napisanie kolejnego testu. Przez takie podejście zawsze patrzymy tak jakbyśmy mieli klapki na oczach. Mimo oczywistych rzeczy otaczających nas, nie zważamy na nic i piszemy tę swoją minimalną funkcjonalność. Dzięki temu cały kod jest pokryty testami, ale za to może się okazać (i okazuje się często) słaby koncepcyjnie. To tak jakbyśmy w przestrzeni szukali maksimum metodą, która gwarantuje nam uzyskanie maksimum lokalnego. W automatyce są takie podejścia i wtedy mimo, że można uzyskać efekty dużo lepsze, zadowalamy się tym maksimum lokalnym. Tak samo postrzegam TDD – dostajemy maksimum lokalne, mamy kod pokryty testami, ale nic więcej. Gdybyśmy, być może, połączyli dwa podejścia – projektowanie przed przystąpieniem do kodowania, a następnie TDD, wyniki byłyby dużo lepsze a dojście do nich nie byłoby tak frustrujące – bo jak nazwać to, że przez kilka godzin piszemy kod, a następnie dochodzimy do tego, że tak naprawdę to nie o to nam chodziło? Gdybyśmy najpierw sprawę przemyśleli, obmyślili architekturę – choćby w podstawowym zarysie, to wtedy dużo efektywniej moglibyśmy pisać testy – tyle, że wtedy nie byłoby to już TDD. Nie programowanie sterowane testami. W ogóle jak to brzmi? Nawet gdy sam ten skrót przetłumaczymy na polski to już coś tu nie pasuje… Mam cały czas przeczucie, że programowanie nie powinno być właśnie sterowane testami, a po prostu testowane.

No, ale to co właśnie napisałem powyżej kłóci się z tym, co pisze sam Kent Beck. Daleki jestem od porównywania się z nim, ale ktoś w tym momencie się myli – z rachunku prawdopodobieństwa wychodzi, że ja, ale dlaczego dotąd nikt mnie z tego błędu nie umiał wyprowadzić? Nawet książką taką jak ta? Bo sprecyzujmy raz jeszcze – nie mam absolutnie nic przeciwko testowaniu, a wręcz przeciwnie, ale mam wrażenie że TDD to po prostu przereklamowane podejście, które nadaje się do małych kawałków kodu i niczego więcej, a ludzie którzy twierdzą inaczej po prostu dostają za to niezłe pieniądze. Patrząc na Uncle Boba i Becka to nawet by się zgadzało i mam wręcz wrażenie, że pisząc taką książkę Beck schodzi trochę z takiego piedestału, na którym stoi jako żywa legenda programistyczna, a zaczyna się trochę „sprzedawać” (modne słowo) biorąc pieniądze za wciskanie czegoś co nie do końca działa. Bo, spójrzmy prawdzie w oczy, nie istnieje „złoty młotek”. I im bardziej ktoś przekonuje mnie do tego, że sprzedaje panaceum i nie mówi kiedy to się będzie sprawdzało, a kiedy nie – tym bardziej staję się nieufny.

Tutaj przypomnę Macieja Aniserowicza, na którego prezentacjach zawsze słyszałem kiedy opisywana technika się sprawdzi, a kiedy tak nie robić. Podobnie Udi Dahan – mimo, że NServiceBus to jego dzieło, nie opisuje go jako sposób na każdy projekt.

Do tego w drugiej części książki naczytałem się o efemerycznych wzorcach, które wg mnie pełnoprawnymi wzorcami nie są (a przynajmniej nie wszystkie), lub są znane szerzej pod inną nazwą – to też, wg mnie – takie dodawanie treści na siłę, żeby dociągnąć do zakładanej objętości druku.

Schodząc już z autora, nie oszczędzę też tłumacza, który może i miał trudne zadanie – bo jak tłumaczyć terminy programistyczne na polski, ale nie wywiązał się z niego zbyt dobrze. Nie od razu dotarło do mnie znaczenie „obiekt wartości” czy też „logowanie łańcuchowe” czy jak mu tam.

Podsumowując – jeżeli ktoś uwielbia TDD i stosuje je wszędzie, proszę o kontakt. Komuś takiemu ta książka nie jest potrzebna, ale dałby on jej najwyższe noty. Dla sceptyków, biorąc pod uwagę powyższe, daję jej 4.5 w mojej skali ocen.