Ktoś sprzątać musi aby bałaganić mógł ktoś

Wszyscy zapewne pamiętamy burzliwą dyskusją Joela Spolskyego z Uncle Bobem (skrót na infoq)

Odbiła się ona szerokim echem dyskusji na ogólny temat: rzemiosło, profesja, jakość czy moźe lepiej byle jak, byle szybko, byle jako tako zadowolić klienta?

Kto ma rację?

Oczywiście ideałem byłoby dobrze i tanio. Ale jak intuicyjnie czujemy - tak to można tylko w mordę dostać;)

Prawda jak zwykle leży gdzieś po środku.

/*
 * W rozważaniach pomijam specyficzne przypadki typu
 * "firma nieustannie na dorobku"
 * albo specyficzny rodzaj dostawcy
 *
 * Zakładam, że bawimy się w projektach perspektywicznych
 * i jesteśmy świadomi zaciąganego kredytu bałaganu
 */


Ciekawą analizę tego zjawiska oraz racjonalne i pragmatyczne podejście do problemu przedstawił ostatnio w swojej genialnej (i jak zwykle niemiłosiernie ospałej) prezentacji sam guru DDD: Errrrrric Evaaaaans: Strategic Design - Responsibility Traps.

Poruszana tematyka zaczyna być omawiana od 30. minuty, ale gorąco wszystkich zachęcam do obejrzenia całości. Evans po mistrzowsku (i z typowym dla siebie poczuciem humoru) buduje od początku kontekst aby w 30. minucie wygarnąć nam co o nas myśli.
Wcześniej dowiecie się min. jakich strategicznych błędów nie popełniać podczas modernizacji systemu. Okazuje się, że standardowe 3 podejścia są z góry skazane na porażkę.

Prezentacja jest wg. mnie tak dobra, że w moim rankingu zajmuje miejsce 2. - zmieniając tym samym ostatnie notowania.


ZAŁOŻENIA (SAD BUT TRUE)
System jako całość nie może być dobrze przemyślany i zaprojektowany. KROPKA.
Nigdy nie będzie dostatecznie dużo: czasu, pieniędzy, wiedzy biznesowej, ludzi z odpowiednimi kwalifikacjami, czasu, pieniędzy, czasu, pieniędzy, czasu, pieniędzy,...

CO Z TEGO WYNIKA
Mamy 2 możliwości:
a) Wszystko zrobić "byle jak"
b) Pewną część zrobić porządnie i zgodnie z zasadami sztuki (oczywiście kosztem tego, że pozostała część będzie jakości mniejszej niż w punkcie a). W którą część i dlaczego warto zainwestować wysiłek - dowiemy się już za chwilę.

PROBLEM
Evans wytyka często spotykany problem. Ja nazwałbym go "złym rozłożeniem potencjału".
Evans opisuje taki oto często powtarzający się wzorzec: najlepsi (w sensie doświadczenia, intuicji, smaku a nie np certyfikatów) programiści/projektanci/architekci zajmują się tworzeniem tak zwanej "platformy". W zależności od systemu może to być wewnętrzny framework, główne biblioteki - ogólnie najczęściej są to jakieś zawiłości techniczne.

Natomiast reszta teamu - radośni hakierzy odpowiadają zwykle za dostarczanie corowych ficzerów biznesowych budowanych na bazie tejże tworzonej przez lokalnych guru platformy. Oczywiście ficzerów okraszonych zaokrąglonymi rogami w GUI - zgodnie z najnowszą modą żadna kanciasta forma nie jest dozwolona;)

Dostarczają oni funkcjonalności nazwanych przez Evansa sexy capabilities. Robią to tak jak potrafią, czyli byle jak byle szybko:)

Klient jest oczywiście zachwycony nowymi seksownymi możliwościami i nie zważa na marudzenie "nudziarzy od platformy", którzy narzekają, że znowu muszą sprzątać. Zresztą... po co sprzątać skoro działa?
Hero of the day to ten, kto zrobił zaokrąglony guzik zwiększający obroty o 1%;)

Oczywiście przyrost bałaganu jest większy niż możliwości jego sprzątania i mamy problem...

ROZWIĄZANIE: DESTYLACJA
Kto jak kto, ale my Słowianie mamy doświadczenie w destylacji więc mógłbym sobie odpuścić ten rozdział;)




Pomysł Evansa polega na wydestylowaniu domeny corowej. Zacznijmy od tego, że Evans wyróżnia 3 klasy domen:

- Core Domain - są to te specyficzne aspekty biznesu, będące powodem dla którego w ogóle warto tworzyć system. Przykładowo to one warunkują przewagę klienta nad konkurencją, lub odróżniają go od innych. To właśnie w tym miejscu mieszkają "sexy capabilities".

I to właśnie w ten kawałek (a powinien być relatywnie mały) inwestujemy największy wysiłek umysłowy.

To tutaj jest miejsce dla całej artylerii sprawdzonych technik naszego rzemiosła: szczegółowa analiza, archetypy biznesowe, wzorce projektowe, narzut na hermetyzację domeny, narzut na otwartość na rozbudowę, narzut na testability...

Core powinien być dobrze uniezależniony od pozostałych domen, które z definicji są w jakimś sensie "mniej godne zaufania" (bo np niestabilne).

- Supporting Domain - dodatkowe ficzery, bez których jednak można się obyć. Ten kawałek systemu może nawet np outsourceować. Jego jakość z założenia może być niska.

- Generic Domain - specyficzne domeny typu podsystem fakturowania lub biblioteka do operowania na grafach. Najlepiej kupić/uzyć gotowe rozwiązanie. Pamiętając o unikaniu zależności ze strony Core Domain.


Dobrym przykładem ilustrującym relatywizm tego pojęcia w zależności do biznesu jest system komentarzy użytkowników wystawianych kontrahentom.
W ebay jest to corowa funkcja (bez niej nikt nie kupiłby niczego od nieznajomej osoby). Dla amazona to po prostu jakiś poboczny ficzer (supportig domain) - ludzie i tak kupią jeżeli czegoś potrzebują lub po prostu mają ochotę.

Pamiętajmy, że developerzy nie są w stanie (ba, nie powinni) określić co należy a co nie do Core Domain w konkretnym przypadku danego klienta. Określenie Core Domain to jedna z głównych rzeczy, którą trzeba z niego wydusić;)




Chyba już domyślacie się jakie rozwiązanie sugeruje Evans...
Core Team zajmuje się Core Domain.
Najważniejsza część systemu ma szansę być zrobiona zgodnie ze sztuką a członkowie tego teamu zyskują uznanie jako dostawcy "sexy capabilities":)


Mam nadzieję, że moja recenzja/streszczenie zachęci Was (a szczególnie managerów) do poświęcenia godziny cennego czasu na prezentację Evansa.
Ciekaw jestem co sądzicie na temat tego podejścia - liczę na dyskusję równie owocną jak ta z przedostatniego posta:)

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

Prowokacyjnie dodam, że Joel Spolsky stosuje jednak strategię "klasyczną". Flagowe oprogramowanie w ofercie firmy Joela: Copilot (soft dla helpdesku pozwalający na zdalną pracę na maszynie "petenta") to nic innego jak nakładka na OpenSourceowy projekt na licencji GPL ;PPP

Czyli ni mniej ni więcej: ktoś zrobił platformę a partacze Joela dodali "sexy capabilities" - a biznes chyba się kręci:)



I jeszcze druga myśl, która mi się nasunęła: Nierzadko występują takie przypadki, gdy naprawdę doświadczony developer w ogóle nie interesuje się pewną domeną biznesową. Po prostu uważamy (niebezpodstawnie) za interesują mniej więcej w takim samym stopniu jak zeszłoroczny śnieg. Wolimy zamiast tego skupić się na rozwoju w kierunku technicznym z uwagi na jego ogólność wynikającą z abstrakcyjności. Nic na siłę, każdy powinien znaleźć sobie optymalne zainteresowania...