Między krokiem piątym powstała luka, która została zasypana kolejnymi modułami i rozwojem aplikacji w nieoczekiwanym kierunku.

Krok szósty stał się teoretycznym rozwinięciem kroku piątego i pobożną listą życzeń. Krok piąty i pół stał się realną rozbudową systemu w oparciu o nie zawsze zgodne (solidne) praktyki. Wydaje mi się, że prędzej czy później część projektów, ze względu na czas, pieniądze, umiejętności czy też znajomość dziedziny problemu (stopień znajomości) przeobraża się w niesolidne rozwiązanie, które do długotrwałej pracy potrzebuje ciągłej refaktoryzacji i modyfikacji.

Krok piąty i pół stał się przykładem tej nie do końca negatywnej przemiany, bo nawet tu pozostały pewne części aplikacji będące solidnie zbudowane.

W moim przypadku przyczyną degradacji systemu stał się czas i „spuchnięta” architektura oraz ten tak zwany dług techniczny.

Do rzeczy. Krok piąty i pół opis.

Aplikacja maratonu otrzymała nowy moduł odpowiadający potrzebom biura zawodów „MarthonOffice”. Skupiającym się na usługach związanych z prowadzeniem imprezy i przygotowaniem zawodników do startu. Już na wstępie mogę dodać, że moduł ten otrzymał za dużo odpowiedzialności co skutkowała rozdmuchaną złożonością.

W warstwie aplikacji pojawiła się abstrakcja odpowiedzialna za ten moduł oraz pojawił się nowy model, który jednak nie ma odzwierciedlenia w Entity Frameworku. Po stronie bazy danych nowy schemat powstał w nim został utworzony widok główny oraz nie co później procedura. Model oparty o ADO.Net i nieśmiertelne  obiekty DataTable mapowane na klasy odpowiadające strukturze widoku.

Odpowiedzialność  modułu.

Tak jak wspominałem moduł odpowiada za biuro maratonu, do jego funkcji należą:

  • wprowadzenie opłaty za zawodnika
  • nadanie numeru, dołączenie do listy startowej
  • zmiana dystansu
  • start z listy
  • generacja certyfikatu
  • deaktywacja zawodnika (opcja niedostępna z interfejsu)

Logika tego modułu w znacznej mierze zostła przerzucona na bazę (procedury składowane) interfejs pozostał jedynie wykonawcą rozkazów bazy i nie posiada on zbyt dużej logiki. Czyli schemat od którego się odchodzi w dzisiejszych czasach.

Dlaczego jednak się zdecydowałem się na procedury? Dla mnie jest to droga szybsza i łatwiejsza do testów, nie zostało zbyt wiele czasu do startu, pracy nie ubywa.

Wielce jest prawdopodobne, że ta edycja będzie pierwszą i ostatnią dla tej aplikacji. Z tego względu końcówka tworzenia systemu poniosła z tego tytułu ofiarę w postaci gorszej jakości kodu.

Pierwsze wnioski

Czytając książkę Erica Evans-a o DDD zdaje sobie sprawę z pewnych błędów popełnionych na etapie projektowania modułów ale na zmianę tego jest już zapóźno. Najpoważniejszym błędem stały się nazwy poszczególnych części systemu, które to nazwy powinny opisywać zakres odpowiedzialności modułów, a czego nie robią w pełni. W dłuższej perspektywie używania (rozwijania ) prowadziło by to do chaosu w aplikacji. Kolejna sprawa to zakres odpowiedzialności poszczególnych części systemu, które są albo za dozę albo błędnie rozeznane. Na sam koniec pozostała kwestia warstwy abstrakcji oraz modelu, który miał być siła tego rozwiązania a stał się ciężarem i do tego zmutował przez zastosowanie w taki sposób ADO. Samo ADO nie było by takie złe ale nie za bardzo się wpisuje w tę warstwę gdzie króluje EF.

Moduł dostępu do danych z pominięciem EF-a powinien być osobny ale chciałem zachować pewną konsekwencję i wpisałem to do tej warstwy, powinny być dwie równoległe np o nazwach „abstract_and_model_layer_EF” i „abstract_and_model_layer_ADO”, myślę że to było by roziwązanie znacznie upraszczające ten i tak duży chaos.

Kolejny wniosek który mi się nasuwa to, że moduł „marthonOffice” powinien być fasadą na inne moduły, było by ciekawsze rozwiązanie ułatwiające rozszerzenie tej części systemu ale w tym momencie idziemy w kierunku części szóstej, prawdopodobnie właściwej aczkolwiek już nie realnej części.

Ten powyższy tekst był pisany tuż przed głównym testem aplikacji, czyli wdrożeniem na produkcje u mnie produkcja oznacza obycie się zawodów. To było tydzień temu i tak aplikacja którą przygotowuje cały rok, działa tylko trzy dni, a potem zostaje zatrzymana. Oczywiście część związana z rejestracją zawodnika działała znacznie dłużej bo została uruchomiona w październiku 2018.

Jak oceniam  tę edycje? Tworząc ją od zera chciałem żeby była to najlepsza część jaka powstała (co roku mam takie marzenie) ale jak to zwykle bywa nie wszystko się udało, pod sam koniec, jak wspominałem wyżej, jakość rozwiązania nie co straciła. Ta edycja została zamknięta pozostał pewien niesmak w postaci zbyt uproszczonych wyników, które w założeniu miały być proste, zarazem czytelne, a stały się proste i nieczytelne. Na plus muszę zaliczyć to, że nie musiałem już przesiadywać całej nocy w managmencie sql jak w latach poprzednich i na bieżąco łatać niedoróbki insertami i updatami na „produkcji”.

Kolejna nie doróbka to start z listy, który dodałem do interfejsu i świetnie się sprawdził ale zawierał jeden mały szczegół który psuł wszystko, tym szczegółem było brak wyświetlenia zawodników z listy do startu. Dopiero po wystartowaniu na interfejsie pojawił się wynik z zawodnikami którzy wystartowali.

Pora na plusy.

  •  zarządzanie w module „marathonoffice”, dzięki, które bardzo proste stało się dodanie nowego zawodonika. Samo dodanie uprościłem maksymalnie i zamykała się w podaniu imienia nazwiska, mejla oraz dystansu, co było wystaczające do tego aby zawodnika mógł wystartować w maratonie (nawet mejl mógł być domyślny).  Z lat poprzednich wiem, że ilość czasu poświęcona na zawodnika przychodzącego do biura zawodów powinna być jak najmniejsza, żeby nie było kolejek i zatorów. W biurze zawodów pomagały mi żona i szwagierka (dzieci też zostały zaangażowane), maraton stał się rodzinną imprezą.
  • oprócz dodawania zawodnika, była też metoda opłaty zawodnika zintegrowana z przydzieleniem numeru oraz dodaniem do grupy startowej, te dwie czynności były rozwiązane za pomocą procedur składowanych z których jestem niezwykle zadowolony, zadziałały w sposób prawidłowy i mnie nie zawiodły
  • generowanie certyfikatu – każdy zawodnik po ukończeniu swojego dystansu otrzymywał certyfikat, zawsze był to probelm ale nie wtej edycji, bo w tej edycji zrobiłem widok dzięki któremu (widok z logiką) obliczane były rzeczywiste dystanse, do tego wrócę w osobnym poście bo ten temat zasługuje na osobny artykuł.

Szósta edycja została zakończona, historia zatoczyła koło i znalazłem się w tym samym miejscu gdzie byłem sześć lat temu. Część webowa mojej aplikacji za miesiąc przestanie istnieć (koniec hostingu), wtedy kod też wrzucę na githuba (hasła pousuwam). Odpowiedzialnośc za część webową spoczywa teraz na innej osobie, aplikacja do pomiaru czasu w tej formie która jest teraz musi także przestać istnieć.

Zakończenie

Sporo czasu spędziłem z tym tematem, wyszedł przydługi artykuł, nie ostatni pewne rzeczy wymagają głębszej analizy co też mam zamiar uczynić ale w innej kategori. Bo ta jest już zamknięta nowej architektury już nie będzie, a ten post jest zakończeniem tego działu i jego podsumowaniem.

Aplikacja do Obsługi Maratonu Rowerowego 04-2013 – 07-2019.

Historia:

Maraton historia – wersji aplikacji było sześć nie siedem gdyż szósta była rozwinięciem piątej ( nie powinna mieć swojej cyfry).