Librerie di codice comuni riuscite [chiuso]

Un'istruttiva storia dell'orrore è Pattern di errore . Fondamentalmente l'eccessiva generalizzazione del codice è considerata un anti-modello. Se si creano librerie di codici comuni, assicurarsi che rimangano il più possibile accoppiati liberamente. Cerca di tendere verso un'architettura di toolbox, dove scegli ciò di cui hai bisogno a seconda del progetto su cui stai lavorando, invece di una libreria monolitica di tipo Big Core che può fare tutto, tranne l'evoluzione.

Credo che si dovrebbe cercare di raggiungere un buon equilibrio tra la progettazione iniziale e lo sviluppo organico . Più una libreria comune viene utilizzata da parti esterne, più è difficile cambiare la sua API una volta pubblicata. Quindi dovrebbe essere ben pensato e coerente sin dall'inizio. Tuttavia, è pensato per essere utilizzato da altre persone, quindi dovrebbe seguire e adattarsi alle esigenze del cliente piuttosto che soddisfare semplicemente alcuni principi del design accademico.

In pratica, la comunicazione tra gli sviluppatori della biblioteca e i loro (potenziali) clienti è fondamentale. I progettisti devono testare ogni idea dell'API contro la vita reale prima di impegnarsi in essa . Josh Bloch ne parla in Coders at Work : scrive sempre molto codice per utilizzare effettivamente le sue API in fase di sviluppo, anche quando questi sono solo uno scheletro formato a metà senza alcuna reale funzionalità. Ciò gli fornisce un prezioso feedback per migliorare le interfacce e renderle facili da usare e non ambigue per i casi d'uso comuni.

La convenzione di denominazione dovrebbe essere in atto. Rendi il nome di classi, funzioni, eventi, ecc. Autoesplicativo. Ciò contribuirà a trovare la funzione ed evitare la duplicazione / confusione.

Almeno per C ++, penso che uno degli approcci più interessanti sia la libreria Loki di Andrei Alexandrescu, spiegata in < a href="http://rads.stackoverflow.com/amzn/click/0201704315"> Design C ++ moderno .
In particolare la progettazione della classe basata su criteri , fornisce all'utente della libreria un modo per configurare esattamente come vogliono moduli per comportarsi e lavorare.

Sono favorevole all'approccio organico, finalizzato alla creazione di una libreria di utilità piccole, indipendenti, piuttosto che di grandi quadri.

Ecco come lo facciamo (in Java), nel mio attuale posto di lavoro. Abbiamo inserito il nostro codice comune di scopo generale in un singolo progetto. Gli sviluppatori lo aggiungono come meglio credono. Di solito il codice comune inizia come codice specifico del progetto e viene fornito in quanto diventa più generalmente utile. Se blocchi di funzionalità diventano troppo grandi, vengono scorporati in un progetto separato. Ognuno di questi progetti si basa su un barattolo. Rifattiamo con cautela e usiamo i test unitari per mantenere stabile la libreria.

Il codice sorgente è tutto in CVS, ma qualsiasi sistema di controllo delle versioni popolare avrebbe fatto il lavoro. Le applicazioni aziendali che utilizzano la libreria comune funzionano in due modi. La maggior parte si basa solo sull'ultimo codice impegnato. Alcuni richiedono più certezza e utilizzano i tag CVS per controllare la versione del codice sorgente che stanno utilizzando. Un terzo modo, che non usiamo, sarebbe quello di costruire i codici comuni come librerie esterne: artefatti pre-costruiti, mantenuti separatamente.