Devo impostare l'ambiente in modo predefinito per qualcuno che utilizza la mia libreria?

Question

Ho avuto questo dibattito con un amico in cui ho una libreria (il suo pitone ma non l'ho incluso come tag come la domanda è applicabile a qualsiasi lingua) che ha alcune dipendenze. Il dibattito è se fornire un ambiente predefinito nell'inizializzazione o forzare l'utente del codice a impostarne esplicitamente uno.

La mia opinione è di forzare l'utente come esplicito ed eviterà la confusione e chiarire a cosa stanno puntando.

Il mio amico è più sicuro e più conveniente per impostazione predefinita in un ambiente e consente all'utente di eseguire l'override se lo desidera.

Pensieri? Ci sono buone referenze o esempi/modelli in librerie popolari che supportano uno dei nostri argomenti? inoltre, qualsiasi blog o articolo popolare che discute questo punto di progettazione dell'API?

Answer 1

Non ho riferimenti, ma qui sono i miei pensieri come potenziale utente di tale libreria.

Penso che sia utile avere una configurazione predefinita disponibile per consentire agli sviluppatori di valutare rapidamente la libreria. Non voglio dover passare attraverso una serie di configurazioni solo per vedere se la libreria farà ciò di cui ho bisogno. Una volta sono felice che la libreria farà ciò che mi serve, quindi sono felice di configurarla nel modo che voglio.

Un buon esempio è il framework ASP.Net MVC di Microsoft. Quando si crea un nuovo progetto MVC, si aggancia a un provider di autenticazione e appartenenza predefinito, che consente allo sviluppatore di ottenere rapidamente un'applicazione funzionante. È anche facile configurare diversi provider da utilizzare se quelli predefiniti non soddisfano i requisiti dell'applicazione in questione.

Come esempio leggermente diverso, Atlassian Confluence è un software wiki che supporta molti diversi database back-end. Atlassian avrebbe potuto scegliere di non avere alcuna configurazione predefinita del DB, ma invece Confluence viene fornito con un database predefinito, semplice e basato su file per consentire agli utenti di valutare il software. Per le installazioni di produzione puoi quindi collegarti a Oracle, SQL Server, MySQL o qualsiasi altra cosa tu voglia.

Ci possono essere casi in cui un configuratino predefinito per una libreria non ha molto senso, ma penso che sarebbe un caso speciale, piuttosto che una regola generale.

Answer 2

Dipende. Se è possibile fornire valori predefiniti sensibili, è possibile farlo: renderà la vita più facile agli utenti occasionali della libreria in quanto possono impostare solo le impostazioni pertinenti, in contrapposizione a tutto l'ambiente (con possibilmente impostazioni le cui implicazioni non capisco completamente (ancora)). Hai ragione, che in situazioni è possibile questo porta a frustrazione e confusione poiché le impostazioni predefinite potrebbero causare comportamenti imprevisti (imprevisti dell'utente (inesperto)) - devi valutare la ridotta frustrazione di convenienza rispetto al prezzo di non- predefinite comprese per effettuare la scelta per ciascuna di queste impostazioni predefinite, scelta che potrebbe influire sulla scelta anche per altre impostazioni correlate

D'altra parte, se non vi sono impostazioni predefinite sensibili (ad es. credenziali DB, indirizzo remoto), è necessario richiedere all'utente di fornire tali impostazioni.

La chiave in entrambi i casi è quella di fornire informazioni sufficienti nella documentazione della libreria e nei messaggi di errore (sia per le impostazioni mancanti o in conflitto) che l'utente può capire che cosa effettivamente tali impostazioni significano/controllo senza dover leggere il codice sorgente della libreria.Questa parte è difficile perché 1) è usualmente noiosa dal punto di vista dello sviluppatore di librerie (quindi è spesso trascurato) e 2) la documentazione deve essere scritta dalla mentalità di un principiante alla biblioteca, che è spesso diversa dal punto di vista dello sviluppatore della biblioteca - quest'ultimo conosce le implicite connessioni/implicazioni, il primo deve essere raccontato in modo comprensibile.

Answer 3

Anche se non esattamente identico in termini di dominio del problema, questo mi sembra l'argomento Convention over Configuration.

C'è stato molto slancio dietro CoC negli ultimi anni e, secondo me, ha molto senso. Finché la flessibilità non è persa, hai tutto da guadagnare. Lo sviluppo a basso attrito è quello che ci interessa, e se devo configurare ogni aspetto della tua API per farlo funzionare, sono meno incline a usarlo su un'altra API di uguale funzionalità.

Mi piacciono i podcast di Hanselman, quindi se volete ascoltare un po 'di luce, date un'occhiata allo this podcast.

Answer 4

Penso che la tua domanda abbia bisogno di qualche chiarimento. Per i principianti, non penso che una libreria debba avere alcuna configurazione di runtime. In termini di dipendenze, le dipendenze della libreria devono essere gestite in modo appropriato per l'ambiente per cui sono state scritte. In Python, tali dipendenze devono trovarsi nel file setup.py (sotto requisiti), e in ultima analisi quel file dovrebbe soddisfare i requisiti di qualsiasi servizio si preveda di renderlo disponibile su (cioè pypi per python).

Per le applicazioni, è assolutamente necessario richiedere la configurazione di runtime, ma è necessario provare ad avere valori predefiniti sensibili. Se l'applicazione dipende dalle librerie, tale dipendenza dovrebbe essere gestita allo stesso modo in cui verrebbe gestita una dipendenza da libreria, anche se tali informazioni potrebbero essere ridondanti nel contesto di un programma di installazione (se necessario). Per la maggior parte gli script di prima esecuzione e il loro ilk dovrebbero essere separati dal programma di installazione/rpm.

Per i framework Web, è tipico che l'app porti con sé la configurazione e che probabilmente debba essere installata in modo diverso rispetto alle applicazioni tradizionali. Qui, l'unica cosa che puoi fare è provare a seguire le convenzioni di qualsiasi struttura tu stia scrivendo.