Il codice interno deve essere condiviso con i non sviluppatori di un'organizzazione?

Non penso che ci sia una risposta generale a questo. Le organizzazioni differiscono selvaggiamente per dimensioni, diffusione geografica, cultura aziendale, politiche di copyright, tipo di software in fase di sviluppo, ecc. Ecc.

es. per un'azienda che sviluppa software di tipo commodity / infrastruttura, può essere facile aprire il codice sorgente, persino open source, come Cisco ha fatto alcuni anni fa con il loro software driver di stampa (IIRC).

Per un'azienda che sviluppa qualche raro software proprietario, potenzialmente inclusi algoritmi speciali o elementi che danno loro un vantaggio competitivo rispetto alla concorrenza, posso capire molto bene se si stanno sforzando di mantenere il loro codice segreto. Per esempio. AFAIK Google limita molto strettamente il numero di persone a cui è concesso l'accesso alla loro implementazione dell'algoritmo di ricerca di base.

Anche oggi un'organizzazione multinazionale si sviluppa su molti paesi, fusi orari e culture e, per ragioni di sicurezza, probabilmente segmentano la loro intranet e utilizzano i firewall per controllare il traffico tra diversi segmenti / domini. Pertanto, rendere un repository SCM accessibile a "tutta l'azienda" potrebbe richiedere molto lavoro extra per gli amministratori di sistema e ulteriori rischi per la sicurezza. Mentre di solito non porta alcun beneficio in generale, dato che i datori di lavoro che lavorano in un altro continente su cose totalmente diverse probabilmente non conoscono nemmeno il nostro progetto qui, tanto meno per contribuire positivamente.

Quindi, se ha senso nel tuo dipartimento e / o per le persone associate al progetto in qualche modo, perché no. Ma in generale, solo per "apertura", non sono sicuro che ne valga la pena.

Un'ultima nota: anche quando le persone di supporto sono intelligenti e desiderose di contribuire con le patch, direi che i loro contributi dovrebbero sempre essere esaminati da uno sviluppatore prima di integrarsi nel sistema.

Nella maggior parte delle organizzazioni in cui ho lavorato, il repository di codice era aperto a tutti gli sviluppatori.

In alcuni è stato utilizzato anche per archiviare documenti (come specifiche e requisiti) per metterli a confronto con il software. In quel caso anche la maggior parte degli altri dipendenti aveva accesso. Laddove il repository era usato solo per il codice, i non-sviluppatori di solito non avevano accesso - ma non ho mai sentito nessuno lamentarsi, quindi probabilmente non era un grosso problema in ogni caso.

Vorrei raccomandare la massima apertura possibile - quindi se la gente vuole l'accesso, dammela a meno che non ci sia un problema ovvio. Ma questa è davvero una questione della cultura dell'organizzazione ...

Condivido una visione generale / pragmatica al riguardo e posso anche dipendere dalla natura del lavoro / organizzazione. Ma credo che la base di codice dovrebbe essere aperta a tutti (mostrerà anche l'apertura e la fiducia anche all'interno dell'organizzazione).

Lavoro anche in una configurazione simile, come hai menzionato dove abbiamo un team di assistenza / assistenza che tratta le richieste dei clienti. Tuttavia, alcune aree complesse del sistema richiedono un aiuto aggiuntivo. Nel mio caso il codice base è aperto a tutti non abbiamo riscontrato problemi.

• Penso che aprendo il codice base altri membri del team di supporto che sono appassionati possono anche controllare il codice base e acquisire familiarità con le regole aziendali / aree a cui sono interessati o hanno bisogno di trovare risposte (e possibilmente migliorare la loro comprensione tecnica e guardare a qualcosa di diverso rispetto alla routine monotona se il tempo lo consente;)). Ciò potrebbe anche rivelarsi utile quando i membri del team di supporto ottengono i problemi e i log dei clienti e sarebbero in grado di puntare / assistere su possibili aree del codice dove ciò accade osservando lo stacktrace, ad es. (ovviamente dipenderà dal problema, ecc.). Ciò consentirà anche di risparmiare tempo con lo sviluppatore, ma a seconda del problema, naturalmente.

Anche avere una documentazione aggiornata / wiki del prodotto che contiene tutte le regole aziendali / decisioni aiuterà anche. Ma ovviamente è necessario assicurarsi che il wiki sia costantemente aggiornato per rimodellare nuovi miglioramenti e / o correzioni di errori (dove il comportamento cambia). I miei pensieri onesti

In generale, dal punto di vista dell'organizzazione - le persone vanno e vengono; il progetto (o il prodotto) deve continuare ad evolversi. Quindi, nella maggior parte delle organizzazioni, di solito c'è un Open in tutti i repository per il mantenimento del codice.

Di solito ci sono diritti di accesso, ecc. per prevenire accessi non autorizzati non autorizzati (per prevenire il furto di codice, ecc.) ma la maggior parte degli alti non sono bloccati su questo. All'interno di un'organizzazione, ci si deve fidare delle persone (abbastanza) che ci si può fidare di loro con il codice. Nascondere il codice dai dipendenti (o dai colleghi) è un grande fattore demotivante.

Nella nostra organizzazione, anche quando le persone non contribuiscono realmente al codice, hanno accesso diretto al codice che aiuta perché tentano di combattere / risolvere i problemi sul campo (con proprietà) piuttosto che rimandare le cose allo sviluppatore e andare dormire!