Wątek przeniesiony 2021-10-09 12:07 z Flame przez Shalom.

Dlaczego programy "enterprise" muszą być tak kosmicznie przekombinowane?

2

Wyglada tak samo jak działa. Przecież klient musi wiedzieć, że płaci za produkt klasy enterprise ;)

A tak na serio, trudno zrobić czystą architekturę i ją utrzymać. Niektórzy pakują wzorce bez zastanowienia i spojrzenia na całość, tak to robili przez cała karierę zawodową i tak będą robić dalej.

7

Ja mam z kolei inną obserwację - czesty brak sensownych warstw abstrakcji i mieszanie kodu domenowego z infrastrukturą, np. encje JPA w logice biznesowej.

2

W momencie pisania tego kodu często nie są znane wymagania, więc (wydaje się, że) trzeba zrobić taki kod bardziej podatnym na wymagania, które pojawią się w przyszłości. Wymagania które były znane w momencie tworzenia kodu, przestały być wymaganiami w momencie w którym oglądasz ten kod. Możliwe, że w projekcie tydzień temu było szkolenie z wzorców projektowych/czystej architektury/pogadanka o SOLID, albo architekt przeczytał akurat jakąś książkę.

5

Przekombinowane rozwiązania, zazwyczaj mają bardzo pięknie brzmiące i stosunkowo proste uzasadnienia, dlaczego niby są takie świetne. Uniwersalność, możliwość konfiguracji i rozszerzania, użycie nowoczesnych narzędzi automatyzujących taką czy inną czynność... są dobrze wchodzącymi sloganami i nie wymagają jakiegoś dłuższego wstępu, aby pobieżnie tylko rozumiejący temat słuchacze nabrali entuzjazmu i pomyśleli - och, jakieś to mądre.

Jeśli ktoś z kolei rozumie jaki problem oprogramowanie ma rozwiązywać, ma doświadczenie w programowaniu i tej bądź pokrewnej dziedzinie, widzi że te entuzjastyczne wizje to puste slogany, i że to przekombinowane podejście stworzy mnóstwo problemów, a mało co rozwiąże, nie wytłumaczy tego w 15 minut jakiemuś członkowi zarządu, bo musiałby go wprowadzić w ogromną liczbę szczegółów, o których ten nie ma ochoty słuchać. Po wysłuchaniu obu stron, osoby decydujące ocenią rozwiązanie przekombinowane jako lepsze.

1

Fajnie jakby w tym wątku zostały podane przykłady przeinzynierowania, bo jak na razie mamy tylko jeden przykład z factory, który jak napisali poprzednicy wcale nie musi być przekombinowany :)

Albo nie, osobny wątek lepiej założyć.

Przykłady przeinżynierowanego kodu

1

No ten przykład z pierwszego posta @Crazy_Rockman z zamianą int sum = 2 + 3; na wywołanie jakichś bobów budowniczych to w zasadzie niedoinżynierowanie, bo to wygląda tak, jakby ktoś chciał osadzić jakiegoś DSLa/minijęzyk skryptowy w aplikacji (stąd potrzeba dynamicznej zmiany operatorów czy wartości) i zamiast odrobić pracę domową czyli napisać tego prostego DSLa albo poszukać istniejącego (co byłoby w zasadzie bardziej odważnym rozwiązaniem niż tylko wrzucenie paru wzorców więcej), to idzie na pół gwizdka i robi "DSL dla ubogich" w postaci

Integer a = IntegerBuilder
  .fromPrimitiveInt(2)
  .withSign('+')
  .build();

itp.

Tzn. przykład wygląda jak zmyślony, ale widziałem już podobne rzeczy naprawdę.

2
LukeJL napisał(a):

No ten przykład z pierwszego posta @Crazy_Rockman z zamianą int sum = 2 + 3; na wywołanie jakichś bobów budowniczych to w zasadzie niedoinżynierowanie, bo to wygląda tak, jakby ktoś chciał osadzić jakiegoś DSLa/minijęzyk skryptowy w aplikacji (stąd potrzeba dynamicznej zmiany operatorów czy wartości) i zamiast odrobić pracę domową czyli napisać tego prostego DSLa albo poszukać istniejącego (co byłoby w zasadzie bardziej odważnym rozwiązaniem niż tylko wrzucenie paru wzorców więcej), to idzie na pół gwizdka i robi "DSL dla ubogich" w postaci

Integer a = IntegerBuilder
  .fromPrimitiveInt(2)
  .withSign('+')
  .build();

itp.

Tzn. przykład wygląda jak zmyślony, ale widziałem już podobne rzeczy naprawdę.

Jak dla mnie, nie ma testu jednostkowego który mógłbyś napisać żeby rozróżnić Twój przykład z budowniczym od 2 + 3. Więc czemu miałbyś nie użyć "krótrszego" zapisu?

1

O apkach enterprajs to chyba można biblię napisać.

Ja troszkę odbiję piłęczkę.
Uważam, że prawie największy wpływ na kiepski kod ma ... biznes.

Ciągle niesprecyzowane wymagania, zmiana w locie, myślenie że bycie agile i mając scrum robią wszystko OK.
Przez to powstaje kupa w kodzie, nieważne jak dobrze zaczniesz, lebiegi z biznesu ubiją każdy soft w firmie.

Milion pomysłów na początku, którym ucina się łeb i potem coś na szybko trzeba sklecić z istniejącego kodu.

Porywanie się z motyką na słońce, porzucanie pomysłów, wypalanie programistów z w/w powodów.
Zatrudnianie najtańszych też de facto decyzja biznesowa, nie wpływa pozytywnie na jakość kodu :D

No i architekci też mają swój wkład, generowanie modułów z T4 i inne badziewia.

10

Większość tych rzeczy, które ludzie nazywają abstrakcjami, i zarazem to co opisał OP to tak naprawdę przekierowania/ pośredniość (indirection) a nie żadne abstrakcje.

Przekierowania i pośrednicy zwiększają stopień skomplikowania kodu. Każde miejsce gdzie możesz wpiąć inną implementację to przekierowanie. Im takich warstw więcej, tym kod czyta się trudniej, bo jest mało "mięska" a bardzo dużo "szkieletu".

Natomiast abstrakcja polega na tym, że zasadniczo upraszcza rozumienie kodu. Zamiast składać ręcznie bajty i pchać przez socket do bazy, od drodze jeszcze szyfrując, piszesz "addUser(user)" i sie robi. Dobra abstrakcja polega na tym że możesz opisać co robi takie "addUser" oszczędzając szczegółów jak to się tam naprawdę robi.

Abstrakcją jest baza danych, socket, plik, obiekt, iterator, drzewo, słownik itp. To są wszystko rzeczy dzięki którym pisze się prosciej bo pozwalają Ci trzymać w głowie znacznie mniej szczegółów (mniej niż wszystkie rzeczy faktycznie potrzebne do działania tych abstrakcji) a nadal jesteś w stanie ogarnąć system.

https://www.silasreinagel.com[...]direction-is-not-abstraction/

1

Jeżeli sądzę, że coś można wykonać lepiej / prosciej to pytam autora kodu dlaczego zostało w ten sposób to zakodowane. Wtedy dosyć często autor opisuje sytuację, której nie wziąłem pod uwagę i daje sensowną odpowiedź. Dosyć często jest też druga odpowiedź. Gonił deadline i trzeba było robić na odpie*dol (npm przekopiować istniejący już kod z innego projektu) :D

W każdym razie, warto ze sobą rozmawiać i pytać.

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