Po co korzystasz z biblioteki?

1

Witam, popularnie wszyscy używamy bibliotek różnej maści, wszyscy wiemy też że biblioteka bibliotece nie równa; niektóre są ogromne, utrzymane kilkanaście lat o bardzo dobrej reputacji i ścisłej domenie; z masą kontrybutorów, testów, gwiazdek, downloadów i rozwiązanych issue'sów. Są też inne, utrzymane max. rok, z ostatnim commitem wiele miesięcy lub lat temu, bez testów, bez kontrybutorów napisana przez jedną czy dwie osoby.

Poziomy jakości tych bibliotek są różne, oraz ich opłacalność na dłuższą metę jest różna. Sprawia to że wydaje mi się że istnieje pewna granica w spektrum bibliotek po przekroczeniu której opłacalność użycia biblioteki jest mniejsza niż koszt napisania jej samemu, zwłaszcza jeśli biblioteka jest słabo napisana i zaprojektowana.

Jestem też pewien że każdy z was się spotkał z juniorem, który nie był świadom istnienia jakiejś biblioteki i spędził kilka tygodni na pisanie swojej biblioteki, żeby się dowiedzieć że taka już istnieje, i wystarczyłoby żeby jej użył. Powoduje to powstanie takiego efektu, kiedy ktoś kto pisze swoją libkę jest hejtowany i wyzywany od juniorów. Kiedy zgadzam się że kiedy "ktoś pisze swojego reacta" to to ma mały sens, tak kiedy dostępnych narzędzi jest 0/mało; albo są tylko nieodpowiednie do celu; wtedy ta szala opłacalności może się przechylić na drugą stronę. Mogłoby tu dojść do absurdalnej sytuacji w której ktoś woli napisać import "is-odd"; w JS, zamiast napisać % - to oczywiście żart; ale chodzi o sytuacje kiedy ktoś mógłby uchronić się od dodatkowej zależności jedną/dwiema klasami, zamiast dokładać libkę

Jestem też zdania, że im masz większe doświadczenie, że jeśli podejmiesz decyzę o napisaniu swojej biblioteki/implementacji, tym większa szansa że będzie ona sensowna.

Dlatego pomyślałem że zrobię ankiete - jakie są wasze najczęstsze powody używania bibliotek; oczywiście nie mówię o takich jak Laravel, Spring, RoR, React, które definiują wręcz pracę, tylko takich które potencjalnie moglibyście napisać w tydzień/dwa, żeby uchronić się od zależności.

Bardzo proszę, o nie zaznaczanie w ankiecie punktów z którymi się zgadzacie! Tylko tych które faktycznie są waszym powodem

1

"Bo robi to co jest mi potrzebne" - nie znalazłem takiej odpowiedzi na liście :(

0
some_ONE napisał(a):

"Bo robi to co jest mi potrzebne" - nie znalazłem takiej odpowiedzi na liście :(

Tylko wiesz, to nie do końca powód; bo Twoja implementacja też robiłaby to co Ci potrzebne ;)

Libka Moja implementacja
Robi to co mi potrzebne Robi to co mi potrzebe
Argumenty za Argumenty przeciw
1

Zawsze, gdy się da. Największa zaleta jest wtedy, gdy kod biblioteki to coś czego sam bym nie napisał przy bieżącym poziomie wiedzy (np. biblioteka do obsługi jakiegoś protokołu) albo, gdy napisałbym taki kod, ale biblioteka jest dużo bardziej dopieszczona tj. ma dokumentację, testy, wersjonowanie, w miarę stabilny interfejs. To czego się wytrzegam to multiliby np. boost z C++, bo to najgorszy syf jaki może być: często biblioteki słabej jakości ciągną w dół te lepsze, bo są zestawione obok siebie albo co gorsza ta lepsza używa tej gorszej

1

Brakuje mi czegoś typu utilsowe biblioteki łatające upośledzony język programowania - Usprawniają pisanie całego projektu np. lombok, vavr, lodash.
No i biblioteki I/O. Jak chcę wygenerować excela/PDF to w życiu nie będę tego pisał od zera. Chociaż chyba się to podpina pod "Bo ma integrację z systemem, z którego korzystam"

0
Grzyboo napisał(a):

Brakuje mi czegoś typu utilsowe biblioteki łatające upośledzony język programowania - Usprawniają pisanie całego projektu np. lombok, vavr, lodash.

Ale mi nie chodzi o to jakie biblioteki wybierasz, tylko czemu.

Innymi słowy, pytanie jest takie - Jeśli chcesz łatać język i używać utilsów, jak StringUtils z apache; to czemu wybierzesz ściągnąć bibliotekę lombok zamiast napisać swoją. To jest sens ankiety.

No i biblioteki I/O. Jak chcę wygenerować excela/PDF to w życiu nie będę tego pisał ręcznie.

A czemu nie? Odpowiedz proszę w ankiecie.

2

Wydaje mi się, że odpowiedź mocno zależy od języka np. porównując takie C++ vs Go:

C++:

  • systemy budowania to burdel, jedyną przenośną opcją są header-only liby, ale one mają problem np. z długi czasem kompilacji
  • nawet jak mamy bibliotekę header-only to puszczanie testów zawsze działa inaczej
  • porządne liby obsługują wszystkie systemy i kompilatory, przez co ich czytanie to męka, bo połowa kodu to #ifdef, #define i #pragma
  • biblioteki są napisane w różnych dialektach języka np. w C++ będziemy mieli: zwykłe C, enterprise C++ jak z lat 90%, C++ wykorzystujący mocno mechanizmy C++ ale bez standardowej biblioteki (np. rapidjson), templatowe abominacje bo ktoś chciał się pobawić, super "nowoczesny" C++ korzystający mocno z nowych ficzerów języka, C++ używający określonej biblioteki jako biblioteka standardowa np. liby używające boosta i pewnie jeszcze mógłbym szukać wiele innych hybryd. TL;DR: jest mała szansa, że styl naszego projektu będzie pasował do biblioteki
  • programiści często kierują się czystością kodu. Twórcy bibliotek często idą w poprawność, przez co wykorzystują wszystkie możliwe mechanizmy języka, żeby być poprawnym/wydajnym w każdym przypadku. Np. implementacje kontenerów takie są
  • biblioteki często są ogólne przez co używają templatów. Templaty czyta się gorzej niż normalny kod, bo słabo się dokumentują. Błędy kompilacji potrafią ciągnąć się na kilka stron a analizowanie kodu po typach często zawodzi, bo templaty używają duck typingu

Go:

  • wszystko ustandaryzowane: formatowanie, dokumentacja, testy, benchmarki, system budowania
  • dodanie biblioteki do projektu to go get github.com/sciezka/do/repo
  • generalnie wszyscy piszą w jednym stylu. Anemiczny system typów sprawia, że każdy używa tych samych buliding blocków do tworzenia swoich bibliotek, bo użycie czegokolwiek bardziej finezyjnego wygląda źle
  • wydaje mi się, że z uwagi na wiek jest dosyć mało potworków np. multilibów albo pseudo libów standardowych. Jak jakiś lib stanie się passe (np. https://github.com/sirupsen/logrus) to wchodzi w tryb utrzymania i społeczność powoli migruje się na coś lepszego (https://github.com/uber-go/zap albo https://github.com/rs/zerolog). Generalnie nie widziałem przykładu tak grubej dependencji jak np. popularny w dzisiejszych czasach log4j2.

W przypadku takiego C++ dużo częściej pisałbym własne liby, bo sumarycznie liczba minusów często przewyższa plusy. W takim go mam dużo mniej powodów, żeby tak robić

1

a) bo jest to jakiś standard - e.g ORM typu EF Core / Dapper czy Logger typu Serilog

b) bo problem jest dość złożony e.g parser pdf, html.

c) bo budżet mały

d) bo nie umiem e.g networking

A zdarza mi się pisać własne rzeczy

3

Brakuje mi odpowiedzi : bo jestem leniwy

2

Chce mieć do CV

1

Zaznaczyłem trzy: bo nie mam czasu, bo biblioteka działa na 100%, I że piszę swoje implementacje.

Należy to rozumieć tak: o ile jestem w stanie napisać większość bibliotek tak nie widzę w tym sensu. Strata czasu. Chociaż zdarza mi się pisać jakiegoś utilsa, gdy potrzebna mi jest jedna metoda z jakichś commonsów.

0
wartek01 napisał(a):

ile jestem w stanie napisać większość bibliotek tak nie widzę w tym sensu. Strata czasu.

No spoko, większość z nas nie widzi w tym sensu i to właśnie jest cel ankiety - ustalić jakie są powody czemu ludzie ich nie piszą. Rozumiem że w Twoim przypadku "brak sensu" == "szkoda czasu"?

0

Zaznaczyłem chyba z 5 najbardziej oczywistych.

Rozbawiły mnie za to te:

  • Bo autor biblioteki mógł rozwiązać problem na który ja nie wpadłem
  • Bo biblioteka działa idealnie 100%, i nie ma potrzeby duplikować

Ale ilość głosów przy nich już zasmuciła.

4

Jednej odpowiedzi brakuje - bo używam standardów wypracowanych w społeczności przez co łatwiej znaleźć ewentualnych kolaborantów do projektu.

4

jest opensourcowa biblioteka, brakuje mi jakiegoś drobiazgu, więc zamiast szukać innej biblioteki gorszej i mniej popularnej albo pisać od początku bibliotekę, mogę dopisać funkcjonalność do tej i udostępnić społeczności

0
Miang napisał(a):

jest opensourcowa biblioteka, brakuje mi jakiegoś drobiazgu, więc zamiast szukać innej biblioteki gorszej i mniej popularnej albo pisać od początku bibliotekę, mogę dopisać funkcjonalność do tej i udostępnić społeczności

Ale to mówisz o kontrybutowaniu do biblioteki; a ankieta była o wyborze "napisać vs użyć".

2

Im bardziej zaawansowana biblioteka, tym więcej w niej autorskiego widzimisię ale zazwyczaj popartego doświadczeniem.

Jeśli autorskie widzimisię biblioteki pokrywa się z Twoim lub Twojej organizacji, to nie ma sensu marnować czasu na własną implementację, testy i utrzymanie (z punktu widzenia organizacji koszt utrzymania własnego rozwiązania jest znacznie wyższy). Oczywiście, jeśli libka, która potencialnie ma się nam przydać nie ma dużej ekspozycji na krytykę innych, możemy przejrzeć jej kod i zobaczyć czy nie pisał jej amator do pracy licencjackiej - jeśli tak, to potencjalna ilość poprawek będzie znacząca i wtedy rozsądnie jest rozważać własną implementację :D

Wiadomo, zdarzają się wyjątki typu ostatni bonus w log4j dzięki któremu pewnie połowa korpo apek już pewnie jest "compromised" xD. ALE statystycznie, we własnym rozwiązaniu równie łatwo można popełnić błąd, więc dodatkowy koszt maintenance nie jest tego wart (szczególnie gdy bierzemy pod uwagę libki z długą historią i długim stażem - np. nikt normalny tworzący oprogramowanie komercyjne nie pisałby od zera własnego HttpClienta w Javie).

Do celów naukowych lub dla siebie (jeśli nie programuje się zarobkowo), oczywiście można pisać odpowiedniki istniejących popularnych rozwiązań, bo zawsze jest szansa, że można zrobić coś lepiej, lub odkryć, że istniejące rozwiązanie to kompletne bagno bez przyszłości :)

6

Odwóćmy trochę sytuację. Przychodzisz jako nowy do teamu, gdzie programiści cierpią na syndrom NIH i mówią że mają własny generyczny framework lub własną bibliotekę uber utilsów. Co czujesz? Ja czuje że chcę uciekać. I to tym bardziej im większy jest ten framework czy biblioteka. No bo jeśli to jest ich własne rozwiązanie to znaczy, że w internecie nie znajdę żadnych tutoriali jak tego użyć. Jedynym sposobem będą albo unit testy pisane do tej biblioteki, albo czytanie kodu (zakładam że dokumentacja zawsze w takich wypadkach jest niekompletna lub przestarzała). Bohatersko będę rozwiązywac problemy które występują tylko w tej firmie i ta wiedza nie przyda mi się w żadnej kolejnej pracy.
Na szczęście "własny generyczny framework" oznacza że mają cieńkiego wrappera na zewnętrzny framework :D

1
qbns napisał(a):

Im bardziej zaawansowana biblioteka, tym więcej w niej autorskiego widzimisię ale zazwyczaj popartego doświadczeniem.

Jeśli autorskie widzimisię biblioteki pokrywa się z Twoim lub Twojej organizacji, to nie ma sensu marnować czasu na własną implementację, testy i utrzymanie (z punktu widzenia organizacji koszt utrzymania własnego rozwiązania jest znacznie wyższy). Oczywiście, jeśli libka, która potencialnie ma się nam przydać nie ma dużej ekspozycji na krytykę innych, możemy przejrzeć jej kod i zobaczyć czy nie pisał jej amator do pracy licencjackiej - jeśli tak, to potencjalna ilość poprawek będzie znacząca i wtedy rozsądnie jest rozważać własną implementację :D

Wiadomo, zdarzają się wyjątki typu ostatni bonus w log4j dzięki któremu pewnie połowa korpo apek już pewnie jest "compromised" xD. ALE statystycznie, we własnym rozwiązaniu równie łatwo można popełnić błąd, więc dodatkowy koszt maintenance nie jest tego wart (szczególnie gdy bierzemy pod uwagę libki z długą historią i długim stażem - np. nikt normalny tworzący oprogramowanie komercyjne nie pisałby od zera własnego HttpClienta w Javie).

Do celów naukowych lub dla siebie (jeśli nie programuje się zarobkowo), oczywiście można pisać odpowiedniki istniejących popularnych rozwiązań, bo zawsze jest szansa, że można zrobić coś lepiej, lub odkryć, że istniejące rozwiązanie to kompletne bagno bez przyszłości :)

Widzę że nadal niektórzy nie kumają ankiety.

W ankiecie nie jest zadane pytanie CZY korzystać z biblioteki, czy pisać swój - tylko raczej o powód - jeśli wybierzesz bibliotekę, to który konkretnie powód Cię do tego skłania.

KamilAdam napisał(a):

Odwóćmy trochę sytuację. Przychodzisz jako nowy do teamu, gdzie programiści cierpią na syndrom NIH i mówią że mają własny generyczny framework lub własną bibliotekę uber utilsów. Co czujesz? Ja czuje że chcę uciekać. I to tym bardziej im większy jest ten framework czy biblioteka. No bo jeśli to jest ich własne rozwiązanie to znaczy, że w internecie nie znajdę żadnych tutoriali jak tego użyć. Jedynym sposobem będą albo unit testy pisane do tej biblioteki, albo czytanie kodu (zakładam że dokumentacja zawsze w takich wypadkach jest niekompletna lub przestarzała). Bohatersko będę rozwiązywac problemy które występują tylko w tej firmie i ta wiedza nie przyda mi się w żadnej kolejnej pracy.

To co napisałeś można podciągnąć pod każdy projekt, legacy lub nie - nie ważne czy nazywają to libką czy nie.

Do każdego projektu można wprowadzić gówniane rozwiązanie, i nowi będą musieli z tym bohatersko walczyć. Więc - jako że się zgadzam żę zjawisko istnieje; tak mam wrażenie że nie podciąga się pod temat ankiety.

3

Bo lubię zapach książek.
Najczęściej szkoda mi czasu:

  • na pisanie biblioteki, którą użyje do jednego projektu,
  • na naukę czegoś, co może nie mieć przełożenia na inne projekty (wiedza domenowa).

Nie udaję UberProgramisty, pozwalam innym zrobić coś lepiej.

1

To co napisałem mógłbym streścić do "Bo w internecie są tutoriale do biblioteki". Wybierając bibliotekę staram się patrzeć która ma lepszą dokumentację. Np mając do wyboru "Cats vs Scalaz" wybrałbym Catsy ze względu na dokumentację.

TomRiddle napisał(a):

To co napisałeś można podciągnąć pod każdy projekt, legacy lub nie - nie ważne czy nazywają to libką czy nie.

Tak, dlatego jestem wielkim przeciwnikiem kodu w aplikacji. Im mniej kodu w aplikacji (i więcej w bibliotekach zewnętrznych) tym lepiej :P

Ale nie zawsze mi się to oczywiście udaje. Ostatnio napisałem własną implementację monady Writer. Zanim się zorientowałem że to Writer i mogę użyć standardowego z Catsów poszedł merdze go mastera. I teraz mamy własną implementację monady Writer na produkcji :D

2

Mogłaby być jeszcze odpowiedź: "Bo ktoś już ten problem rozwiązał".

0
dargenn napisał(a):

Mogłaby być jeszcze odpowiedź: "Bo ktoś już ten problem rozwiązał".

Bo biblioteka działa idealnie 100%, i nie ma potrzeby duplikować?

Tylko wiesz, to że go rozwiązał, nie znaczy że rozwiązał go dobrze; i nie znaczy że Ty nie możesz go rozwiązać samemu.

2

Taką też opcję zaznaczyłem, ale to nie jest to samo.
Koło zostało już wynalezione raz, po co kolejny raz to robić?

Wiadomo, że odpowiedź zależy od wielu czynników, dlatego kieruję się wskaźnikiem "good enough". Nie musi być idealne, tak jak prawdopodobnie moje rozwiązanie też nie będzie.

0
dargenn napisał(a):

Taką też opcję zaznaczyłem, ale to nie jest to samo.
Koło zostało już wynalezione raz, po co kolejny raz to robić?

No, koło to akurat przykład idealnego rozwiązania: proste, przemyślane, sprawdzone, niezawodne. Nie każda biblioteka taka jest. Niektóre mają słaby design, błędy, bugi, koszt update'ów i utrzymania może przewyższać ich wartość.

2
TomRiddle napisał(a):
dargenn napisał(a):

Taką też opcję zaznaczyłem, ale to nie jest to samo.
Koło zostało już wynalezione raz, po co kolejny raz to robić?

No, koło to akurat przykład idealnego rozwiązania: proste, przemyślane, sprawdzone, niezawodne. Nie każda biblioteka taka jest. Niektóre mają słaby design, błędy, bugi, koszt update'ów i utrzymania może przewyższać ich wartość.

No to takich lepiej nie używać :P A to czy było warto, prawdopodobnie wyjdzie dopiero z czasem. Bo wybór prawie zawsze sprowadza się do czasu: wysiłek kontra korzyść z danego rozwiązania. Jeśli spędzisz dwa tygodnie na coś co można załatwić jednym importem - słabo.

Poruszę tu jeszcze inny temat: bibliotek które krążą wewnątrz firm. Ile razy był "nakaz" używania jakiejś biblioteki przez uber-architekta, a później okazywało się że i tak trzeba coś fixować? :P Z tej perspektywy to czasami wolałbym nic internalnego nie używać. Oczywiście, można to zrobić dobrze, tak samo jak i dobrze może być zrobiona biblioteka zewnętrzna. Mimo wszystko skłaniałbym się ku rozwiązaniu open source z aktywnymi kontrybutorami - nawet z potencjalnymi bugami, które w razie potrzeby dość pilnie zostaną poprawione, niż korzystać z archaicznych rozwiązań in-house, gdzie autor tej biblioteki już dawno pracuje gdzie indziej.

0
dargenn napisał(a):

No to takich lepiej nie używać :P A to czy było warto, prawdopodobnie wyjdzie dopiero z czasem. Bo wybór prawie zawsze sprowadza się do czasu: wysiłek kontra korzyść z danego rozwiązania. Jeśli spędzisz dwa tygodnie na coś co można załatwić jednym importem - słabo.

Nie koniecznie, owszem oszczędzisz sobie tych dwóch tygodni; ale dokładasz do projektu coś co zostanie na lata; i przez te lata takie rozwiązanie może Ci i członkom zespołu zabrać dużo więcej niż te dwa tygodnie.

Poruszę tu jeszcze inny temat: bibliotek które krążą wewnątrz firm. Ile razy był "nakaz" używania jakiejś biblioteki przez uber-architekta, a później okazywało się że i tak trzeba coś fixować? :P

No to zaznacz proszę opcje w ankiecie Bo kazali użyć.

Mimo wszystko skłaniałbym się ku rozwiązaniu open source z aktywnymi kontrybutorami - nawet z potencjalnymi bugami, które w razie potrzeby dość pilnie zostaną poprawione, niż korzystać z archaicznych rozwiązań in-house, gdzie autor tej biblioteki już dawno pracuje gdzie indziej.

No to jest też opcja w ankiecie Bo biblioteki mają dużo kontrybutorów.

4

@TomRiddle:
Te wszystkie Twoje argumenty kojarzą mi się z tym, jakby wszystkie dostępne biblioteki były wyjątkowo słabej jakości.
W C#, większość tego co jest teraz jest tak dopracowane, że pisanie samemu NA PEWNO będzie gorsze.
Przykład? HangFire, NSwag, Polly, Dapper.

Napisanie czegoś podobnego do jednej z nich to tysiące godzin, które można byłoby przeznaczyć na picie wódki w doborowym towarzystwie.

@Edit:
Aż mi się skojarzyło, znam kilka osób, co robią wszystko zwykłym SQL argumentująć, że ORM jest wolny itp. Kończy się na

  • Errorach w składni przy edge case
  • Trudności w rozwijaniu
  • Dużej ilości "quick fix bo tak działa.", co robi z kodu kupkę.
0
Pixello napisał(a):

Te wszystkie Twoje argumenty kojarzą mi się z tym, jakby wszystkie dostępne biblioteki były wyjątkowo słabej jakości.

Oj, nie nie nie. Na pewno nie wszystkie. Wiadomo, że są biblioteki które są zjawiskowo dobre.

Again; mam wrażenie że niektórzy tutaj nie rozumieją ankiety. Ja nie zachęcam ani do używania bibliotek, a do nie używania nic z tych rzeczy. Ja po prostu pytam; że jeśli decydujesz się dodać bibliotekę, to jakim konkretnie powodem się kierujesz.

Napisanie czegoś podobnego do jednej z nich to tysiące godzin, które można byłoby przeznaczyć na picie wódki w doborowym towarzystwie.

Czyli czas jest tutaj czynnikiem? To zaznacz odpowiedź Bo nie mam czasu napisać własnej impl?

Aż mi się skojarzyło, znam kilka osób, co robią wszystko zwykłym SQL argumentująć, że ORM jest wolny itp. Kończy się na

  • Errorach w składni przy edge case
  • Trudności w rozwijaniu
  • Dużej ilości "quick fix bo tak działa.", co robi z kodu kupkę.

No wiadomo, że jak słaby programista się za to weźmie, to wiadomo że jest spora szansa że zrobi to gorzej niż jest w bibliotece. Ale autor biblioteki też pewnie ideałem nie jest, i może się znaleźć taki ktoś kto napisałby coś jeszcze lepszego.

Na ten argument polecam odpowiedź w ankiecie Bo nie chcę brać odpowiedzialności za ew. błędy albo Bo autor biblioteki mógł rozwiązać problem na który ja nie wpadłem.

1
TomRiddle napisał(a):

Nie koniecznie, owszem oszczędzisz sobie tych dwóch tygodni; ale dokładasz do projektu coś co zostanie na lata; i przez te lata takie rozwiązanie może Ci i członkom zespołu zabrać dużo więcej niż te dwa tygodnie.

Akurat do tego się odnosiłem, mogłem od razu dodać cytat, ale to mnie striggerowało, bo najczęściej delikwent sam coś napisze, pójdzie, i przy każdej zmianie to jest dług, który ktoś musi kiedyś zamienić na libkę.

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