Uproszczenie aplikacji, ucieczka od

W apce od strony frontu mam zdarzenia generowane przez:

• ui (np. kliknięcie buttonu)
• ws (np. gdy przyjdzie info, że ktoś kliknął button)
• logika (np. gdy spełni się warunek po którym leci zdarzenie)

w tym wszystko ma wpływ na wszystko (tzn. ui ma wpływ na logikę, logika ma wpływ na ui, logika ma wpływ na ws itd.)

Dla mnie to przepis na spaghetti.

Chciałbym zapytać czy na dzień dzisiejszy jest jakiś sposób, który pozwala to ogarnąć z tym, że nie chcę koncentrować się na dzieleniu wszystkiego w drobny mak, by później wertować po wszystkich powiązanych plikach.

Bardziej chciałbym, aby wszystko było bliżej siebie, żeby to jakoś finalnie uprościć. Chciałbym móc przepływ w aplikacji przeczytać jak skrypt wykonujący się linia po linii.

znowutosamo7 napisał(a):

W apce od strony frontu mam zdarzenia generowane przez:

• ui (np. kliknięcie buttonu)
• ws (np. gdy przyjdzie info, że ktoś kliknął button)
• logika (np. gdy spełni się warunek po którym leci zdarzenie)

w tym wszystko ma wpływ na wszystko (tzn. ui ma wpływ na logikę, logika ma wpływ na ui, logika ma wpływ na ws itd.)

Dla mnie to przepis na spaghetti.

Bardziej "potencjał", niż "przepis", jeśli się tego nie utrzyma w ryzach.

znowutosamo7 napisał(a):

Chciałbym zapytać czy na dzień dzisiejszy jest jakiś sposób, który pozwala to ogarnąć z tym, że nie chcę koncentrować się na dzieleniu wszystkiego w drobny mak, by później wertować po wszystkich powiązanych plikach.

Bardziej chciałbym, aby wszystko było bliżej siebie, żeby to jakoś finalnie uprościć. Chciałbym móc przepływ w aplikacji przeczytać jak skrypt wykonujący się linia po linii.

1. Odseparuj istotne elementy (logikę biznesową) od szczegółów implementacyjnych (json, protokół, http, biblioteki)
2. postaraj się znaleźć osie rotacji w aplikacji - miejsca które często się zmieniają razem, i połącz je. Znajdź też miejsca które zmieniają się niezależnie od siebie (np. jak zmienisz event "created" w ui, to czy zmieniasz też event "created" w ws? jeśli tak, to połącz je, jeśli nie to rozłącz je)
3. napisz testy automatyczne pod każdy odrębny event który wymaga innego handlowania.

Na 99% Twój front nie musi wiedzieć czy event przyszedł z WS czy z UI. Jeśli uważasz że musi, to to może być sygnał że Twoje eventy mają niepotrzebny tight-coupling na technologię.

znowutosamo7 napisał(a):

W apce od strony frontu mam zdarzenia generowane przez:

• ui (np. kliknięcie buttonu)
• ws (np. gdy przyjdzie info, że ktoś kliknął button)
• logika (np. gdy spełni się warunek po którym leci zdarzenie)

w tym wszystko ma wpływ na wszystko (tzn. ui ma wpływ na logikę, logika ma wpływ na ui, logika ma wpływ na ws itd.)

Dla mnie to przepis na spaghetti.

Po prostu zastanów się, co zrobić, żeby jednak flow danych był bardziej jednokierunkowy i konkretnie zdefiniowany.

np. ui ma wpływ na logikę - okej, ale czemu logika ma wpływ na ui? Pytanie, co to znaczy "wpływ", bo sam wpływ (widoczny dla użytkownika) może mieć, jeśli będzie to zapośredniczone przez jakiś dodatkowy mechanizm. Np. logika tylko powiadamia ui o zmianach za pomocą obserwatora, a nie wpływa bezpośrednio.

Myślę więc, że najpierw warto odizolować poszczególne moduły i przemyśleć o tym, jak płyną informacje po apce (no, jakbyś miał to sobie rozrysować strzałkami. Możesz zacząć od rozrysowania tego, co już jest, żeby wiedzieć, z jakiego punktu wyjścia startujesz). Być może powydzielać nowe moduły (np. jeśli masz cykliczne zależności A<-->B, to możesz wydzielić C, do którego wstawisz wspólne dla A i B rzeczy, wtedy A i B zamiast komunikować się bezpośrednio, mogą się komunikować przez C).

Może potrzeba będzie utworzyć dodatkowy mechanizm pośredniczący (jak u ciebie zdarzenia płyną? czy jest jakiś punkt zbierający te zdarzenia, czy sobie hulają bezładnie?)