Ti chiedi come mantieni la motivazione in utilizzando un determinato progetto API open source?
Il trucco sta nel capire quali progetti Open Source sono i migliori. La principale qualifica in Open Source è il fatto che hai accesso al codice sorgente, che è estremamente utile quando devi scoprire come funzionano le cose (che di solito accade quando hai bisogno di un comportamento per cambiare in qualche situazione), ma questo non implica qualcos'altro. Ciò include la qualità del progetto che non ha nulla a che vedere con l'apertura della fonte.
La qualità consiste in diverse cose più o meno sottili quando si parla di un progetto di codice:
- Quanto è stata progettata l'API? Il codice che devi scrivere per chiamare effettivamente l'API può essere letto facilmente?
- Quanto ben scritto è il codice effettivo nell'API? È facile capire cosa succede? Le strutture dati sono ben scelte e non hanno costose caratteristiche di runtime? I nomi delle variabili sono ben scelti? Il codice è conforme a uno standard di codifica?
- L'API è documentata? Questo è sia il design che javadoc del codice attuale ed è utile? Questo è più importante di quanto tu possa pensare, poiché mostra la maturità del codice.
- Il progetto ha una pagina Web? È aggiornato e senza collegamenti interrotti? Fornisce un facile accesso a codice sorgente, download e documentazione?
- Il progetto ha una community e mailing list? Gli archivi sono disponibili e accessibili? La comunità è utile?
Tutte queste cose sono utili da tenere a mente quando si sceglie se si desidera utilizzare un dato progetto open source oppure no. Qualsiasi derivazione dai migliori dovrebbe far lampeggiare un segnale di avvertimento perché è un'indicazione che questo non è un progetto best-of-breed.
Poi, quando hai trovato il progetto, ti piace quello che vedi, c'è il test finale:
- Quanto è difficile essere operativi da zero con un semplice programma che richiama l'API in un modo utile?
Questo dovrebbe essere
- spiegato in una posizione facile da individuare sul sito Web del progetto e / o nella documentazione del pacchetto di download.
- facile da ottenere correttamente - la documentazione deve essere accurata, il programma semplice da scrivere o adattarsi da un dato, semplice esempio ed entrambi ben spiegati e facilmente comprensibili.
- veloce a destra - se hai bisogno di eseguire qualsiasi debug a questo punto per far funzionare il programma come spiegato, qualcosa è molto sbagliato.
Se è evidente che questo è un caso d'uso anticipato e prioritario, allora questo dovrebbe essere banalmente semplice. Se è evidente che il progetto non si preoccupa di questa particolare cosa, allora vorrei strongmente considerare di non usarlo! Se è in salita qui, sarà in salita molte, molte volte dopo, e sarà meglio non usarlo.