Le migliori pratiche per la condivisione di piccoli frammenti di codice tra i progetti

Se sono davvero metodi / classi riutilizzabili, potresti scriverli in un piccolo numero di librerie "Swiss Army Knife". Lo facciamo abbastanza spesso nella mia azienda; li chiamiamo librerie framework:

• Framework.Data - Utilità per lavorare con le query del database.
• Framework.ESB - Metodi standard per l'interazione con il nostro bus di servizio aziendale
• Framework.Logging - Sistema di registrazione unificato
• Framework.Services - Utilità per l'interazione con i servizi web
• Framework.Strings - Utilità per la manipolazione avanzata delle stringhe / ricerca stringa fuzzy ecc.
• ...

In tutto, ci sono circa una dozzina di librerie. Puoi davvero distribuire il codice come meglio credi, quindi non devi finire con centinaia o buttare tutto in un unico gigantesco assemblaggio. Trovo che questo approccio si adatti perché solo alcuni dei nostri progetti avranno bisogno di Framework.Data e solo pochi avranno mai bisogno di Framework.Strings , in modo che i consumatori possano selezionare solo le parti del framework che sono rilevanti per il loro particolare progetto.

Se sono davvero solo frammenti e non metodi / classi reali che possono essere facilmente riutilizzati, potresti provare a distribuirli come frammenti di codice nell'IDE (ad esempio Snippet di codice di Visual Studio ). I team con cui ho lavorato in passato avevano una libreria di frammenti di codice comune che rendeva più facile per tutti seguire le nostre pratiche di codifica standard anche con il codice interno.

Non sono d'accordo con la risposta accettata per molte ragioni.

Nella mia esperienza, quando vedo le librerie "varie" come la risposta accettata, sono una scusa per reinventare la ruota (o non inventato qui (NIH) ) - un peccato molto più grande della violazione di Dont Repeat Yourself (DRY) .

A volte violando DRY può essere un ragionevole compromesso, è meglio che introdurre un accoppiamento stretto. Il riutilizzo è una preoccupazione secondaria rispetto al buon design orientato agli oggetti. Un po '(intendo una piccola quantità, applica la Regola dei tre ) della duplicazione è più facile da capire di codice di spaghetti.

L'approccio di numerose librerie di scopi generali non è un buon esempio. Porta a una granularità fine dell'assemblaggio e troppi assembly sono cattivi. Recentemente ho ridotto un interno da 24 librerie a 6 librerie. Ha migliorato il tempo di compilazione da diversi minuti a ~ 20 secondi. Visual Studio è anche più lento da caricare e meno reattivo con più assiemi. Avere troppe librerie porta anche a confusione su dove il codice dovrebbe vivere; preferisco regole più semplici e semplici.

Perché le cose nel .Net Framework non sono abbastanza buone? Il quadro è abbastanza grande; molte volte ho visto il codice che re-implementa cose che già esistono lì. Assicurati davvero che i tuoi framework stiano colmando lacune nel framework .Net e non esista solo per ragioni estetiche (per esempio "Non mi piace il framework .Net qui" o forse alcuni ottimizzazione prematura )

L'introduzione di un altro livello nella tua architettura ha un costo di complessità significativo. Perché lo strato esiste? Ho visto un falso riutilizzo, con ciò intendo dire che il codice è costruito su un framework interno. Sarebbe stato molto più efficiente implementarlo direttamente sulle librerie standard.

L'uso di tecnologie standardizzate (come il framework .Net e le popolari librerie di terze parti / open source) presenta vantaggi che spesso superano i vantaggi tecnologici comparativi derivanti dalla creazione di te stesso. È più facile trovare talenti che conoscano queste tecnologie e i tuoi sviluppatori esistenti investiranno di più nell'apprenderlo.

I miei consigli:

• Non condividere questo codice.
• Crea una nuova libreria se ha uno scopo coesivo non utilizzare il schema di progettazione della palla di fango .
• Riutilizza le librerie di terze parti esistenti laddove possibile.
• Preferisci un minor numero di assiemi, con regole più semplici su dove dovrebbe essere il codice.

Per piccoli bit di codice - diciamo una singola classe senza dipendenze - tendiamo a copiare e incollare il codice nei progetti. Sembra una violazione di DRY, e ammetto che può essere a volte. Ma a lungo termine è stato molto meglio che avere una sorta di progetto di comuni commessi con più teste per diversi motivi.

In primo luogo, è più semplice avere a portata di mano il codice, specialmente quando si creano e si debuggano.

In secondo luogo, invariabilmente vorrai apportare qualche piccolo ritocco al codice comune per quel progetto. Se hai una copia locale della fonte di quanto tu possa solo fare il tweak e chiamarlo un giorno. Se è presente una libreria condivisa, è possibile che tu stia prendendo in considerazione la libreria e quindi assicurati di non rompere tutte le altre app o creare un incubo di versioning.

Quindi, se non è abbastanza robusto per il proprio spazio dei nomi, tendiamo a inserirli nei bit appropriati del progetto e a chiamarli un giorno.

La seconda soluzione che descrivi non è poi così male. In .NET si fa riferimento anche a un assembly dal GAC anche se si utilizza solo una singola classe di esso. "Trascinare il codice irrilevante" non è un problema come potresti pensare. In questo caso è fondamentale almeno mantenere metodi e classi correlati organizzati in diversi spazi dei nomi. Inoltre, devono essere applicate buone pratiche per la progettazione dell'API per evitare che questa soluzione diventi un disastro.

Se si tratta di bit di codice molto piccoli, penso che il seguente approccio sia un buon complemento per un progetto comune: consentirgli di essere duplicati in diverse soluzioni. Affrontali come le migliori pratiche: documentale e comunicale alla squadra.

Ho sempre lavorato solo in ambienti "enterprise" in cui questo genere di cose è stato un problema e ogni volta è stata adottata la seconda opzione. Per la maggior parte, ha funzionato bene perché non c'è stato alcun vincolo sull'impronta dell'applicazione.

Tuttavia, dopo aver trascorso l'ultima settimana con una start-up che sta eseguendo il proprio server Nuget, sono propenso a suggerire questa alternativa come valida. Naturalmente i problemi che mi aspetto di emergere saranno intorno alla scoperta-abilità.

Se i progetti sono adeguatamente granulari e gli spazi dei nomi sono ragionevoli, allora posso vedere che questo sta diventando un approccio popolare nei luoghi.

Di recente ho pensato a questo e quello che mi è successo è stata una grande libreria di metodi comuni, come è stato detto finora, ma con una svolta. Il progetto della libreria ti permetterebbe di configurare in fase di compilazione quali pezzi sono inclusi come il progetto BusyBox . Con questo approccio, puoi avere un repository di libreria in stile "kitchen sink", ma solo prendere gli strumenti di cui hai bisogno durante la compilazione.

GitHub ha uno strumento piuttosto utile per il salvataggio di frammenti di codice link

Memorizza i tuoi snippet come repository git che puoi mantenere privati o utilizzare per condividere frammenti con altre persone.

A seconda delle dimensioni del team / progetto / società questa sarà una cosa piuttosto difficile da fare efficacemente, a meno che non sia già integrato nel tuo ambiente in qualche modo, e ogni soluzione che troverai (se la implementerai) costerà un po 'di soldi . (Potrebbe salvarti di più, ma non sarai in grado di misurare facilmente). Dovrai controllare se vale il prezzo. Tieni presente, inoltre, che le soluzioni riutilizzabili tendono a diventare astratte e spesso si adattano a molte situazioni, ma senza essere ottimali.

In ogni caso, se vuoi farlo per il codice prodotto da più di una persona, in un primo momento avrai bisogno della consapevolezza di tutti e della cooperazione. Questo include sviluppatori e manager.

Quindi dovrai assicurarti di conoscere l'ambito in cui vuoi farlo. Squadra? Progetto? Dipartimento? Azienda? A seconda della risposta, il tipo di codice che inserirai in tali soluzioni varierà, così come la granularità con cui personalizzi le DLL. Una volta che hai deciso su questo qualcuno (preferibilmente con un certo entusiasmo per l'idea - tu?) Dovresti sederti e iniziare a mettere una struttura in questo.

Tuttavia, la creazione di tali DLL non sarà sufficiente per fare il trucco. Per renderli utili dovrai pubblicizzarli (agli utenti e ai contributori) e mantenerli come qualsiasi altro software, il che di solito significa che devi metterli a capo di qualcuno per un lungo periodo di tempo. Avrai bisogno anche di una documentazione affidabile, che avrà anche bisogno di manutenzione. Con un po 'di fortuna e cooperazione potresti finire con alcune buone pratiche, ma può anche facilmente evolvere in un progetto a se stante, a seconda delle dimensioni e del numero di squadre coinvolte. E per questo avrai ancora bisogno del supporto di gestione.

Ho avuto un sacco di problemi, e la mia soluzione preferita è di pubblicare il codice in un repository abilitato per github / pubic web. risolve un sacco di problemi -

1. facile accesso e facile condivisione. cvs / svn / enterprise-repos significa estrapolare il progetto in più spazi di lavoro IDE e talvolta dover cambiare workspace o computer solo per fare riferimento a un piccolo snippet di codice.
2. supponendo che questi frammenti di codice non siano pezzi di codice proprietari / classificati e siano variazioni della conoscenza disponibile pubblicamente, pubblicandoli su un repo pubblico come Github significa che altri lo guarderanno e potrebbero persino contribuire.
3. pubblicare qualcosa di pubblico dominio sotto il tuo nome ha l'ulteriore pressione della reputazione. ricontrollerai e aggiornerai le cose, poiché riflette sulle tue abilità come programmatore.
4. aggiornamenti. il fatto di conservare frammenti di codice in un repository è, se uno snippet non è stato utilizzato da molto tempo, potrebbe diventare obsoleto (contiene apis / libs obsoleti). esempio: snippet di codice java per leggere un file. avresti potuto trovare il modo migliore per farlo nel 2009, ma nel 2014 uscirà un nuovo file API che cambia tutto. il tuo frammento? ancora bloccato nel 2009. in un repo pubblico, le cose verranno aggiornate, sia da voi (perché il proiettile 3), i vostri compagni di squadra, o qualche membro della popolazione generale del programmatore, e nel processo, potreste anche ricevere suggerimenti per aggiustare qualcosa che avresti potuto sbagliare per molto tempo.

Una cosa che vorrei raccomandare, non importa dove mantieni i tuoi frammenti, fai sempre roba su google prima di usarla. le cose cambiano tutto il tempo i frammenti salvati fanno risparmiare tempo, ma generano anche compiacimento .

Abbiamo un progetto separato "utilità" in cui archiviamo tutti questi piccoli metodi insieme ai test.

Quando un progetto ha bisogno di qualche utilità, aggiunge semplicemente il file sorgente con il metodo richiesto con "aggiungi come collegamento".

Ciò significa che non sono state aggiunte dipendenze del tempo di esecuzione (a meno che il file incluso ne abbia bisogno).

Il sistema ha funzionato bene, ma come tutti gli altri ha bisogno di diciplin su cosa sia un'utilità. Richiedere una copertura di prova elevata ha funzionato bene per noi e i test sono anche una buona documentazione di utilizzo. La scoperta è ancora un problema irrisolto per noi.

Una complessità con il progetto di utilità è decidere il livello di visibilità sugli articoli. Una regola empirica è che i metodi dovrebbero essere interni e le strutture dati pubbliche.

La mia azienda utilizza servizi web intranet-locali. Abbiamo alcuni servizi Web che vengono configurati come servizi Web interni comuni e quando un altro progetto deve accedere a uno dei servizi, invia una richiesta http con un'interfaccia definita. Poiché si trova sulla intranet, ospitato nella stessa server farm, queste richieste sono molto veloci.

Ovviamente funziona solo con le app in Internet (e funziona solo in millisecondi quando si trova sulla stessa rete locale), ma ha alcuni vantaggi davvero interessanti.

Di recente ho creato questo servizio: Snip2Code ( link ).

È un modo interessante per condividere solo i frammenti (non interamente librerie) con il tuo team. Rompe il solito punto di creare librerie comuni che dovrebbero essere referenziate in altri progetti, e secondo me questa è una visione preziosa.

Inoltre, ci sono molti scenari in cui l'uso di una libreria comune semplicemente non si applica: prendiamo in considerazione ad esempio alcuni modelli di design come Singleton, Strategy o Observer. Puoi creare librerie per supportare tali modelli, ma ancora non c'è copertura al 100%.

Il vero bisogno è di avere uno strumento per condividere pratiche comuni tra la squadra. Ho provato ad usare gli schemi di Github ma sono bloccato dalla loro ricerca (davvero scarsa) e dal fatto che non posso condividerli solo tra la mia squadra e non con altri ...

(Disclaimer: sono uno dei fondatori di Snip2Code, e sono stato - insieme ai miei co-fondatori - nella tua stessa mentalità qualche tempo fa: è per questo che abbiamo deciso di iniziare questo progetto !!)