fbpx
devstyle.pl - Blog dla każdego programisty
devstyle.pl - Blog dla każdego programisty
2 minut

Słowo na niedzielę, o syndromie i chorobie


13.11.2016

Kto widział “nasz własny dostęp do danych”, bo “ORMy są słabe“? Kto widział “nasz własny kontener Dependency Injection”, bo “to przecież proste“? Kto widział…?

Akcja: BLOGvember! Post nr 9.
W listopadzie w każdy roboczy poranek na devstyle.pl znajdziesz nowy, świeżutki tekst. W sam raz do porannej kawy na dobry początek dnia.
Miłej lektury i do przeczytania jutro! :)

Ilekroć miałem do czynienia z projektami, w których większość kodu stanowiły narzędzia i infrastruktura, a nie logika biznesowa, wiedziałem TO. Czułem. Najpierw intuicja, potem doświadczenie, zgodnie podpowiadały: oj stary, nie będzie wesoło.

RETREEEEAT!!!

Powodów wynajdowania koła na nowo może być wiele. A to żałowanie kasy na kupno gotowca (choć finalnie wychodzi drożej). A to nieufność do cudzego kodu (choć własny bardzo rzadko jest lepszy). A to chora ambicja (MY NIE ZROBIMY??). A to wreszcie: niedouczenie i brak rozeznania w ofercie rynku.

Jest to zjawisko bardzo powszechne. Spotykane często, zaraźliwe jak ospa. Przenoszone drogą elektroniczną. Dorobiło się nawet własnej nazwy: Not Invented Here Syndrome (NIH).

Chcesz dowiedzieć się, jak działa ORM? Proszę bardzo, napisz swój. Kontener DI? Napisz swój! Biblioteka do walidacji? Napisz! Program do wersjonowania baz danych? Napisz! Biblioteka do testów? Napisz!

Ale, na Boga Swaroga, nie skazuj swojego projektu na używanie go. Potraktuj to jako ciekawe doświadczenie, eksperyment. Bardzo wartościowy sposób na podszlifowanie własnych umiejętności i dogłębne zrozumienie danego (rozwiązanego wszak) problemu. Nic więcej.

Wiecie ile czasu jest co miesiąc marnowanego na utrzymywanie takich “własnych” rozwiązań w prawdziwych, komercyjnych projektach? Dużo. Jest tu obecny ktoś, kto ten czas marnuje w taki sposób? Palec pod budkę, podzielcie się w komentarzach :).

The NIH syndrome is a disease.
Linus Torvalds

P.S. Wiem, że czasem NIE DA SIĘ inaczej, chociażby ze względów prawnych. Ale to margines.

0 0 votes
Article Rating
18 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Andrzej
Andrzej
7 years ago

Co prawda to prawda, można to uznać za marnowanie czasu i ja ten czas tam marnuje. Ale ileż to razy nie muszę walczyć z ORM który postanowił zmienić całe API, lub z frameworkami które wymuszają stosowanie transakcji w określony sposób by w kolejnej swojej wersji nagle zmienić koncepcje. Albo też zostają one porzucone lub ich rozwój jest mocno spowolniony. Ze świata Javy mam tu na myśli choćby Grails.

Dodatkowo używanie obcych bibliotek czy też frameworków powoduje uzależnienie od nich, a że w środowisku Java używa się często rozwiązania typu Maven, które zarządza zależnościami to nie trudno mi wyobrazić sobie że nie tak dawny przypadek z NodeJS i NPM może powtórzyć – http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/

Andrzej
Andrzej
7 years ago

Bilans wychodzi na korzyść jeśli faktycznie korzystasz z zewnętrzenych SPRAWDZONYCH rozwiązań i dobrze rozważyłeś sens ich użycia i co do tego się zgadzam, ale ostrożność w tym trzeba zachować.

Inna rzeczą jest że obecnie strasznie popularne jest używanie bibliotek prawie do wszystkiego, pomijając to że biblioteka wnosi np. 10 zależność a używana będzie tylko np. do formatowanie daty.

Reasumując: Należy używać zewnętrznych bibliotek jak najbardziej ale robiąc to rozsądnie.

eN
eN
7 years ago

Zbyt radykalne stanowisko przedstawiłeś, w programowaniu nie jest to dobre, zbyt wiele rzeczy zależy od kontekstu do którego należy dobrać rozwiązanie, a nie próbować jednym młotkiem wbijać wszystko co wystaje.
Zamiast iść w łatwe do sformułowania populistyczne hasła na rzecz używania rozwiązań firm trzecich, znacznie większą wartością byłoby zastanowienie się kiedy jednak napisanie własnego rozwiązania ma większy sens, bo tych przypadków poza prawnym jest znacznie więcej i zdecydowanie to nie jest margines, aczkolwiek ciągle znacząca mniejszość.

Uvi
Uvi
7 years ago

Ja bawię się we własne twory. Ale ich potem nie stosuję. Zwykle gdy używamy cudzych tworów znamy je tylko w takim zakresie jakim potrzebujemy. W wolnym czasie siadam i próbuję samemu kopiować całość po swojemu. Czasami potrafię stracić 2 dni na zrozumienie jednej metody. Co na tym zyskuję? To jak nabijanie expa w grach. Możesz się expić na ślimakach przez miesiąc i i tak nie wiele zyskasz albo rzucić się na smoka. Jak wygrasz skaczesz kilka leveli. Zwykle po tak bezmyślnej szarży na kod człowiek musi posprzątać przeglądarkę z 5o linków do forów, blogów i innych miejsc, które odwiedził. Zastanawia się co robi z własnym życiem. Ale gdy wraca się potem do kodu to od razu widzi lepiej zależności, przewiduje dziwne zachowania i bez problemu może znaleźć dobre rozwiązania – choć zapewne już je ma, znalezione na forach, zapisane w odpowiednim folderze na przyszłość . I jeszcze czasami ta satysfakcja gdy nikt nie wie i samemu znajduję się rozwiązanie.

Krzysiek
7 years ago

Oj zgodzę się. Not invented here to faktycznie straszna choroba. Choroba, którą chyba jednak trzeba przejść, przejechać się na swoich “lepszych” rozwiązaniach parę razy, żeby zrozumieć o co w niej chodzi. Ze swojej strony dodam jeszcze kolejny powód tworzenia własnych rozwiązań (choć pewnie zawiera się on w chorej ambicji) – jest to perfekcjonizm. Wystarczy zauważyć, że biblioteka/framework/komponent/język mógłby robić coś lepiej/szybciej/w mniejszej ilości linii kodu i czasami to jedno wystarczy, żeby podjąć decyzję o pisaniu czegoś własnego.

Tomasz M.
Tomasz M.
7 years ago

Aż się zjeżyłem jak to przeczytałem.

A potem próby upgrade’owania takiego core’a (jak to się zwyczajowo pewnie nazywa) systemu to wielki ból dupy i dziesiątki (i tu chyba nawet nie przesadzam) straconych godzin w skali miesiąca.

Do tego jak jest sporo językowej automagii + scentralizowany system kontroli wersji (gdzie dev’y nie mają czasu zapoznać się z *chociażby* pracą na gałęziach) a także niska jakość pisanego kodu (mam tu na myśli głównie copy’n’paste) i mamy niezły stolec implementacyjny. Good luck have fun – I’m going home.

O “debugowaniu” i o dość częstym występowaniu błędów typu “u mnie działa” nie wspomnę.

Wojtek
Wojtek
7 years ago

Jak dla mnie jest jeszcze jeden powód: prostota. Często tworząc coś małego nie chcemy od razu dorzucać biblioteki, która ma więcej linii niż cały nasz projekt. O ile w przypadku ORMa to raczej się nie dzieje, o tyle zdarza mi się dość często nie użyć kontenera DI. W momencie gdy mam 5-15 klas w mikrousłudze, wole to wszystko stworzyć ręcznie w mainie aplikacji(i przekazać przez konstruktory) niż dodawać bibliotekę.

Łukasz
Łukasz
7 years ago

Może nie do końca rozumiem co masz na myśli używając ORMów, ale dla mnie głównym problemem w ORMach jest wygenerowane zapytanie do bazy. W przypadku prostych, nieskomplikowanych zapytań wszystko działa ładnie, natomiast jak już masz złączenie 3 tabel i do tego tabele z 10 milionem rekordów to już jest problem. Pisze o tym z doświadczenia właśnie produkcyjnego.
Ja osobiście preferuje użycie microORM np. Dappera i mieć wpływ w 100% na wygląd zapytania.

trackback

[…] Słowo na niedzielę, o syndromie i chorobie […]

trackback

[…] A nawet: NIH! NIH Syndrome się kłania. Tak, jak bez sensu jest pisać własny kontener (co na jutubie czynię :) ), tak bez […]

Kurs Gita

Zaawansowany frontend

Szkolenie z Testów

Szkolenie z baz danych

Książka

Zobacz również