Come posso promuovere il riutilizzo del software in una grande azienda? [duplicare]

Dati i tuoi limiti, non sono sicuro che il riutilizzo del software sia anche una buona idea. I team per i tuoi singoli prodotti conoscono già in modo approfondito gli strumenti e le piattaforme specifici per ogni prodotto specifico, quindi reinventarli per promuovere il riutilizzo del codice potrebbe essere uno spreco di tempo e denaro.

Qualsiasi rielaborazione di questo tipo coinvolgerebbe sicuramente la strategia aziendale. Dovresti fare un caso convincente che la ristrutturazione potrebbe risparmiare tempo e risorse, migliorare l'efficienza e rendere l'azienda più redditizia.

Un approccio più semplice: se esci con nuovi prodotti, puoi provare a riutilizzare pezzi di la tua piattaforma di maggior successo.

Penso che sia necessario considerare che una grande azienda sia per tutti gli scopi pratici un ecosistema di software selvaggio; forse non è così eterogeneo come il mondo intero, ma devi comunque aspettarti che le pratiche di strumenti e software siano abbastanza ben diffuse.

Quindi la questione di come promuovere il riutilizzo del codice in azienda non è diversa dalla promozione con il mondo. Sto sostenendo, un approccio essenzialmente open source allo sviluppo di componenti comunemente utili. Facci sapere se riesci a farlo funzionare.

Alcuni anni fa sono stato in grado di avviare una squadra che lo ha fatto all'interno dell'organizzazione per cui lavoravo in quel momento. E 'stata una grande esperienza e lo farei di nuovo in un batter d'occhio. Le persone più difficili da vendere sull'idea erano gli altri sviluppatori, non la direzione. Ho avuto una buona reputazione con i diversi gruppi di sviluppo, quindi è stato molto utile e siamo stati molto attenti a mantenere quella reputazione mentre il nostro team cresceva. Quando lasciai la compagnia, il progetto era vivo da due anni e contava circa 8 sviluppatori a tempo pieno.

Consigli che potrei trasmettere:

• Avere una squadra che non è responsabile di nient'altro che questo
• Ottieni le tue richieste dai rappresentanti di ciascun gruppo di sviluppo in modo che abbiano un buy-in
• Inizia con qualcosa che gli sviluppatori di un paio di team già desiderano condividere
• Documenta il tuo codice così come ti aspetti che una lingua sia documentata

Il problema con il riutilizzo del codice è che il codice deve evolversi in modo diverso in prodotti diversi.

Dì che hai due prodotti (1 e 2) che hanno caratteristiche simili, e quindi estrai una libreria (L) che contiene quelle caratteristiche condivise. Sembra una buona idea: ora basta migliorare la libreria e i miglioramenti vanno "automaticamente" a entrambi i prodotti.

Poi, nel tempo, costruisci più prodotti su quella libreria. Alla fine hai 10 prodotti. Noterai che cambiare la libreria è diventato un processo estremamente rigido . È necessario considerare tutti questi 10 prodotti quando si implementa una modifica e, dopo averlo implementato, è necessario testarlo su tutti quei prodotti. Cosa succede se alcuni prodotti ora devono evolvere in modo diverso, anche se all'inizio erano simili? È possibile diramare la libreria in modo che diversi prodotti abbiano le proprie versioni della libreria (non più vantaggio di condivisione), o iniziare a costruire tutti i tipi di switch, opzioni, livelli dell'adattatore e casi speciali per soddisfare tutte le esigenze speciali nella base di codice unita unita . La fine potrebbe essere una Grande palla di fango .

Può essere fattibile, ma non è così roseo come si potrebbe sperare. Almeno aumenta il rischio.

Non cercare la grande rivoluzione: cerca passaggi evolutivi piccoli ma cumulativi. Cerca le opportunità in cui alcuni cambiamenti positivi sono relativamente facili.

Non spingere l'idea così strong da essere vista come una manovella.

Il modo migliore per rendere riutilizzabile il software è renderlo visibile e comprensibile .

• Se nessuno lo sa, nessuno lo userà.
• Se nessuno riesce a capire come usarlo, nessuno lo userà.

Per gli sviluppatori questo significa fare una buona documentazione e utilizzare gli strumenti. Discuterò Java poiché è quello che conosco meglio:

Usa JavaDoc : Questo consente di creare documentazione API con riferimenti incrociati in cui lo scheletro viene creato automaticamente e di disporre di spazi ben definiti per inserire gli snippet di codice HTML nel codice che verranno quindi inclusi nella documentazione web. Consulta la documentazione ufficiale di Java per un buon esempio. Secondo me questa è una delle migliori documentazioni basate su codice oggi disponibile.

Metti JavaDoc in un posto ricercabile : affinché le persone possano trovarlo devi renderlo pubblico. Avere un server Web interno a cui indirizzare tutta la documentazione, probabilmente sottoclasse per progetto. In un mondo perfetto hai un sito web SINGLE che incorpora le classi ALL sviluppate internamente.

Semplifica l'accesso: hai un link di posizione dal quale è estremamente semplice estrarre il codice sorgente (o la libreria). Eclipse ha alcuni meccanismi per farlo. Preferibilmente la fonte da un repository di origine, dato che il repository di origine può RACCONTARE chi ha lavorato su un dato pezzo di codice, dando una buona idea di chi parlare con il caso in cui abbia bisogno di assistenza con quel codice.

Buoni esempi di utilizzo: il modo più semplice per mostrare come usarlo è con buoni test unitari, in quanto dimostrano come usare il codice e cosa aspettarsi. Essendo eseguibili possono verificare che il codice funzioni come descritto.

1. diventa il CIO
2. promuovere il riutilizzo del software
3. L'utile!