In che modo l'organizzazione gestisce i componenti comuni?

Question

Un componente comune è una libreria o qualche 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 per soddisfare le loro esigenze.
• Rompono la compatibilità con la versione trunk solo per rispettare le scadenze.
• Gli utenti finiscono per codificare le proprie soluzioni (meno robuste) perché pensano che sia meglio.

In che modo l'organizzazione gestisce i componenti comuni?

Idee che ho:

• Tratta il componente come un progetto open source e richiede ai team di inviare patch.
• Non consentire totalmente modifiche personalizzate al codice.
• ...

Answer 1

Quello che hai qui potrebbe essere un problema di fattori umani piuttosto che tecnico. In effetti potrebbe essere principalmente un problema di apprendimento (associato al tipico sindaco non inventato qui).

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

Quando hai una nuova assunzione, riceve una formazione formale nella tua biblioteca di componenti comuni?

Quindi c'è il problema di ciò che le persone vengono premiate. Al momento della revisione, i manager premiano le persone per l'utilizzo dei componenti comuni, per il miglioramento e per la presentazione di miglioramenti alla libreria? Oppure i manager si preoccupano semplicemente dei propri progetti.

Quanto al tuo gruppo che mantiene la biblioteca comune, quale forma o ricongiungimento danno alle persone che si prendono il tempo per suggerire o inviare miglioramenti? Vengono scritti nella newsletter dell'azienda? Ricevi un bonus in contanti? Prendi la loro foto sulla lavagna?

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

Answer 2

Stiamo cercando di spostarci verso più sistemi basati sui servizi, in modo che se creiamo una particolare funzionalità per un progetto, può essere utilizzata 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 3

L'unico componente di successo che ho visto qui è ridistribuito in una versione compilata (* .dll). Gli utenti segnalano bug e richiedono funzionalità direttamente con il team proprietario e li implementano da soli. C'è un'API per scrivere i tuoi plugin per cose che è più probabile che cambino, quindi le persone possono estendere la funzionalità in molti casi.

C'è sempre il compromesso con

• convincere le persone a usare il tuo componente
• mantiene un ragionevole livello di qualità allo stesso tempo

Non sei sicuro di quale sia la cosa migliore da fare nel tuo caso, ma in generale cerca di implementare tu stesso la logica di base, mantieni il componente configurabile / estendibile in modo che le persone non debbano cambiare il core continuamente e offrano un buon supporto . Per qualche ragione alcuni sviluppatori tendono sempre a reinventare la ruota per quanto sia stupida, quindi non me ne preoccuperei troppo.

Answer 4

Un buon modo è quello di istituire revisioni periodiche del codice. Durante questi casi, se trovi una ruota reinventata, puoi sfruttare l'opportunità di educare gli sviluppatori a utilizzare il componente comune o perché hanno sentito la necessità di reinventarla e allinearne il ragionamento al codice originale. In questo modo vengono fatti tutti i requisiti e i componenti sono migliorati per tutti.

Answer 5

Trattali come faresti con le librerie di terze parti. Non permetterei nemmeno agli altri team di vedere la fonte, perché ciò può portare a molte perdite di tempo e critiche da perdere.

Answer 6

Quanto è grande l'organizzazione? Ho visto queste cose gestite molto bene in una piccola organizzazione (poche decine di programmatori in totale) in cui è noto che una o due persone possiedono la proprietà di ciascun componente e rispondono alle richieste di funzionalità.

È più facile andare all'ufficio di qualcuno (o spedirli per posta), spiegare di cosa hai bisogno e ottenere uno di:

• il modo previsto di fare quello che vuoi,
• accordo per aggiungere la funzione richiesta (o dirigere un servitore per farlo),
• autorizzazione per implementare la funzione richiesta nel componente comune,

Che è solo lanciarsi nella scrittura di soluzioni alternative, avviare un fork o scrivere un nuovo componente equivalente. Se i tuoi programmatori sono intelligenti, faranno ciò che ritengono più semplice. Il trucco è assicurarsi che questa sia la cosa giusta.

A parte cose molto semplici come le liste collegate, non c'era molta reinvenzione delle ruote. Molto raramente c'erano forchette private per prodotti particolari, più comunemente per ridurre la dimensione del codice tagliando le cose. Ma il solito modo per farlo era modificare il componente originale per avere più opzioni di compilazione.