Temat: Microsoft obiektowo - Using Models within the Development...
Popieram zdanie Pana Żelińskiego, że dokumentacja musi być zrozumiała dla całego zespołu produkcyjnego. Jeśli już tak obszernie posługujemy się analogią do budownictwa, to chiński architekt nieznający żadnych języków oprócz swojego nie wytłumaczy robotnikom gdzie mają stawiać ściany, gdzie są okna itp. Do tego mają swoje rysunki i opisy - jednolity zapis pozwala na jednoznaczne zrozumienie nad czym wszyscy mają pracować. Dlatego też powstały diagramy DFD, ERD, powstał opis UML jak i wiele innych.
Jednakże nic nam będzie po opisie, jeśli nie będziemy otwarci na modyfikacje lub tez zmiany. Dlatego też od dłuższego czasu tak popularne stały się metodyki Agile ( Xp, AUP, EUP ), w których dość jasno oparto się na doświadczeniu prowadzenia wielu projektów. Zbiór tychże metodyk również nie jest lekarstwem na wszystko. Pamiętajmy, że tak samo jak się zmieniają wymagania projektowe tak samo powinniśmy podchodzić do metodyki wytwarzania oprogramowania. Dzięki czemu sam staram się tam gdzie mogę stosować połączenie XP z RUP oraz Scrum, do tego czerpię inspirację z PMI plus PRINCE2.
To, co jest najważniejsze jednak, to że niestosowanie żadnej metodyki prowadzi do chaosu oraz robienia wielu rzeczy wielokrotnie (prawie jak odkrywanie koła za każdym razem kiedy potrzebujemy coś cięższego przetransportować). Takie zwielokrotnienie w procesie wytwarzania czegokolwiek jest od razu skazane na porażkę konceptu dobrze prosperującej firmy. Stajemy się takimi osłami z klapkami na oczach, które to dany klient nam nakłada.
Metodyki są po to, aby nie dać się osiodłać, aby wskazywać rozwiązania i nie podążać nimi ślepo.
Dla mnie architekt powinien być jak najbardziej świadom pracy programistów, wiedzieć jak działa lub zachowuje się wybrana technologia oraz jakie ma bariery. Analityk w etapie opracowywania projektu musi wspierać się właśnie o wiedzę architekta systemowego jaki i analityka biznesowego danej domeny projektu. Najlepiej jest oczywiście posiadać wszystkie te wymienione umiejętności. Uzyskane w taki sposób rozwiązanie na pewno potrafi przeskoczyć niejedną przeszkodę lub ograniczenie - trafiając tym bardziej w pojęcie "nie da się zrobić". Jakbyśmy się jakiegoś matematyka 100 lat temu zapytali, czy będzie możliwe opracowanie takiej maszyny, która pomoże nam modelować nowe leki - z pewnością powiedziałby, że na 100% nie. A jednak się udało. Z każdym dniem ktoś opracowuje jakąś do tej pory niemożliwą lub unikalną technologię - tak więc nie lubię podejścia w projektowaniu lub wytwarzaniu, że czegoś się nie da. Zadaniem analityka jest znalezienie takiego obejścia oraz opracowanie w postaci modeli UML oraz i opisu słownego dla klienta.
Czy wyobrażacie sobie taką sytuację, w której to jeden programista twierdzi, że coś się da wykonać w 5 minut a drugi twierdzi ze albo się nie da lub będzie to trwało nie wiadomo ile? Sam byłem świadkiem wielu takich sytuacji. A o czym to świadczy? Jedynie o tym, że każdy inaczej podchodzi do różnych problemów czy zagadnień.
Czy DDD jest takie wspaniałe - z mojego doświadczenia dość dobrze sprawia się zamiast modelowania biznesowego projektu, jednakże równie dobrze analityk biznesowy z danej domeny klienta może być świadom pewnych zagrożeń lub ułatwień, do których jeszcze sam klient nie doszedł.
Prototypownie aplikacji ma swoje zalety, jednakże niewiele programów pozwala na dobre opracowanie ich. (np. raz spotkałem się z wykorzystaniem programu do przygotowywania prototypów stron internetowych, aby finalnie wykonać całą aplikację w flex). Dla procesów można również oprzeć się o OOWF, ale czy klient będzie w stanie ogarnąć o co chodzi? Trzeba wykorzystywać na pewno technologię czy też pisać dokumentację pod poziom klienta, aby miał świadomość, że operujemy tymi samymi pojęciami i poruszamy się po tej samej domenie zagadnień.
Podsumowując, jaką metodykę nie wybierzemy, należy zawsze wybierać z niej to, co najlepsze dla nas oraz dla zespołu i szukać nowych rozwiązań. Przecież każda metodyka ma swoje wady i zalety.
Ostatnio miałem przykład takiego "palącego się" do kodowania podejścia do projektu. Całość wyszła żałośnie. "Dokumentacja" była kłębkiem bezmyślnie postawionych kropek i przecinków, w której to wykorzystywane pojęcia by naprzemiennie wprowadzając jedynie chaos (np. słowo klucz pojawiało się w wielu kontekstach, przez co nie wiadomo, o który klucz za każdym razem chodziło). "Dokumentalista" ten twierdził, że zawarł wszystko, co trzeba, a programista drapał się po głowie zachodząc, co autor miał na myśli. Co gorsza, człowiek, który to opracował wdrożył jedną część(najpierw przed opisem lub w trakcie), która, jak się okazało, zupełnie nie pasowała ani do opisu API ani do wytworzonej przez programistę drugiej części.
W tej sytuacji właśnie najlepiej widać, jak ktoś pierw dotyka klawiatury i pisze kod, a przy okazji dokumentuje i przeprowadza analizę, a potem zastanawia się nad tym, czy to co zrobił ma w ogóle sens ( wyszło, że nie, ale to już opowieść na kiedyś indziej).
пропозиції роботи
