Unde trageți linia între „introduc o bibliotecă” și „o implementez eu”

Unde trageti linia intre introduc o biblioteca si implementez eu?

Daca se poate, cu exemple concrete.

Personal am implementat tot felul de la 0, mai mult ca antrenament sau in proiecte hobby, dar pentru sisteme critice as alege o biblioteca pentru mai orice complicat pe principiul: cu cat o folosesc mai multi, cu atat mai mare sansa sa se gaseasca sau sa se fi gasit deja buguri mai greu de detectat.

Last github commit > 6 months

6 Likes

De obicei, fac o evaluare asupra ceea ce se întâmplă: dacă este vorba de un feature specific, îl dezvolt eu. Dar dacă este ceva generic, ce deja există, folosesc/adaptez respectiva implementare.

Costul folosirii/adaptării unei soluții existente este, de cele mai multe ori, semnificativ mai mic decât cel al dezvoltării de la zero.


Sidenote: până (relativ) recent, eram de părere că în repo-ul proiectului nu are ce să caute cod care nu este scris de mine (sau de echipa din care fac parte). Dar încep să cred din ce în ce mai mult că e o idee bună ori să faci un monorepo ce include (și) toate dependențele :slight_smile:


Presupun că are legătură cu asta: Câtă încredere mai aveți în third parties :smiley:

Argumentul ăsta este (posibil?) greșit. Doar în ultimul an și doar în lumea node/npm au fost câteva pachete în ultimele luni ai căror autori went rogue. Nu uita și de Faker, de acum câteva luni.

4 Likes

Diferenta se face la mentenanta. Nu e deajuns sa dezvolti un modul nou, trebuie si testat in practica si reparat in caz ca se intampla ceva dupa ani de zile. Eu sunt pentru refolosire ori de cate ori e posibil.

5 Likes

Tot ce implementezi trebuie testat, dacă e o librărie are coverage-ul lui. Câteodată chiar de ~100% ceea ce e greu de atins și nu te avantajează când valoare aduc doar feature-urile livrate.

În general un metric foarte relevant la librării e rata de issues closed și open din github.

Dacă au foarte multe issues rezolvate pe bune înseamnă că și tu vei avea posibil aceeași probleme dar ei le-au rezolvat deja. Iar dacă issue-urile noi sunt rapid clasificate și rezolvate înseamnă că suportul este foarte bun.

În cazul react ai foarte multe hook-uri și librării pentru headless components, precum React Table, care au doar logica pentru a crea componentele. Logica e optimizată de obicei pentru ARIA, ceea ce fac foarte rar.

E foarte greu de tras o linie. Eu de exemplu am inceput sa o las mult mai moale cu dependintele de cand fac full time go. Pentru ca “a little copying is better than a little dependency”. Si da, eu de acum 5 ani ar fi considerat bullshit chestia asta. Dar nu o sa intru in detalii pentru ca depinde mult de experienta fiecaruia. Si bineinteles de ecosystemul in care fiecare lucreaza.

Dar linia mea arata cam asa: Daca dependinta adaugata imi adauga alte n dependinte indirecte si zeci de mb in plus pe proiect doar ca sa fac…o parsare de stringuri sa zicem, o sa zic pas.

5 Likes

Când eu ziceam că nu-mi plac framework-urile mi-ați sărit în cap, că cum, că framework-urile sunt testate de mii de oameni.

1 Like

Eu sunt pentru frameworkuri si dependente dar evident nu pentru orice cade in mana. Oricum la proiectele importante fac vendoring ca am mai avut surprize. Dar da, depinde de situatia si ecosistemul fiecaruia, nu cred ca exista o reteta universala de tratare a lor.

Framework nu e acelasi lucru cu adaugarea dependintelor. Frameworkul inseamna reguli, organizarea codului, colaborare, mentenanta, etc

2 Likes

depinde de marime si popularitate. Ceva ca si Angular Material evident nu o sa copiezi, sau date-fns. Daca ceva e foarte popular ai avantajul ca majoritatea bugurilor de care s-au lovit oamenii, datorita faptului ca au folosit acea chestie in nspe mii de implementari, au fost resolvate si o sa fie cel mai probabil rezolvate i continuare. Daca nu e ceva foarte mare sau foarte popular as zice sa il copiezi.

Dezantajul major cand folosesti orice dependinta e securitate. Daca i se fura omului contu de github poate foarte usor sa pushuiasca o versiune minora cu malware.

Noi avem un set de biblioteci custom “commons” pe care le mentinem si sunt sub version control. Sunt mai multe decat 10 linii de cod, care pot fi puse intr-o functie, sau dat copy paste prin diferite locuri.

Daca este ceva ce se poate gasi pe Google si este in numar de linii rezonabil sau este simplu de implementat “o implementez eu”.

Imi adece aminte si te un subiect postat de @IceRidder cu biblioteci de o linie de cod

sau asta. Mai bine ii dai copy paste si vezi ce teste are decat sa o mai adaugi in proiect si sa te numeri printre cei 886 de altelei care depind :grin:

2 Likes

he he… :slight_smile:

Am reusit sa ma chinui o saptamana cu un formular care ia si salveaza date la mai multe endpoint-uri.

Home | React Hook Form - Simple React forms validation (react-hook-form.com)

E o librarie foarte frumoasa, dar a trebuit sa o invat si pe asta.
Daca scriam pur si simplu formularul cu o simpla validare fara sa invat sa folosesc libraria imi lua jumatate din timp.

Cateodata o librarie e de ajutor sa tii un proiect mare in acelasi stil, dar te si incurca fiindca trebuie sa inveti sa faci ceva intr-un alt mod.

3 Likes

Ce bine ar fi daca ar fi atat de simplu ca exprimarea cu ‘a trage o linie’.

E cu ‘depinde’… iar factorii de care depinde pot fi al naibii de multi.

E cu depinde, nu ma astept la un raspuns universal.

Poate trebuia sa formulez la trecut intrebarea: Unde ati tras linia pentru a muta discutia spre exemple concrete.

Nu stiu cat de relevante sunt exemplele concrete.

Pentru proiectele mele open source implementez eu doar pentru ca pot si n-am chef sa adaug cine stie cate dependinte suplimentare, plus ca daca as pasa implementarea in librarii ar fi mai greu de inteles ce se intampla acolo, de catre altii care-s curiosi cum se face.

Uneori pentru ca asa inteleg chiar eu mai bine subiectul (ex, rezolvarea integralelor in aromanro/HartreeFock: A program implementing the Hartree–Fock (also post-HF)/self-consistent field method (also DIIS) with Gaussian orbitals (github.com)), alteori doar pentru ca e suficient de simplu (ex, obj loader in aromanro/SolarSystem: A solar system simulator with Verlet, using OpenGL for displaying. (github.com) sau aromanro/RayTracer: A ray tracing program (github.com)).

1 Like

Am o situație la lucru cu un script scris inițial ca și comand line program care folosește un executabil. S-a dovedit util local și vrem să-l integrăm în automation. Îs multiple wrappers deja dezvoltate dar costul mentenanței librăriei este mai mare decât outcome (am fi vrut ca binaryul să fie inclus în acele librării) așa că vom refactoriza scriptul pentru ce avem noi nevoie. Ce-i sigur îi precis.

1 Like

cam aici trag linia

Asta si:

  1. Daca incerci o biblioteca si iti ia mai mult de o zi sa faci ce ar trebui sa simplifice acea dependinta in the first place → mai bine o implementezi tu daca stii ca ai putea sa faci ceva functional in mai putin de o zi
  2. Daca simti vreodata ca reinventezi roata unde n-ar trebui → mai bine folosesti o biblioteca
  3. Daca biblioteca vine cu o tona de dependinte atunci cand tu ai nevoie doar de 1% din ea, dar face acel 1% de care ai nevoie foarte bine → implementezi tu cu inspiratie din acea bilblioteca sau gasesti o metoda sa iei din ea doar ce ai nevoie fara extra deps
2 Likes

Mie (din experienta pe frontend) mi se pare ca oamenii sar prea repede sa adauge o dependinta npm in loc sa “piarda” cateva ore sa implementeze o chestie relativ simpla.

De exemplu un simplu dropdown (poate nu e cel mai bun exemplu). In orice framework modern (ng/react/vue/etc.) sunt cateva linii de cod sa faci un dropdown simplu, animat CSS, fara brizbriz-uri. Am observat ca majoritatea oamenilor din echipa (in special juniorii) sar imediat sa adauge o dependinta (fara sa o verifice indeaproape) care de cele mai multe ori vine cu cateva dezavantaje majore:

  • bibliotecile publice sunt facute sa fie cat mai generice si sa satisfaca cat mai multe nevoi din alte sute/mii de proiecte, cerinte care de cele mai multe ori nu sunt necesare. Asta inseamna automat dead code in bundle-ul final
  • riscul de securitate crescut - cu cat mai multe dependinte, cu atat mai multi vectori de atac (depinde si de domeniul aplicatiei daca e relevant sau nu)
  • tech debt-ul - bibliotecile publice au release-uri destul de frecvente care ar trebui updatate periodic pentru bugfix-uri, security issues, etc. De cele mai multe ori e bataie de cap mai ales cand treci la major version updates.
  • behavior custom - de multe ori ai nevoie de chichița ta implementata care nici o biblioteca publica nu o suporta si atunci tot trebuie sa sari in codul altcuiva, sa contribui, etc.
5 Likes