Modifiability: Or is there Design in Agility?

Dziesiejszy poranek spędziłem oglądając kolejny film z InfoQ: “Modifiability: Or is there Design in Agility?“. Film ten jest nagraniem panelu dyskusyjnego z udziałem architektów ThoughtWorks pod przewodnictwem Martina Fowlera, przeprowadzonego na konferencji QCon w listopadzie 2007 roku.

Oto fragmentaryczne notatki z prezentacji:

David Farley, rozpoczynająć dyskusję na ten temat, dzieli się swoją definicją OOP/OOD: obiektowe techniki programowania są sposobem na symulowanie problemu, który to oprogramowanie ma rozwiązywać.

Symulacja problemu zbudowana na podstawie wymagań pozwala współdzielić z klientem proces zmian modelu. Oznacza to, że kiedy klient zmieni zdanie, zmieniając model swojego biznesu, nasza symulacja będzie wymagać niewielkich zmian. Co ważne, będziemy mieli dokładne informacje, które części wymagają zmiany, ponieważ nasz model zbudowany jest na bazie tego samego, wspólnego języka. Z drugiej strony, gdybyśmy oparli swoje rozwiązanie na podstawach czysto technicznych, nie byłoby możliwości powiązania zmian w biznesie ze zmianami w symulacji. Szybki wniosek z tej opowieści: Trzymaj swój model tak blisko modelu biznesu, jak to tylko możliwe.

Model domeny powinien być wolny od kwestii technicznych, aby móc podążać za zmieniającym się modelem biznesu.

(Z późniejszej części prezentacji) Ideałem dla Farley-a jest kod tak czytelny, że osoba nieteczniczna potrafi zrozumieć jego ideę. Sposobem na osiągnięcie tego idału jest maksymalna enkapsulacja.

Dla Dan-a North kluczem w Domain Driven Design jest odkrycie, jak wygląda model biznesu, i przetłumaczenie go, najwierniej, jak to możliwe, na działające oprogramowanie. Dzięki DDD unikamy słynnego dylematu z odraczaniem decyzji do ostatniego dobrego momentu. Decyzja o tym, jak wygląda model biznesowy została zwykle podjęta przez naszego klienta 10 lat temu i nowe oprogramowanie jej nie zmieni. Jego zadaniem jest jedynie usprawnić wykonywanie tego modelu.

Martin Fowler, podsumowując, stwierdza, że często najważniejszą kwestią jest podjęcie decyzji o tym, kiedy należy podjąć tę czy inną konkretną decyzję.

Dan North opowiada o projekcie, w którym decyzja o tym, co zrobić, jeśli baza danych przestanie działać, została ostatecznie podjęta wiele tygodni po rozpoczęciu prac. Efektem było rozpoczęcie budowy tymczasowego, zawsze dostępnego, magazynu danych. Ukończenie prac na czas było możliwe dzięki zastosowanie procesu TDD oraz całkowitej automatyzacji testów akceptacyjnych, ponieważ osoby budujące nowy moduł mogły w dowolnym momencie sprawdzić, czy nie zepsuły działania istniejącej aplikacji. TDD jest więc swego rodzaju ubezpieczeniem na wypadek zbyt późno podjętych decyzji.

Eric Doernenburg podaje przykład swojego projektu, jako lekcję jak rozpoznawać ostatni dobry dla podjęcia decyzji moment. W jego przypadku była to decyzja dotycząca charakteru (WWW, standalone) aplikacji zasilającej bazę danych. Na początku baza zasilana była plikami Excel, później, gdy oczekiwania wzrosły, zastosowano proste strony HTML. Osteczną decyzję wciąż odkładano, ponieważ dotychczasowe rozwiązania wiązały się z niewielkim nakładem prac. Kiedy okazało się, że te proste strony się nie sprawdzają, postanowiono wreszcie podjąć decyzję. Zrobiono to, ponieważ każda z potencjalnych opcji (jeden z toolkitów JS, klient Swing) wiązała się z tak dużym nakładem pracy, że dalsze odkładanie decyzji byłoby już marnotrastwem.

Mam nadzieję, że tą krótką notatką zachęciłem Was do obejrzenia prezentacji. Naprawdę warto!

VN:F [1.9.13_1145]