Gdzie kończy się CRUD, a zaczyna kompleksowy system informatyczny?

2

tak jak w tytule

Gdzie kończy się KRÓD jako synonim small scale, not complex system design, a zaczyna kompleksowy system informatyczny? :)

1

A jak system, który zapisuje nasze pesele to crud to nie jest kompleksowy?
Myślę, że crud może być kompleksowy - sam w sumie pisałem taką aplikację, typowego cruda i nie mogę powiedzieć, że nie było to w pewnym sensie złożone.

1

Nie ma i nie będzie precyzyjnej definicji.

Ale jeśli chcesz to moment, w którym czujesz potrzebę pisania testów.

2
WeiXiao napisał(a):

tak jak w tytule

Gdzie kończy się KRÓD jako synonim small scale, not complex system design, a zaczyna kompleksowy system informatyczny? :)

Zapewne w momencie zapłaty / negocjacji o stawkę xD

jak coś się nazwie "kompleksowym systemem informatycznym" to mądrzej brzmi i jak coś, za co można zakosić grubą kasę.
A CRUD to idź pan, student zrobi coś takiego za kilka stówek.

BTW to mój 4001 post :)

3
danek napisał(a):

Nie ma i nie będzie precyzyjnej definicji.

Ale jeśli chcesz to moment, w którym czujesz potrzebę pisania testów.

O.o Ja nawet w prostym crudzie nie wyobrażam sobie pominięcia testów.

2

Ja bym wyszedł od strony funkcjonalności oraz architektury. Wg mnie taki typowy CRUD jest jakby nakładką na bazę danych. Jeśli apka się sprowadza do odczytu i zapisu danych (np. program do prowadzenia magazynu albo baza danych klientów) to mowimy o czymś prostym. Nawet, jeśli ma kilka dodatkowych opcji, takich jak możliwość wydruku albo praca na wielu stanowiskach, to nadal jest krudżem.

Z kolei coś podobnego, ale mające poza magazynem jeszcze możliwość fakturowania, księgowość, moduł kadrowy itp, już raczej będzie systemem złożonym. Celowo napisałem o "module kadrowym", bo to też ma znaczenie przy ocenie złożoności systemu. Może użytkownik końcowy tego nie widzi, ale w zależności od zastosowanej architektury, funkcjonalność może być wkpmpilowana na sztywno, albo możemy mieć budowę modułową, jakieś API, resty, DI itp. Jeśli twój system ma coś takiego, to wiedz, że nie jest CRUDem ;)

4

Jak dla mnie im więcej z poniższych jest spełnione

  • coś jest mocno powtarzalne
  • klepię kod właściwie rutynowo
  • określenie tego "przelotką do bazy"/"skórą na bazę" niemalże wyczerpuje temat
  • pisząc to mogę przestawić mózg na niskie obroty i wciąż ma puste cykle
  • praktycznie wszystkie potencjalne problemy i trudności rozwiązuje "magia pod spodem" której nie tykasz
  • walidacja jest nieskomplikowana np. sprowadza się do jakichś prostych sprawdzeń duplikatów, zakresów itp.
  • filtry są nieskomplikowane

tym większe prawdopodobieństwo, że mam do czynienia z CRUDem lub czymś CRUDo-podobnym :(

Co zatem nie jest CRUDem?

  • rzeczy przy których jest dużo niewiadomych, trzeba wymyślić jak ugryźć problem, można (a nawet trzeba) poeksperymentować
  • robienie "magii pod spodem", przy której to Ty musisz zadbać o te różne "trudności i problemy"
  • robienie rzeczy dla których nie masz gotowej "magii pod spodem", więc musisz zadbać sam o "trudności i problemy"
  • narzędzia, najlepiej żeniące ze sobą inne narzędzia itd. gdzie zawsze nawinie się jakiś dziwny problem do rozkminienia
  • ewentualnie jakieś bardziej złożone przypadki filtrowania/walidacji, przy których można trochę pomyśleć, zastanowić się nad przypadkami szczególnymi
3

Pytanie jest bez sensu.

Natomiast CRUDem w znaczeniu popularnym nazywam antywzorzec inżynierii oprogramowamoa osiągany gdy chłopaki z backendu posłuchają opowieści klienta, zamodelują zarąbiście domenę
nasrają encji, relacji, DTO, CTO, ETO, DBO, serwisów, kontrolerów i buldożerów i wystawią do tego API. Nie sprawdzając jak powinien działać front-end i czego potrzebuje. Bo przeciez frontem gardzimy...

Można to zrobić z dowolnie skomplikowanym systemem.

1
WeiXiao napisał(a):

Gdzie kończy się KRÓD jako synonim small scale, not complex system design, a zaczyna kompleksowy system informatyczny? :)

Zostałem zawołany, ale w ogóle nie rozumiem pytania.

  1. CRUD może mieć wielką skalę (liczba ekranów/formularzy wprowadzania danych) i być bardzo skomplikowany (kwestia dodania dodatkowej warstwy, albo dziesięciu).
  2. Kompleksowy system informatyczny, to mi się z ZUS kojarzy, ale pewnie nie o to chodziło (jeśli jednak o to, to odpowiedź brzmi: Prokom). Skomplikowany system informatyczny zaś to jakiś MRP, ERP czy inny CRM - i w nich też może być masa CRUDa.

CRUD to są moim zdaniem trywialne zadania związane wyłącznie z przechowywaniem danych w bazie, w dowolnej aplikacji może być ich więcej albo mniej. Im więcej, tym nudniej, chociaż z drugiej strony szybciej, bo wiele rzeczy można obsłużyć generycznie (no chyba, że się ma architektów i 15 warstw, ale wtedy nic nie jest proste ani szybkie).

3

Naprawdę poważne systemy zaczynają się kiedy programiście robi się ciepło jeśli słyszy, że ktoś wykrył błąd.

1

Słyszałem o systemie, który miał się składać z 20-30 różnych crudów. Niestety do pracy nad nim nie zatrudniono studentów, którzy będą się cieszyć że piszą coś od początku. Zatrudniono seniorów i architektów. Teraz klient ma generator crudów. Czy taki system zyskuje już prawo do bycia nazywanym skomplikowanym systemem?

1

Kiedyś, w jednym systemie zarzuciłem, że za dużo tego DTO, CTO, ETO, DBO UC, stworzyli i IMO nie będzie się tak dało pisać.
Wtedy główny architekt wyciągnął z kapelusza generator CRUDów, nad którym już od jakiegoś czasu pracował - plugin do Eclipsa :-) tadaaam. Na szczęście to nie był mój projekt. A firma wkrótce też już nie była moją firmą.
Najgorsze, że to jest opublikowane na githubie - wstyd przed Ryśkiem. Nie, nie podam linka.

6

Jak chcesz bezpiecznie płacić 5% podatku i składasz wniosek o interpreacje IP Boxa, to wtedy wszystko nad czym pracujesz staje się kompleksowe i innowacyjne

1

Pytanie, co nazywacie generatorem CRUDów - czy narzędzie, które generuje tony kodu źródłowego zawierającego te wszystkie DTO, encje, mapowania ormowe w XMLu i jeszcze kod mapujący z DTO na encje i z powrotem, czy coś mądrzejszego, co robi to wszystko w locie, bez kodu.

0

A jak się robi kompleksowy system bez CRUD'a.???? O co wam w ogóle chodzi.?

2

Może ktoś w ogóle wyjaśnić co złego jest w CRUDZie, który pod maską, np. przed zapisem używa jakiegoś machine learningu czy coś to rozpoznania czegoś lub jakiś bardziej zaawansowanych rzeczy? Bo widzę jest jakieś dziwne rozróżnienie CRUD == nuda|zlo|wtornosc. Jak coś się nazywa crudem, to od razu jest gorsze od czegoś co nazywa się "liderem rynku" na zewnątrz, który "zmienia świat", a od wewnątrz to ordynarny spagetti crud, z 10^4 lat długu technicznego, tudzież zwykły wordpress z jakims pluginem? :P

1

Ale przecież nie chodzi o to że aplikacja która ma warstwę persystencji to od razu zły crud. CRUD to aplikacje które są frontendem na bazę danych. Mógłbyś taką aplikacje zastąpić jakimś Oracle Apex w 15 minut ;] CRUD kończy się tam gdzie aplikacja zaczyna mieć jakaś logikę.

3

Co zlego w CRUD.

  1. Jeśli front prezentuje CRUD to zwykle oznacza, że użytkownik musi przeklikać się przez ileś ekranów, żeby odczytać jakąś wartość lub dodać jaką informację
  • dawno tego nie widziałem, klienci już sobie takich UI nie daja raczej wciskać.
  1. Jeśli backend jest CRUDem (najczęściej) to front musi ogarnać całą logikę aplikacji. Co gorsza, każdy kolejny front (czyli i web i mobile). Jest to mało wydajne (bo zwykle oznacza robienie kilkudziesięciu lub kilkuset requestów HTTP na jedną stronę) i błędogęnne. JS jest średni do pisania logiki.
  2. W backendzie CRUD to zło - bo D w zasadzie nie wolno używać i tego się każdy programista uczy. Po jakimś czasię człowiek uczy sie, że U też nie wolno używać.
    I zostaje nam samo CR. Ale czy dla dóch literek i kijowego skrótu (słabo wymawialny) warto w ogóle się kłócić?
0

crud kończy się tam, gdzie zaczyna się logika

0

CRUD nie zawiera skomplikowanej logiki. To proste operacje. Jeżeli z otrzymanymi danymi musimy coś już zrobić. Przemielić, przeliczyć. To wówczas mamy kontakt z logiką biznesową. Trudno z góry wskazać co jest czym. Trzeba dogłębniej zrozumieć jak działa system. Brak wiedzy na temat zachodzących procesów skutkuje albo nadimplementacją w przypadku CRUDa lub CRUDzeniem tam, gdzie powinno zastosować się bardziej wyszukane wzorce. Z mojej perspektywy ciekawym podejściem jest odkrywanie co jest czym w trakcie Event Stormingu wówczas można zobaczyć jak głęboko sięga jakiś wątek i dopiero wtedy podjąć decyzję. A w zasadzie w ten sposób oddalić decyzję, aż zrozumiemy co tak naprawdę mamy do zrobienia.

2

Z punktu widzenia enkapsulacji CRUD ma jedną bardzo ważną cechę, która może posłużyć tutaj za wyróżnik - model danych wycieka poza granice aplikacji. Te same struktury danych są zapisywane w bazie i są wystawione po API. Efektem tego jest to, że nie ma stopnia swobody - nie można zmienić modelu danych, ponieważ zerwany zostanie kontrakt.

W przypadku bardziej złożonych systemów powinno się pozostawić swobodę, aby model danych mógł ewoluować i być sterowany potrzebami biznesowymi (Domain-Driven). Wtedy możemy mówić o logice aplikacji, testowaniu jednostkowym i BDD i tak dalej. Wg. mnie to właśnie rozróżnia aplikację biznesową od CRUD-a.

Mała uwaga na koniec - CRUD-y czasami są dobrym wyborem architektonicznym. Takie aplikacje również się bardzo łatwo testuje - wystarczy parę testów integracyjnych, nie ma potrzeby pisać jednostkowych. CRUD-y również bardzo ładnie odkrywa się wspomnianym wcześniej event storomingiem.

1
Charles_Ray napisał(a):

Z punktu widzenia enkapsulacji CRUD ma jedną bardzo ważną cechę, która może posłużyć tutaj za wyróżnik - model danych wycieka poza granice aplikacji. Te same struktury danych są zapisywane w bazie i są wystawione po API.

To się raczej nazywa encja na twarz. O ile mi wiadomo, to w CRUDzie nikt chyba nie broni mieć co innego w tabeli, a co innego na zewnątrz... No chyba, że ta jednolitość jest definicją CRUDa. O czymś nie wiem?
Bo jeśli to faktycznie wyróżnik CRUDa, to w takim razie wynika z tego, że ja nigdy cruda nie robiłem.

1 użytkowników online, w tym zalogowanych: 0, gości: 1