Głuchy telefon - intrygująca i dająca do myślenia zabawa z dzieciństwa, gdzie nawet bardzo prosta "informacja" może zostać zniekształcona po przejściu przez łańcuch "przekaźników".
Kultowy obrazek z huśtawką (który wszyscy znamy) obrazuje co dzieje się z informacją nieco bardziej wyrafinowaną (np. na temat wymagań) w procesie produkcji softu.
Jak temu zapobiec?
Racjonalnym rozwiązaniem jest Ubiquitous Language - kluczowa technika w Domain Driven Design polegająca na operowaniu wspólnym słownictwem domenowym na każdym poziomie abstrakcji: począwszy od eksperta biznesowego po kod źródłowy (sic!) w warstwie logiki aplikacji i logiki domenowej. W logice domenowej oczywiście obowiązuje ścisła "etykieta" - korzystanie z dobrze zdefiniowanych Building Blocks.
W tym miejscu dochodzimy do sedna posta.
Zachęcam do zapoznania się z prezentacją mego guru - Erica Evansa: "Sustainable Design for Agile Teams" podczas, której mamy próbkę sesji analitycznej pomiędzy programistą a ekspertem domenowym. Zwróćcie uwagę na dobrze zdefiniowany, wspólny język jakim posługują się obie strony oraz w jaki sposób "odkrywają" nowe byty.
Oczywiście taki proces nie jest tani oraz wymaga cennego zasobu: eksperta domenowego:/
//===========================================
Prezentacja porusza również inny, arcyważny aspekt: niezrozumienie projektowania domeny w naiwnym podejściu do Agile. Kiedy skupiamy się na pojedynczym wymaganiu lub na pojedynczej iteracji, wówczas zwykle mamy do czynienia ze specjalnym przypadkiem procesu biznesowego w jakiejś domenie. Gubimy "biger pikczer" i z czasem całość sprowadza się do radosnego (później smutnego) "hakowania" kodu opisującego jakieś specjalne przypadki - zaszłości. I nie ma co się oszukiwać - nikt nie jest skory do refaktoringu modelu domenowego, który jest już napełniony danymi w bazie:)
2 komentarze:
Zgadzam się, że naiwnym podejściem jest ignorowanie "big picture" i przejście bez "zbędnych ceremonii" wprost do dzieła. Jeśli mamy pewność, lub poparte wyrobioną intuicją przeświadczenie o kształcie tego szerszego kontekstu, czystą głupotą jest z tej wiedzy nie korzystać.
Z drugiej strony, niestety bardzo rozpowszechnionym błędem jest zgadywanie owego "big picture" (który potem wyłania się całkiem inny), lub sztuczne naginanie problemu do posiadanej już wiedzy, czy wręcz produktów posiadanych w portfolio (pracownicy niektórych dużych firm wiedzą, o czym mówię ;)). Prowadzi to wprost do wykładniczego wzrostu złożoności przypadkowej projektu i generuje znacznie więcej problemów, niż rozwiązuje - stąd bardziej doświadczeni ludzie trzymają się praktyk takich jak:
- KeepItSimpleStupid
- YouArentGonnaNeedIt
- DoTheSimplestThingThatCouldPossiblyWork
- stosowanie Brzytwy Occama
Zalecenie Agile, aby zachowywać prostotę bierze się właśnie stąd oraz z tego, że zmiany są i tak nieuniknione.
Przy okazji, jeśli komuś sprawia zasadniczą trudność refaktoryzacja kodu lub zmiana schematu baz to ma problem :| Refaktoryzacja jest najczęściej utrudniana właśnie przez niezachowanie prostoty (musimy się wówczas troszczyć o nie-psucie nieużywanych features). Mówiąc o bazach, dostępnych jest teraz wiele takich, które nie mają problemu migracji schematu, np. dlatego, że pojęcie schematu w nich nie występuje :) (CouchDB, Mongo, ...) Ludzie wrzucają potem z nich dane offline-owo do bazy relacyjnej tylko na potrzeby raportowania (jak w koncepcji ReportingDatabase opisany przez M. Fowlera) - oczywiście każdy kij ma dwa końce i nie ma srebrnych kul. Wpominam tylko po to, aby uzupełnić perspektywę i nie zawężać dyskusji tylko do typowego stacku JEE.
Zgadam się ze wszystkim. Z tym, że zwykle "typowy stack Java EE" jest nie do ominięcia z różnych względów:/
Prześlij komentarz