Overengineering jako wzorzec projektowy

7

Z mojego skromnego doświadczenia wychodzi, że dość często w projektach używa się ostro przegiętej architektury doprawionej miljonem zależności do rozwiązywania banalnych problemów. Typowe przykłady:
Aplikacje mobilne składające się z 5 ekranów na krzyż mają w sobie:

  • Biblioteke do IoC
  • ORM
  • Event Bus
  • Jakieś customowe biblioteki do MVVM

Proste aplikacje serwerowe z pojedynczym endpointem ładują Springa z wszystkimi dobrodziejstwami, 5 bibliotek do wrzucenia paru linijek logów i również ORM'a do realizacji banalnych zadań.

Zastanawiam się, czy ma to jakiś ukryty sens, czy chodzi o takie sprawy jak:

  • Na blogu przeczytałem, że RxJava to super rzecz i chcę tego użyć.
  • Wszyscy teraz chcą programistów Spring, więc użyjmy tego frameworka, bo chcę go mieć w CV.
  • A co jak nasza aplikacja za 5 lat będzie większa i wtedy to się przyda?

Do tego sprawa trochę poboczna, ale chyba wpisująca się w ten trend - fetysz clean code, polegający na niekończących się dyskusjach, jak nazwać zmienną, żeby zamiast 20 znaków miała 15 znaków i dalej mówiła co przechowuje. Czepianie się o if(obj==null) zamiast if(null==obj), bo w C++ można pomylić porównanie z przypisaniem, my co prawda piszemy w Javie, ale na wszelki wypadek...

5

Proste aplikacje z jednym endpontem?
Ktoś tak robi na produkcji?

Wszyscy teraz chcą programistów Spring, więc użyjmy tego frameworka, bo chcę go mieć w CV.

Powiem szczerze że to mnie dziwi. Większość firm szuka programistów Springa, Angulara itp więc wielu ludzi się boi wykluczenia z rekrutacji.
Poza tym produkcja to nie eksperyment na projekt w Githubie, i tam używa się czegoś czego się zna.
To czy jar wazy 100 czy 200 mb to żadna różnica w porównaniu do rozmiaru community, dobrej dokumentacji itp

2

To nie wiem gdzie pracujesz.. chociaż z clean coderem miałem do czynienia. Na końcu każdego pliku, między nawiasem kończącym klasę, a drugim kończącym ostatnią metodę musiał być enter xD

7

@IHaveHandedInMyResignation:
A to ja kiedyś miałem taki przypadek, gość robił logikę w kontrolerach, klasy z 10 polami itp ale jak były u mnie przez przypadek dwie linie odstępu to afera xD.
Ja się nauczyłem formatowania, typ dobrego kodu raczej nie...

1

OP: Mówisz o projektach komercyjnych czy amatorsko-edukacyjnych? Jeżeli to drugie, to nie widzę w tym nic dziwnego - ludzie chcą na jakimś prostym przykładzie ogarnąć, jak dane narzędzie działa.

4

A jeszcze lepiej kiedy:

  • design jest fancy,
  • zrobione ASAP,
  • project jest flexible,
  • itp itd.

Coraz częściej rzeczy jest możliwych do wyklikania. Potrzeba pisania czegoś samemu jest coraz rzadsza. Zarządy firm kumają IT w stopniu najwyżej miernym. Dla nich ważne, że jest zrobione. Ktoś rzucił buzzwordem typu Spring, który pozwala w krótkiej perspektywie zaoszczędzić parę tysięcy¿ "Me gusta¡" - krzyczą członkowie zarządu i godzą się na takie fajerwerki. Ale, że RAMu trzeba dołożyć albo potem poprawki robić, to nikt nie wie czemu tak się dzieje. Tzn. programiści wiedzą, ale ich mało kto słucha.

4

Mam takie doświadczenia ze sporej liczby komercyjnych projektów, które miały miejsce w sporej liczbie firm. Jak ktoś sobie chce coś prywatnie wyrzeźbić, to nic mi do tego - edukacyjnie wiadomo, że ma to sens. Ale jak chodzi o zrobienie prostej aplikacji do obsługi jakiejś tam promocji, serwisu, który ma szybko dostarczyć jakąś banalna funkcjonalność, czy innego przysłowiowego CRUD'a, to już zaczyna to przypominać trochę kult cargo, w efekcie czego mamy np. aplikacje mobilną z paroma guzikami na krzyż, gdzie zamiast zwyczajnie zareagować na kliknięcie jest rozgłaszany event o naciśnięciu guzika, jakis serwis go przechwytuje, pobiera dane, wysyła inny event, że dane pobrane, co znowu jest przechwytywane przez jakiś ekran i pokazane na ekranie. W efekcie czego po zajrzeniu w taki kod nie wiadomo kompletnie nic, stack trace z exceptionami pokazuje wszystko co możliwe, ale zero odwołań do własnego kodu. Jak przychodzi zrobić jakąś prostą zmianę, to po tygodniu odpowiedź brzmi, że się nie da, bo nie ma takiej adnotacji, ew. ta biblioteka, co jej uzywamy już od tygodnia jest niemodna i trzeba poświęcić miesiąc na jej podmianę do modniejszej. A po przeczytaniu paru rozdziałów z "Clean Code" (nie żebym miał cos przeciwko) 20% czasu w projekcie jest przepalane na dyskusje o wyższości spacji nad tabami.

5

Biblioteke do IoC
(...)
Proste aplikacje serwerowe z pojedynczym endpointem ładują Springa z wszystkimi dobrodziejstwami

NIe znam ekosystemu Javy ale czytając posty na forum coraz częściej odnoszę wrażenie że problemem tak naprawdę jest ten cały Spring, który rzutuje negatywnie na pewne inne, całkowicie normalne aspekty. I winą tutaj po części jesteście Wy szanowni programiści Java, bo wykazujecie się trochę arogancją i nie bierzecie pod uwagę że framework którego Wy używacie nie jest jedyną miarą. Później pojawiają się geniusze którzy wszem i wobec głoszą że te całe IoC to w ogóle zło i tyle, i po co to w ogóle używać.W przypadku IoC ja uważam że nawet w prostszych aplikacjach IoC można stosować i nie ma w tym nic złego, tym bardziej że jest tyle lekkich bibliotek do tego.Oczywiście wszystko ma swoje granice i zależy od wymagań, więc zdaję sobie sprawę że są przypadki gdzie faktycznie podejmuje się próby przeinżynierowania prostych problemów. W 99% przypadków nie zaliczał bym do tego IoC- zakładając że używa się do tego coś normalnego.

fetysz clean code, polegający na niekończących się dyskusjach, jak nazwać zmienną, żeby zamiast 20 znaków miała 15 znaków i dalej mówiła co przechowuje. Czepianie się o if(obj==null) zamiast if(null==obj), bo w C++ można pomylić porównanie z przypisaniem, my co prawda piszemy w Javie, ale na wszelki wypadek...

Ale co do ma wspólnego z czystym kodem? Brzmi to bardziej jakby ktoś sam nie wiedział co chce osiągnąć.

3

@piotrpo: jak pisałem, obawiam się że to w dużym stopniu wina firm. Szukają ludzi którzy mają doświadczenie z 20 technologiami więc ludzie wciskają reactjx itp do tego Androida.
Oczywiście ktoś napisze ze trzeba iść do cywilizowanej firmy która szuka programistów a nie klepaczy Springa, Angulara etc, zgoda - tylko mówię to co widzę.

4

Szefostwo jest niekompetentne i koderzy potrafią wmówić zalety takich rozwiązać, o których przeczytali bo doświadczenia przecież z tym nie maja,. Doświadczenie chcą właśnie móc se wpisać dzięki danemu projektowi. Oczywiście tego doświadczenia nadal nie mają bo jak się pojawiły problemy z daną technologią to sp* z firmy, potem jak masz naprawić ten bajzel to nawet nie ma kogo spytać dlaczego takie rozwiązanie. Zostajesz z transakcjami rozproszonymi w MySQL obejmującymi kod w javie :(

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

Robot: Neevabot