Duplicare Funzionalità Tra progetti multipli

Question

Al momento sto lavorando su due siti di social networking che hanno molto in comune, ma sono tipicamente differenti. Mi ritrovo a scrivere un sacco dello stesso codice per entrambi (compreso UI), e si chiedeva se v'è una buona pratica che limiterà la duplicazione del codice.

Uno dei problemi principali è che questi progetti sono molto indipendenti vicenda e probabilmente hanno più differenze che similaries presto. Inoltre, una volta che il lavoro iniziale è fatto, potrebbero essere passata ad altri programmatori, in modo da avere le librerie di codice condivise potrebbero finire per essere un grosso problema.

Tutti i suggerimenti da parte di persone che potrebbero aver avuto a che fare con una situazione simile?

PS: io sono l'unico sviluppatore su entrambi questi progetti, e sembra che sta andando a rimanere in quel modo per un po '

.

Answer 1

Astraendo funzionalità condivisa di nuovo ad un quadro o una libreria con interfacce definite e le implementazioni di default è un modo comune per gestire questa situazione. Ad esempio, l'architettura a plugin, se si sceglie di supportare uno, è probabilmente qualcosa che potrebbe essere condivisa tra tutti i vostri progetti. Il più delle volte le cose che vuoi condividere sono abbastanza funzionalità di base o le funzionalità relativamente astratto che può essere facilmente personalizzato. I primi sono più facili da riconoscere e fattore fuori per librerie comuni. Quest'ultima può essere a volte più lavoro che semplicemente ri-attuazione del codice con lievi modifiche (condivisione modelli anziché codice).

Una cosa si vuole stare attenti è quello di lasciare l'attuale riutilizzo guidare la progettazione di librerie comuni, piuttosto che venire con un'architettura condivisa in anticipo. E 'molto forte la tentazione di farsi prendere in progettazione dei quadri e astrazione fuori in comune. Purtroppo si trovano spesso che il comune non si sviluppa o si sviluppa in una direzione diversa da quella che vi aspettavate e si finisce per riscrivere o gettare via gran parte del quadro - o, peggio ancora, la conservazione e il mantenimento di codice non utilizzato. Lasciate YAGNI (che non sono gonna bisogno) essere la vostra guida e il ritardo refactoring di librerie comuni fino a quando in realtà hanno un bisogno.

Answer 2

Ci sono un paio (almeno) di diversi approcci qui, e si potrebbe certamente utilizzare entrambi. In primo luogo si potrebbe rimuovere alcuni codice comune per un progetto separato e basta chiamare quel codice staticaly. Questo è abbastanza facile da fare e io a volte prendere questo approccio con semplici funzioni di supporto che, probabilmente, non appartengono a una classe nel mio progetto principale - un buon esempio potrebbe essere una libreria matematica o qualcosa di simile. L'altro approccio è quello di estrarre funzionalità comuni in una classe o interfaccia che poi eredita ed estendere. A seconda di quale codice si sta cercando di riutilizzare si potrebbe utilizzare uno (o entrambi) di questi approcci.

Ho il sospetto che sarà più facile di quanto si pensi. Da provare con qualche semplice codice, impostare un nuovo progetto nella stessa soluzione, fare riferimento la libreria dal codice esistente e vedere come va. V'è inoltre alcuna ragione per non fare riferimento il vostro progetto condiviso in molteplici soluzioni sia.

librerie di codice

Dopo aver condiviso non devono essere un problema se lo sviluppo viene consegnato off. Per ora è possibile avere i 2 siti di riferimento la stessa libreria (o librerie), che si mantiene, ma se e quando si dividono i progetti ad altre squadre puoi lasciare una copia del codice condiviso ad ogni squadra.