Una società di software dovrebbe avere un team dedicato per le biblioteche di ricerca e / o utilità?

Un punto importante è che è impossibile sviluppare una buona struttura in totale isolamento. I buoni quadri sono coltivati biologicamente : quando un programmatore nota che ha bisogno di alcune funzionalità specifiche, lo aggiunge al framework, e così il framework cresce poco a poco - al contrario di architettare una "struttura perfetta" su front, che non funziona mai, perché l'architetto non può essere a conoscenza di tutti i casi di utilizzo alla fine.

Naturalmente, la crescita organica del framework ha il rovescio della medaglia che la sua integrità interna potrebbe non essere troppo buona e si trasforma in spaghetti. Se il tuo team mantiene una buona comunicazione interna, allora potresti essere in grado di combinare il meglio di entrambi i mondi: un team di architetti separato che mantiene l'integrità del framework, ma costruendo per reali esigenze degli utenti finali (sviluppatori).

La mia sensazione è no.

Quello che sospetto che tu possa trovare se lo facessi è che invece di avere gruppi individuali che producono librerie che nessuno al di fuori di quel team ha usato, avresti un gruppo specializzato che produce librerie che nessuno al di fuori del team ha usato ( e così facendo a costi aggiuntivi considerevoli).

Ci sono vari problemi con il tipo di squadra che descrivi, ma per me il principale è che non risolve il problema che hai effettivamente.

Il problema che hai non è colui che produce le librerie (dal suono delle cose hai già molte soluzioni a questi problemi, quindi come potrebbe aiutarne uno?), è che le squadre non stanno parlando e interagendo.

Ci sono buone ragioni per cui i team non si riutilizzano a vicenda il codice (ad esempio che i problemi mentre superficialmente simili sono sottilmente diversi, o che il tempismo del progetto non consente la dipendenza aggiuntiva di sviluppare qualcosa insieme), ma devi vedere come puoi farli interagire quando è possibile.

Suggerirei:

• ruota le squadre tra i progetti
• tieni i pranzi dei gruppi e i gruppi di discussione
• pubblica recensioni di progetti che esaminano come sono stati risolti i problemi (frequentati dagli altri team)
• imposta un'area del codice che descrive il wiki che potrebbe essere riusabile (e con chi parlarne)
• pensare a incentivare un buon riutilizzo - seriamente in realtà paga le persone in più per farlo. Se riutilizzare un componente risparmia 5 giorni e $ 2000 di costi, perché non dare $ 200 di quello che ora è un profitto extra per il team per una serata fuori alla fine del progetto (quando hai convalidato che il salvataggio è stato autentico)

Un team di biblioteche sarebbe, sospetto, sovraccarico senza alcun beneficio.

Dal momento che si tratta di un progetto comune su cui gli sviluppatori lavorano per divertimento, nessuna azienda dovrebbe affidarsi a programmatori che lavorano alle cose nel loro tempo libero. Questo è solo straordinari non retribuiti e, in ogni caso, non è credibile in quanto ci saranno probabilmente lunghi periodi in cui nessuno vuole lavorare sulle cose.

Se stai dicendo che potrebbero essere le persone che lavorano in azienda tra un progetto e l'altro, allora forse può funzionare ma non penso ancora che sia il vero problema. Hai ancora bisogno di capire come farai usare le librerie alle persone. Come ho già detto, hai già soluzioni a questi problemi che vengono sviluppati su ciascun progetto, il tuo problema è perché non vengono condivisi.

Questo è il lavoro di un architetto .

Le principali responsabilità di un architetto del software includono:

• Limitare le scelte disponibili durante lo sviluppo scegliendo un modo standard per perseguire lo sviluppo di applicazioni
• creazione, definizione o scelta di un framework applicazione per l'applicazione
• Riconoscimento del potenziale riutilizzo nell'organizzazione o nell'applicazione osservando e comprendendo l'ambiente di sistema più ampio
• Creazione del design del componente Conoscenza di altre applicazioni nell'organizzazione

Ulteriori informazioni su: - Architetto del software - Architetto delle soluzioni - Architetto Enterprise .

Il detto " Mangiare il tuo cibo per cani " risolve questo problema. Se il tuo top-cool-rockstar-coder dà vita a una biblioteca che non ha mai usato nella pratica, come può dire che è una buona?

I motivi principali per sviluppare funzionalità nel framework sono

1. È utile per lo sviluppo di 2. Ci sono alcuni casi in cui è stato utile
3. Potrebbe essere utile per gli altri

Quando hai colpito 2, la funzionalità è già lì, come puoi passarla a qualcun altro?

Sono un po 'in ritardo per il gioco, ma sentivo che nessuno si stava occupando di questo:

I singoli team che stanno risolvendo diversi problemi in modi diversi trarrebbero sicuramente beneficio dalle funzionalità condivise, e ci sono una varietà di modi per ottenerlo in un modo che non dedica un singolo team allo sviluppo, ma io ho visto un sacco di posti che fanno.

Nella maggior parte dei casi vedo questo come un "nucleo" della linea di prodotti, ea volte c'è un team incaricato di mantenerlo, guidato da (come suggerito da Amir) un architetto. Questo è in genere il modo in cui potresti trovare il modo di sfruttare o creare un framework che rispetti gli standard più severi che hai impostato nella tua organizzazione, ma fornisci solo le funzionalità più semplici che possono o non devono essere estese nelle applicazioni a pieno titolo che i singoli team di prodotto offrono. Ciò ti consente di beneficiare del "dogfooding" del tuo codice base implementandolo in ogni singolo luogo in cui lo utilizzi, per poi estendersi anche a prodotti diversi che potrebbero avere implementazioni completamente differenti. Ciò consente a tutti i tuoi team di contribuire alle librerie principali ma non di impantanarle con funzionalità di cui hanno solo bisogno.

Penso che sia NOT A GOOD IDEA , perché le biblioteche siano utili devono aiutarti a risolvere i veri problemi del progetto e puoi conoscerli solo, beh ... lavorando in realtà progetti.

Altrimenti puoi finire con una libreria "teoricamente" molto buona!

Presso l'unica azienda in cui ho lavorato ho avuto una cosa simile, non sembrava funzionare bene. Le persone del team interno avrebbero avuto un'idea chiara e avrebbero realizzato un prototipo che funzionava principalmente, quindi è andato oltre il muro e ci si aspettava che lo trasformassimo in un prodotto.

Quello che mi aspetterei che succedesse è che il gruppo di strumenti finisse con il suo piccolo programma, producendo funzioni che non erano poi così utili, ma che ingombravano l'API e si erano abituate abbastanza da non poter t facilmente essere rimosso. Non avrebbero documentato adeguatamente.

Se il gruppo di strumenti era sufficientemente sotto un architetto di sistema che era in continuo contatto con le persone che effettivamente utilizzavano gli strumenti, potrebbe funzionare. Se il gruppo di strumenti ruotasse frequentemente (il che ostacolerebbe un sacco di ricerche esterne) potrebbe funzionare. Tuttavia, avrei paura di perdere i contatti con le persone che svolgono il lavoro retribuito.

Quanto tempo hai intenzione di spendere per discutere se utilizzare o meno il framework sarà un vantaggio in tutti i casi? Un progetto viene ritardato aspettando l'aggiornamento del framework? Ad un certo punto l'uso del framework deve essere richiesto per giustificare la sua esistenza.