In librerie riutilizzabili per uso domestico - riutilizzare come dll o come progetti?

Question

Abbiamo un bel po 'di codice riusabile al lavoro (una buona cosa). Ogni volta che creo un nuovo progetto che li usa sono solito includere i loro progetti come parte della mia soluzione e mi chiedevo se invece dovessi riutilizzarli come dll pubblicati. Il motivo (o la scusa) che includo il progetto è che se trovo un bug in uno di essi posso dirlo e correggerlo lì. Ma sembra che prenda la mia attenzione dal progetto a portata di mano.

(Non sono sicuro se questo dovrebbe essere CW dato che ci sono solo due risposte e sarei interessato a conoscere le vostre preferenze)

Answer 1

Ci sono alcune cose da considerare qui.

• Quanto tempo extra aggiungono queste librerie alla compilazione e vi interessa?
• Quante volte è necessario correggere i bug in essi?

Io uso librerie precompilate per qualsiasi codice che non cambi in mesi. Se ho bisogno di cambiare qualche codice più di una volta al mese in un pacchetto, quel pacchetto non è precompilato.

Preferisco la precompilatura per accelerare la compilazione del programma principale. Ma includo sempre i simboli di debug nel precompilamento, quindi se si verifica un errore, posso passare attraverso l'assembly precompilato con la stessa facilità con il resto.

Answer 2

Beh dipende in realtà se si è sul team responsabile per loro o se non siete sul team aggiungili alla tua fonte e risolvili man mano che procedi. Se non si è in quella squadra, utilizzali come cliente e i difetti dei file come li trovi altrimenti potresti diventare responsabile per il codice al di fuori del tuo ambito di lavoro. Se sei in un ambiente flessibile che potrebbe non avere importanza, per me potrebbe essere un problema essere improvvisamente il proprietario di un cambio di codice che non ho più voce in capitolo.

Answer 3

Una considerazione per questo è quanto frequentemente vengono riutilizzate le librerie citate. Se tendono ad essere utilizzati in progetti completamente diversi, devi stare attento a non dipingerti in un angolo, dove scopri che le modifiche apportate tre settimane fa alla libreria per supportare alcune nuove app si sono rivelate in grado di rompere i cambiamenti per alcune altre applicazioni.

Fondamentalmente quello che sto dicendo è che non si vuole resistere alla tentazione di apportare modifiche a una biblioteca, volenti o nolenti; meglio non mettere quella tentazione di fronte a te in primo luogo. Se una libreria è progettata per il riutilizzo, tutte le modifiche significative ad essa devono essere progettate e implementate con molta attenzione e sottoposte a test approfonditi con tutte le librerie/app dipendenti da. Diventa molto più difficile adottare un approccio disciplinato quando hai letteralmente la fonte di fronte a te, in attesa di essere modificata.

Il mio approccio è creare soluzioni delle librerie correlate ; per esempio, potrei avere un assembly per le interfacce core e le classi astratte, alcuni altri assembly per diverse implementazioni concrete, un altro per i test unitari e così via. Se ci sono strati di librerie riutilizzabili dipendenti, spesso vengono tutte raggruppate nella stessa soluzione.

Ma si ferma a livello di applicazione. Qualsiasi progetto che non è sempre che viene distribuito con le librerie principali non condivide una soluzione, fa semplicemente riferimento alla DLL compilata. Mi costringe a essere disciplinato sui cambiamenti di libreria e non a modificarlo per supportare alcune funzioni specifiche dell'interfaccia utente.

Non so se questo è l'approccio "giusto", ma sono stato morso prima apportando modifiche premature alle librerie senza testare correttamente le dipendenze, ed è sempre stato il risultato di essere troppo concentrato su una singola app e non pensare agli effetti collaterali. La mia opinione è che quando si lavora su una libreria, è necessario concentrarsi sulla libreria stessa e non su come viene utilizzata in un particolare scenario.

Answer 4

Per la situazione in cui una libreria viene riutilizzata da più soluzioni indipendenti o quando la libreria è gestita da un'altra squadra rispetto al team che la usa, penso che la regola più importante da tenere a mente è che una particolare versione di una la soluzione dovrebbe normalmente essere correlata a una versione specifica di tale libreria.

Chiediti quanto segue: quale versione della libreria ottengo quando eseguo il checkout del codice sorgente della soluzione da sei mesi fa? Se la risposta è: "Sempre la versione più recente della libreria", ciò potrebbe essere problematico.

Ho lavorato a un progetto in cui gli sviluppatori hanno pubblicato automaticamente nuove versioni delle loro DLL sulla rete locale. La soluzione su cui stavamo lavorando ha appena fatto riferimento alle DLL da quella particolare posizione. Il problema era che non sapevamo mai quale versione della libreria stavamo compilando e più di una volta, dopo aver provato, abbiamo rilasciato una versione della nostra applicazione che si è rotta perché improvvisamente è stata rilasciata una nuova versione di quella libreria (che non prova).

Ma diventerà ancora più evidente quando si sta sviluppando una versione 2 dell'applicazione, ma è necessario mantenere una versione 1 rilasciata della propria applicazione. Si desidera rilasciare patch della versione 1 con la stessa versione di libreria con cui è stato rilasciato inizialmente (quando il bug non si trova in quella libreria) perché altrimenti si dovrà ripetere nuovamente l'intera applicazione.

Per questo motivo di solito aggiungo tutte le librerie che uso (che non sono nella GAC ​​per impostazione predefinita) come parte della mia soluzione e li controllo nel controllo del codice sorgente. In questo modo ho il pieno controllo sulle versioni che la soluzione utilizza in un dato momento.