In che modo la tua organizzazione gestisce i componenti comuni?

Question

Un componente comune è una libreria o un'altra parte di codice creata e gestita da un gruppo e utilizzata da molti gruppi.

Alcuni problemi che abbiamo sono:

• Gli utenti non segnalano problemi con i componenti.
• Gli utenti creano soluzioni alternative ai componenti in base alle proprie esigenze.
• Interrompono la compatibilità con la versione del bagagliaio solo per rispettare le scadenze.
• Gli utenti finiscono per codificare le proprie soluzioni (meno solide) perché pensano che sia meglio.

In che modo la tua organizzazione gestisce i componenti comuni?

Idee che ho:

• Trattare il componente come un progetto open source e richiedono squadre di presentare patch.
• Assenza totale di modifiche personalizzate al codice.
• ...

Answer 1

Quello che hai qui può essere un problema di fattori umani piuttosto che uno tecnico. In effetti, può essere soprattutto un problema di apprendimento (associato alla tipica sindrome non inventata qui).

Avendo lavorato in aziende di grandi dimensioni, mi rendo conto che è difficile per una nuova persona comprendere tutte le risorse (cioè le librerie di codice condivise) a sua disposizione, e tanto meno come e quando usarle correttamente.

Quando si ha una nuova assunzione, viene data una formazione formale nella libreria di componenti comuni?

Quindi c'è il problema di ciò per cui le persone vengono premiate. Al momento della revisione, i manager premiano le persone per l'utilizzo dei componenti comuni, migliorandoli e inoltrando improvvisazioni alla biblioteca? Oppure i manager si preoccupano semplicemente dei propri progetti.

Per quanto riguarda il gruppo che gestisce la libreria comune, quale forma o riconginazione danno alle persone che hanno il tempo di suggerire o presentare miglioramenti? Vengono scritti nella newsletter aziendale? Ottieni un bonus in denaro? Prendi la loro foto sul tabellone?

Ricordate, è altamente improbabile che le persone facciano qualcosa per un'azienda per la quale non ricevono alcun riconoscimento o premio.

Answer 2

L'unico componente di successo che ho visto da queste parti viene ridistribuito in una versione compilata (* .dll). Gli utenti segnalano bug e richiedono funzionalità direttamente al team proprietario e li implementano da soli. Esiste un'API per scrivere i propri plugin per le cose che è più probabile che cambino, così le persone possono estendere la funzionalità in molti casi.

c'è sempre il trade-off a

• convincere le persone ad utilizzare il componente
• mantenere un ragionevole livello di qualità allo stesso tempo

Non so qual è la cosa migliore nel vostro caso, ma in generale cercate di implementare la logica di base da soli, mantenete il componente configurabile/estensibile in modo che le persone non debbano cambiare il core tutto il tempo e offrire un buon supporto. Per qualche motivo alcuni sviluppatori tendono sempre a reinventare la ruota, per quanto stupida sia, quindi non mi preoccuperei troppo di ciò.

Answer 3

Un buon modo è di istituire revisioni periodiche del codice. Durante questi casi, se trovi una ruota re-inventata, puoi sfruttare l'opportunità di educare gli sviluppatori a utilizzare componenti comuni o perché hanno sentito il bisogno di reinventarli e alleare il loro ragionamento al codice originale. In questo modo vengono fatti tutti i requisiti e i componenti sono migliorati per tutti.

Answer 4

Trattali nello stesso modo in cui utilizzi le librerie di terze parti. Non lascerei nemmeno che le altre squadre vedessero la fonte: fare così può portare a un sacco di sprechi di tempo e critiche.

Answer 5

Stiamo cercando di passare a più sistemi basati sui servizi, in modo che se creiamo una funzionalità particolare per un progetto, esso possa essere utilizzato da un altro progetto attraverso un servizio web. In questo modo c'è solo un'istanza del codice.

Naturalmente questo funziona meglio per alcuni tipi di componenti (un esempio: abbiamo recentemente creato un servizio di creazione PDF) rispetto ad altri (probabilmente eccessivo per un'utilità di manipolazione delle stringhe).

Answer 6

Quanto è grande l'organizzazione? Ho visto questa roba gestita molto bene in una piccola organizzazione (poche decine di programmatori totali) in cui uno o due individui sono noti per avere la proprietà di ciascun componente e sono sensibili alle richieste di funzionalità.

E 'più facile a marciare verso l'ufficio di qualcuno (o posta), spiegare che cosa avete bisogno, e ottenere uno di:

• il modo tenuti a fare ciò che si vuole,
• accordo per aggiungere la funzione richiesta (o dirigere un servitore di farlo),
• permesso di implementare la funzionalità richiesta nel componente comune,

di quello che è giusto per lanciarsi in scrittura soluzioni alternative, a partire da una forchetta, o scrivere un nuovo componente equivalente. Se i tuoi programmatori sono intelligenti, faranno ciò che pensano sia più facile. Il trucco è assicurarsi che questa sia la cosa giusta.

Oltre a cose davvero semplici come le liste concatenate, non c'era un bel po 'di reinvenzione delle ruote in corso. Esistevano, molto raramente, forchette private per determinati prodotti, più comunemente per ridurre le dimensioni del codice eliminando le cose. Ma il solito modo per farlo era modificare il componente originale per avere più opzioni di compilazione.