piątek, 5 czerwca 2009

Domain Driven Disaster

Przygotowania do prezentacji o DDD na LJUG w toku. Tymczasem mamy niecodzienną okazję aby zobaczyć jak w praktyce możne wyglądać projekt, którego jednym ze szczytnych założeń było podążanie za DDD.

Dziś pierwszy (i mam nadzieję, że nie ostatni) post z gatunku gościnnych.

Jako pierwszego mamy zaszczyt gościć tajemniczego Malory z krainy deszczowców, który podzieli się doświadczeniami z dużego, zagranicznego projektu. Projektu, w którym niestety nieco rozminięto się z filozofią DDD, TDD i Agile:

<post_goscinny>
Przyjemność bycia częścią projektu napędzanego czystym agilem (iteracje mamy, lecz do Agile nadal daleka droga), z domieszką domain driven, test driven, i ogólnie driven skłonił do podzielenia się kilkoma refleksjami. Tym gościnnym postem u Sławka podzielę się refleksjami o dysonansie miedzy filozofią którą niosą ze sobą ddd, Agile, TDD a praktyką... czyli Projektem.

O ddd Sławek pisał tutaj już nie raz i każdy z czytelników mniej lub bardziej "czuje' o co w ddd chodzi. Esencja to słowa z ddd.org: "ddd is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains". Nic dodać, nic ująć. Koncepcja a raczej filozofia spojrzenia na problem, na domenę. A w praktyce? Bywa różnie. Brak zrozumienia idei którą niesie ze sobą ddd, i twarde (beton) myślenie przez pryzmat aplikacji CRUD driven (formularzyki), gwarantuje Monthego Pythona każdego dnia. Sam wybór ddd nie zawsze jest szczęśliwy bo jak wyraźnie wskazuje cytat: "complicated domain". Więc po co się męczyć, i udawać ddd gdy chcemy zrobić nakładkę na db? Efektem końcowym będzie i tak mieszanka anemicznych encji i a'la serwisów żonglujących encjami w górę i w dół. W praktyce ddd niebezpiecznie zbliża się do kilku „warstewek” klas delegujących wywołania metod z dao. I nie ma w tym nic złego – to rozwiązanie dobiera się do problemu. Nie odwrotnie. Sama sytuacja w której kończymy z pustymi encjami (@Entity, nie żadne tam encje ddd) i serwisami wskazuje że coś jest nie tak. Fundament OOD jest prosty – odpowiedzialność a get/set to chyba jednak trochę za mało...

Siłą napędową ddd to domena, co w odniesieniu do projektu oznacza eksperta domeny, będącego światłem w tunelu dla zespolu. Jako ze projekt nie zawsze ma domain eksperta - bywa śmiesznie. Developerzy to cwani ludzie i dadzą radę, ale to raczej Developer Driven Design (co oczywiście nie jest złe.. ale zależy od doświadczenia zespołu...). W przypadku bogatej domeny, bez pomocy eksperta wątpliwe jest stworzenie nawet poprawnych zrębów domeny, nie wspominając nawet o niuansach i bliższym nakreśleniu relacji w domenie. Pora teraz na agile (fonetyka naszego rodzimego języka, nie żaden tam edżajl).

Skomplikowana domena powoli ewoluuje, nieraz zamiast ewolucji doświadczyć możemy rewolucji, gdy powolny knowledge crunching zaowocuje przełomem w spojrzeniu na domenę. I czy nie jest to "Responding to change over following a plan" który niesie ze sobą agile manifesto? W tym momencie przypomina mi się pytanie podczas jednego z pierwszych spotkań (spotkanie a raczej meeting jest nieodzownym elementem każdego poważnego agile projektu), a mianowicie "kiedy dostaniemy skończony model domeny?". Hmm - odpowiedź była prosta: nigdy. Po czym zaczęło się wyjaśnianie (okraszone nerwowymi spojrzeniami "góry"), że to nie waterfall. Same iteracje nie sprawią, że będziemy Agile. Do tego potrzeba tzw. bigger picture i zmuszenie całego zespołu (łącznie z managementem) do innego spojrzenia na problem. Iteracje i milestony mogą być jednak wystarczającą dawką agilu. O tym, że to wymagania napędzają development niekoniecznie się pamięta. Zresztą, bywa w niektórych projektach że wymagania odpowiadają poziomem testom (assertTrue(true)); //FIX LATER, its friday, 4 o'clock ). Raz zrobiony task (zrobiony w stylu general concept, bo jak inaczej bez wymagań...) zostaje jako skończony i nie ma nawet mowy o refaktoringu pózniej... To przecież zbędne filozofowanie... W wyniku zostaje brązowa (flagowy kolor branży) papka kodu którą ktoś (nieszczęśnik, albo student, niewolnik IT) będzie miał przyjemność poprawiać. Domena zamiast ewoluować - kostnieje, zamiast odpowiadać na zmiany - napierdalamy aby zdążyć w terminie.

Ostatnim kawałkiem układanki jest TDD. Który doskonale wpasowuje się do mieszanki DDD i Agile. Domena powinna ewoluować, dojrzewać, i odpowiadać na zmiany. Tutaj pomocną rączkę wyciąga TDD. Pod warunkiem że napisane testy mają sens. W życiu bywa jednak rożnie, w praktyce testy nie zawsze testują. Mądrze napisane uspokajają sumienie i pozwalają pracować nad aplikacją. Pozwalają na eksperymentowanie i dają ujście wiedzy którą powoli team zdobywa. Testy trzeba jednak umieć pisać.. i mieć na nie czas. Z pierwszym bywa rożnie, na drugie niekoniecznie jest czas w schedule projektu. Efekt - każdy boi się panicznie dotknąć czegoś większego w domenie aby całość się nie rozleciała...

Na koniec link do doskonałej prezentacji o... samochodach. Obejrzyj i popatrz przez pryzmat naszej branży. Tutaj też są projektanci i inżynierowie. W tej branży jest miejsce na pasję, rzemiosło i jakość. Uwolnijmy się od brązu.



</post_goscinny>



//=======================================

Jak wiadomo najlepiej uczyć się na błędach:) Dobrze, gdy mamy okazję z dystansu przyjrzeć się cudzym:]
Potwierdzają się moje przemyślenia na temat metodyk Agile. Idea piękna, ale pod warunkiem, że mamy dojrzały i świadomy zespól profesjonalistów, którzy wiedzą co robią lub przynajmniej mogą poprowadzić duchowo resztę teamu.

Sama filozofia DDD o ile nie jest jakoś specjalnie wysublimowana to niestety posiada pewną barierę wejścia: podstawy OO - i nie mam tu na myśli składni dziedziczenia, lecz myślenie obiektami.

7 komentarzy:

Stronnice Chlebika pisze...

Fajne te posty, jakze zyciowe :) Natomiast gdybys mogl kiedsy napisac dluzsego posta o tym, co w tym zostalo zasygnalizowane - mianowicie o umiejetnosci pisania testow. Nie jest to rzecz, ktorej da sie nauczyc z tutoraiala dotyczacego JUnit.

Łukasz Lenart pisze...

Do nauki TDD przez zabawę polecam TDD Randori Session. Na początku nie jest to łatwe, ale jak się załapie to zabawa przednia.

Sławek Sobótka pisze...

@Chlebik - tak szczerze, to noszę się od jakiegoś czasu z chęcią napisania posta o testach. I masz rację - pisanie dobrych testów nie jest proste. Jeszcze trudniejsze jest pisanie kodu podatnego na testowalność (testablility). A jeszcze trudniejsze jest wybranie kodu, ktory trzeba/warto/nie warto testować - wiadomo: czas to niestety pieniądz:/

Musiałbym jednak opisać mój niepoprawny politycznie pogląd na bezmózgowe testowanie. Zamiast tego preferuję racjonalnie podejście do sprawy - czyli takie gdzie testy rzeczywiście mają sens (ba, są wręcz nieodzowne).

Niestety żona nie pozwala mi już pisać niepoprawnych postów;)

@Łukasz - dzięki za wskazanie Randori

Aleksander Brancewicz pisze...

@slawek
"Czas to niestety pieniadz.." i wlasnie dlatego nie wolno pisac kodu bez automatycznych testow. Mozliwosci zespolu rosna przerazliwie i mialem okazje sam tego doswiadczyc w jednych z agile projektow.
Przepraszam ze byc moze wypadne jak burak z zaswiatow ale w Holandii przynajmniej na tyle na ile wspolpracuje z dwoma firmami testy automatyczne sa tak elementarna podstawa jak w polsce tester clicker. Jasne ze testy trzeba pisac w sposob przemyslany np. zachowujac zasade niezaleznosci testu (test A nie zmienia danych tak aby test B mogl sie odbyc) itd. Mimo wszytsko kilka dni studiow i prob z JUnit jest duzo bardziej warte niz E2E manual testing horror

ToJaJarek pisze...

Sama filozofia DDD o ile nie jest jakoś specjalnie wysublimowana to niestety posiada pewną barierę wejścia: podstawy OO - i nie mam tu na myśli składni dziedziczenia, lecz myślenie obiektami.

Ale chyba OO to podstawowa kompetencja w procesie, bo w przeciwnym wypadku mozna by powiedzieć "wyjazd autostopem do Angli to super pomysł ma jednak barierę wejścia - trza znać ankgielski" .. no trza znać, trza...;)

Sławek Sobótka pisze...

Tak Jarku, podstawowa. Ale co z tego, że Ty to wiesz, i że ja to wiem:/
Rzeczywistość jest taka, że każdy kto jest w stanie jako tako japisać pętlę;) czy narysować prostokąty połączone kreską jest kwalifikowany do procesu.

Anonimowy pisze...

"agile" polską fonetyką? Ciekawe. O ile mi wiadomo, to w języku polskim nie ma takiego słowa :|