Gestione delle dipendenze di terze parti

2

Sto cercando una strategia per gestire le mie dipendenze da terze parti. Non intendo i gestori di pacchetti e i tecnici dei fornitori, intendo un processo di prendere decisioni riguardo l'aggiunta di una lib di terze parti o di scrivere qualcosa da solo.

La mia personale attitudine è "non inventata qui sindrome" - ho sempre voglia di scrivere qualcosa da zero "per sapere come funziona tutto". A volte vedo un modo opposto di prendere questa decisione tra i miei colleghi quando ci immergiamo nell'inferno della dipendenza come 124 dipendenze ricorsive per un servizio nano che sta solo facendo una chiamata a un'API.

Quindi sono sempre sbilanciato. A volte spendo una grande quantità di tempo per reinventare qualcosa e la prossima volta spendo la stessa quantità di tempo per leggere tonnellate di documenti di librerie di terze parti solo per fare una piccola correzione.

Qual è la strategia per prendere decisioni sulle dipendenze di terze parti quando si sviluppa un prodotto finale commerciale e quando si sviluppa una libreria open source?

    
posta I159 01.08.2017 - 09:59
fonte

2 risposte

3

La decisione di utilizzare una libreria di terze parti non deve essere presa alla leggera. La decisione di scrivere qualcosa da solo, d'altra parte, dipende dalla quantità di lavoro necessaria per implementarla.

Come hai notato correttamente, le librerie di terze parti spesso dipendono da altre librerie. Ciò potrebbe significare che la libreria A dipende da B v1.0 + C v1.2, e la libreria D dipende da C v1.1 e potresti non essere necessariamente in grado di avere C v1.1 e C v1.2 collegati allo stesso tempo , efficacemente, A e D sono incompatibili.

Se utilizzi una libreria di terze parti, tieni presente i wrapper: Utilizzo di librerie di terze parti: utilizza sempre un wrapper?

Considera anche questi:

  • Problemi di sicurezza : le librerie di terze parti potrebbero avere noti problemi di sicurezza.
  • Tempo per imparare : a volte la cosa più difficile può imparare a utilizzare l'interfaccia, non a implementarla, il che significa che puoi anche scrivere tutto da solo
  • Sostituibilità : dovresti avere una strategia per sostituire una libreria di terze parti con un'altra libreria di terze parti o scrivere la funzionalità da solo
  • Problemi di licenza : se scrivi da solo, hai il copyright e non devi preoccuparti delle licenze e delle loro condizioni.
  • Tempo di avvio : il caricamento di una libreria casalinga semplice è più veloce del caricamento di una gigantesca libreria esterna gigantesca
  • Impronta di memoria : come per il tempo di avvio, le grandi librerie esterne consumano più memoria.
  • Rischio di bug : più grande è la libreria esterna, più è probabile che abbia dei bug.
  • Stabilità della versione : alcune librerie di terze parti non dispongono di un'interfaccia stabile, il che significa che l'aggiornamento della libreria interrompe tutto.

Vorrei basarmi su questi suggerimenti per valutare attentamente se si desidera utilizzare una libreria di terze parti o meno. Per un mio progetto, un'applicazione scientifica, ho deciso di utilizzare solo una libreria di grafici a linee e di implementare tutto il resto da solo. In realtà ho anche scritto la mia propria libreria di grafici a linee, ma non mi sono preoccupato di perfezionarla per ottenere grafici quanto più belli possibili, motivo per cui alla fine ho usato una libreria esistente.

    
risposta data 01.08.2017 - 12:53
fonte
0

Se si nascondono componenti di terze parti (e altro codice di infrastruttura) behnd un'interfaccia come descritto in the onion architettura puoi posticipare / ripristinare la tua decisione in qualsiasi momento. Pertanto, la decisione "sbagliato in anticipo" non è più costosa.

Puoi iniziare con qualcosa che già conosci / che hai già e modificarlo in seguito, se necessario.

Come effetto collaterale: avere interfacce di servizio rende l'unittesting / mocking molto più semplice.

    
risposta data 01.08.2017 - 15:06
fonte