Valutazione di librerie di terze parti

4

Nella nostra azienda, utilizziamo frequentemente librerie e framework di terze parti nei nostri prodotti. Spesso ci troviamo di fronte al compito di valutare una o più librerie che soddisfano pienamente requisiti simili (in un caso specifico dovevamo scegliere tra alcune librerie di crittografia). Spesso facciamo un semplice prototipo per cercare di capire, se la biblioteca funziona in qualche modo per noi. Tuttavia, spesso i prototipi diventano molto complessi e quando siamo in un punto in cui scopriamo che la libreria non è adatta ai nostri scopi, è stato speso un sacco di tempo, che avremmo potuto usare noi stessi per scrivere la funzionalità desiderata.

La mia domanda sarebbe, hai o eserciti delle linee guida quando valuti la valutazione di librerie di terze parti? Più nello specifico, hai qualcosa come un tempo massimo che sarà speso per i prototipi e hai i requisiti generali per le librerie che usi (problemi di licenza, supporto, documentazione, ...)?

    
posta Benni 18.08.2011 - 22:10
fonte

2 risposte

4

Parlando solo per me stesso (e avendo fatto decine di questi):

Se è closed-source, non vale il tempo della mia azienda.

Se la licenza open source causasse sopracciglia anche leggermente sollevate in Legal, non vale il tempo della mia azienda. LGPL va bene, Apache va bene, MIT va bene, GPL (qualsiasi versione) non lo è.

Se la documentazione non include i documenti dell'interfaccia completa minima, un tutorial veloce e una FAQ, non vale il tempo della mia azienda.

Se la libreria mi richiede di costruirlo prima che io possa usarlo, non vale il tempo della mia azienda.

Se la libreria non sembra avere una comunità di utenti rilevabile da google, non vale il tempo della mia azienda.

Se il rivenditore della biblioteca non pubblica una roadmap o non apre il proprio sistema di tracciamento dei problemi (anche di sola lettura), questi sono dei brutti segni, ma non dei downlink immediati a meno che tutti gli altri candidati non facciano meglio.

Questo taglia fuori il deadwood. Una volta che siamo lì, è il momento di progettare il bake-off. Un utile stufato deve avere una scala temporale fissa, un insieme fisso di criteri di valutazione e un set di caratteristiche fisse, che devono essere tutte scritte . Tutte le funzionalità del set di caratteristiche dovrebbero essere legate a un criterio di valutazione (idealmente esattamente uno dei criteri di valutazione). Per periodi di pausa più lunghi (in particolare quelli con > 2 candidati), dovrebbe esserci un checkpoint. Al checkpoint, tutti i candidati dovrebbero essere esaminati per vedere se qualcuno di loro è completamente dominato su tutti i criteri di valutazione. Qualsiasi candidato così dominato (o anche quasi completamente dominato) dovrebbe essere abbandonato a metà strada attraverso il bakeoff.

Tutto ciò sembra pignolo, ma l'alternativa sembra essere infinita criteri di valutazione che vanno nelle erbacce fino a quando la giustificazione aziendale originale per la tecnologia è obsoleta o ridotta attraverso la pura stanchezza.

    
risposta data 18.08.2011 - 23:14
fonte
3

La singola linea guida più importante che io cerco di seguire sempre quando scelgo cose del genere è di avere un documento checklist

  • per la libreria di terze parti la mia lista potrebbe essere simile a questa: maven; maven - versione di rilascio; esempi di codice; open source; javadoc comprensibile; API compatta; riferimento alle specifiche utilizzate; riferimento a specifiche pubbliche utilizzate (come RFC, JSR ecc.); rilascia changelog; bug tracking; attivo; feedback positivo (la versione più recente della lista documentata e spiegata qui: csv api per java :)

do you have something like a maximum time that will be spend on prototypes

In casi come te descrivi - sì. Più in generale, ogni volta che sento qualcosa che assomiglia a una scadenza, la aggiungo immediatamente alla mia lista di controllo. ...; data provvisoria per decidere se accettare o rifiutare un prototipo

    
risposta data 19.08.2011 - 00:26
fonte

Leggi altre domande sui tag