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.
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,
Oczywiście zdarzają się fuckupy w “zewnętrznych” projektach, ale z mojego doświadczenia wynika, że mimo wszystko w ogromnej większości przypadków bilans wychodzi na ich korzyść.
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.
Nie no oczywiście :) prawie każda dyskusja pod tekstem kończy się wnioskiem : “byle z głową i świadomie”.
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ść.
EN,
Podejście musi być zdecydowane, żeby przekaz był jasny. Jednak nie wiem co ten tekst ma wspólnego z… “populizmem” :). Zastrzeliłeś mnie tym sformułowaniem.
Wiadomo, że są odcienie szarości i nie ma jednej odpowiedzi, która zawsze będzie słuszna.
A przykładów podałem kilka: własny dostęp do danych czy kontener DI prawie nigdy nie ma sensu, a są implementowane bardzo często.
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.
Uvi,
Oczywiście, jak najbardziej! Tak jak napisałem, BARDZO wskazane jest implementowanie takich rozwiązań na własną rękę. Tylko że: nie produkcyjnie, a w ramach edukacji i eksperymentu. Ja kiedyś napisałem data access, który wspierał składnię a’la LINQ, gdy sam LINQ był jeszcze w becie. Świetna sprawa, bardzo dużo się przy tym nauczyłem.
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.
Krzysiek,
Masz rację, z tego leczy się po prostu poprzez zdobywanie doświadczenia :).
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ę.
Tomasz,
“U mnie działa” – dokładnie :). Dopiero jak się faktycznie człowiek porządnie zagrzebie w takim projekcie to widać ilu scenariuszy autor “customowego rozwiązania” nie przewidział…
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ę.
Wojtek,
Zauważ, że napisałeś “stworzyć ręcznie i przekazać…” a nie “zaimplementować własny kontener” :). Zresztą o tym będzie niedługo.
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.
Łukasz,
To już jest zupełnie inna kwestia. ORMy są tak bardzo NADużywane jak tylko można. Ich zadaniem NIE JEST (a raczej: nie powinno być) generowanie bardzo skomplikowanych zapytań, bo tego nie potrafią. Też preferuję microorm (akurat Simple.Data).
Co nie jest powodem, aby pisać… własny :). A o tym jest ten tekst.
[…] Słowo na niedzielę, o syndromie i chorobie […]
[…] A nawet: NIH! NIH Syndrome się kłania. Tak, jak bez sensu jest pisać własny kontener (co na jutubie czynię :) ), tak bez […]