… lata 80, Simple Minds i ich klasyczny Alive and Kicking (specjalnie w wersji koncertowej).
Długo mnie tu nie było, zaniedbałem i tak wąskie grono czytelników, blogosferę i Googlebot’a. Jednak nieobecność w sieci nie oznacza, że całkiem zaniedbałem moje “pisarstwo” ani też że zapadłem w sen zimowy.
W międzyczasie zmieniłem pracę, eksplorowałem Europę Północną, przeżyłem morderczy “after” po pierwszej edycji odswieżonej confitury, oraz rozpocząłem doktorat z JBoss 4.2.3 GA.
Zamknąłem się w mojej małej przestrzeni, przy nowym biurku z widokiem na Kraków i jak mantrę powtarzam mvn clean package, run i kolejne przekleństwo przez zaciśnięte zęby i git reset.Wyłączyłem Google Reader, InfoQ i jeszcze kilka innych “dysturbatorów”. Jedyną rozrywką jest utrzymanie przy życiu szczytnej idei “zero inbox”.
Dla jasności, kod z którym pracuję nie jest zły, koszmarny, nieczytelny czy też fatalny. Nie jest też tak, że zawiódł moje oczekiwania, rozczarował i pogrążył w czarnej jak espresso rozpaczy. Człowiek już wie czego się spodziewać, akceptuje fakt, że klient Panem jest i basta. A czystość rasowa kodu, jego koszerność pozostaje w sferze piwnych dumanek w papierosowym dymie.
Cóż więc pcha mnie do późnowieczornych przemyśleń? Od jakiegoś czasu żyję sobie poza nurtem TDD, BDD, DDD oraz Software Craftsmanship (obecnie te zabawki całkiem nie pasują do mojej piaskownicy). I uświadomiłem sobie jak trudno mi się pracuje bez tych narzędzi, jak bywało ciężko gdy mogłem z nich na co dzień korzystać i jak jeszcze ciężej jest przetrwać bez nich (być może to tylko kwestia przyzwyczajenia). Obecnie gołymi rękami dekomponuje strukturę kodu, dokonuje destrukcji lokalnych zależności, demotywuje kolejne warstwy aplikacji oraz demontuje stosy fałszywych założeń i prawd uznanych. Moja natura nie pozwala mi jednak zaakceptować stanu rzeczy zastanych i próbuje zrozumieć motywacje i kontekst.
Próbuje nie wyszukiwać winnych (git log nic nie zmieni), zakładam dobrą wolę twórców, niejasne wymagania oraz presję czasu. Gdzie więc tkwi przyczyna? W JBoss AS. Nie odbierajcie tego zbyt osobiście. To równie dobrze mógłyby być Spring Framework, OSGi, Grails czy też domowej roboty, szyta na miarę platforma.Każda platforma/framework czy też innej maści zwierz niesie z sobą początkowy dług techniczny.Myślicie, że JBoss nie ma długu technicznego, a kod jego czysty jak przysłowiowy kieliszek “wyborowej”? Przestańcie się łudzić, każdy kawałek kodu który powstał jest obarczony mniejszym czy też większym długiem.
Jest też inna kategoria zadłużenia która pojawia się wraz z wyborem “tego jedynego rozwiązania”. Nasz brak kompletnej wiedzy o wybranej technologii, braki w dokumentacji, nieaktualne “samouczki”, rzeczy o których twórcy nie chcą głośno mówić i “cudowne” rozwiązania dostępne w sieci. Czyli to co Dan North tak ciekawie przedstawił w “Deliberate Discovery”. Naszym długiem jest to czego nie wiemy, że nie wiemy :). I tym sposobem rzeczy proste, przewidziane w platformie oplatamy “hackami”, aspektami, modyfikowanymi bibliotekami aby tylko związać koniec z końcem i wypuścić naszą aplikacje.
Oczywiście można tu by jeszcze dorzucić kamyczek o naszej ignorancji w obszarze danej domeny biznesowej ale na obecnym etapie nie mam zamiaru zakładać stryczka sobie samemu na szyje.
I docieramy do sedna problemu. Jak ważny jest wybór naszej docelowej, jedynej i ukochanej platformy? Moim zdaniem nie ma to zupełnie znaczenia, i tak bez względu na wybór zaciągamy dług techniczny jeszcze przed napisaniem pierwszej linijki.I będziemy zadziwiać przyszłe pokolenia naszą ignorancją. Nasz dług będzie rósł z każdą nową wersją JBoss’a,Spring’a do której nie będziemy mieli czasu przenieść naszej aplikacji. Teoretycznie ignorancja twórców rzeczonych platform będzie malała z każdą nową wersją. Więc z czystego rachunku wynika, że w naszym interesie jest nie pozostawanie w tyle. Tylko kto ma na to budżet? Lepiej się zadłużyć i tak nie będzie to widoczne na corocznym sprawozdaniu finansowym.
Co ciekawe nie wypracowaliśmy jeszcze jasnego i efektywnego podejścia do tego typu problemów (mowa o “legacy code, archiecture and design”). Wiem, że zarzucicie mnie zaraz uwagami o mojej czytelnicznej ignorancji. Ależ tak, czytałem “Working with legacy code” i “Refactoring to patterns”. Jednak każda taka aplikacja z którą przyjdzie wam pracować jest unikalna w zestawie wymóżdżeń którym poddali się jej twórcy. I dlatego uważam, że jeżeli szukacie prawdziwych wyzwań, intelektualnych puzzli i pracy która przyniesie wam fale uniesień i lawiny upadków, poszukajcie jakiegoś “legacy” systemu. Osobiscie uważam, że żadna nowa, pisana od zera aplikacja, w najnowszych “framełorkach”, językach niezwykle dynamicznych, dających wam w ręce “ostre” narzędzia nie sprawi tyle przyjemności i dumy z dobrze wykonanej roboty jak porządny “legacy” oddany w wasze ręce do wyprostowania. Dlaczego? Zapytacie?
Albowiem aplikacja taka dobrym “hackiem” stoi.To nie TDD, BDD, DDD oraz Software Craftsmanship acz HFDD (Hack it and Fuck it Driven Development). Nowy lepszy paradygmat:)
Przyszłością IT jest, ku trwodze i ogólnemu zgorszeniu, programistyczna archeologia. A przecież to dzięki archeologii dowiadujemy się o przeszłych pokoleniach, i ich zwyczajach, rekonstrujemy bieg wydarzeń, poszerzamy swoje doświadczenia i przez to stajemy sie lepsi. Czasami też odkrywamy dawno zapomnianą technologię, i gdy widzimy, że jest dobra, naklejamy nową naklejkę i sprzedajemy jako przełomowe odkrycie
geekyprimitives 