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

Dove lavoro, abbiamo molti sviluppatori e moltissimo codice che esegue le nostre applicazioni proprietarie utilizzate da personale e clienti.

Abbiamo anche un sacco di personale di supporto intelligente a cui piace capire il funzionamento interno dei nostri sistemi per supportare meglio i nostri clienti e forse anche inviare una patch di volta in volta.

Dovremmo aprire il nostro codice affinché il nostro personale non addetto allo sviluppo sia in grado di leggere? Quali fattori dobbiamo prendere in considerazione quando prendiamo questa decisione? Mi sono imbattuto in una serie di argomenti e controargomenti in ogni modo e vorrei prendere una decisione basata sull'esperienza degli altri e sui rischi ben compresi.

Alcuni argomenti finora:

• Le password in VCS sono esposte (soluzione: sbarazzarsi delle password - non dovrebbero essere lì per cominciare)
• Il codice è aperto agli attacchi di sicurezza in white box (contro-argomento: questo tiene fuori solo gli attaccanti onesti / pigri)
• Il personale di supporto può chiedere agli sviluppatori "come" funzionano le cose (contatore: insegnare a un uomo a pescare, ecc.)

Qualcuno apre il proprio codice allo staff della propria organizzazione? Ha causato problemi?

Non credo che ci sia una risposta generale a questo. Le organizzazioni differiscono enormemente per dimensioni, diffusione geografica, cultura aziendale, politiche sul copyright, tipo di software sviluppato, ecc. Ecc. Ecc.

Ad esempio, per un'azienda che sviluppa software di tipo merceologico / infrastruttura, può essere facile aprire il codice sorgente, anche per aprirlo, come ha fatto Cisco alcuni anni fa con il software del driver della stampante (IIRC).

Per un'azienda che sviluppa alcuni software proprietari rari, che includono potenzialmente algoritmi speciali o elementi che offrono loro un vantaggio competitivo rispetto alla concorrenza, posso ben capire se si stanno sforzando di mantenere segreto il loro codice. Ad esempio, AFAIK Google limita fortemente il numero di persone a cui viene concesso l'accesso all'implementazione dell'algoritmo di ricerca principale.

Anche un'organizzazione multinazionale è oggi diffusa in molti paesi, fusi orari e culture e, per motivi di sicurezza, probabilmente segmentano la loro intranet e usano i firewall per controllare il traffico tra diversi segmenti / domini. Pertanto, rendere un repository SCM accessibile a "l'intera azienda" potrebbe in effetti richiedere molto lavoro extra per gli amministratori di sistema e rischi di sicurezza aggiuntivi. Anche se di solito non porta alcun beneficio in generale, poiché i datori di lavoro che lavorano in un continente diverso su cose totalmente diverse probabilmente non conoscono nemmeno il nostro progetto qui, tanto meno per contribuire positivamente ad esso.

Quindi, se ha senso all'interno del tuo dipartimento e / o per le persone associate al progetto in qualche modo, perché no. Ma in generale, solo per "apertura", non sono del tutto 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 anche utilizzato per archiviare documenti (come specifiche e requisiti) per la versione insieme al software. In tal caso, anche la maggior parte degli altri dipendenti ha avuto accesso. Laddove il repository veniva utilizzato solo per il codice, i non sviluppatori di solito non avevano accesso, ma non ho mai sentito nessuno lamentarsi, quindi probabilmente non è stato un grosso problema in entrambi i casi.

Consiglierei quanto più apertura possibile, quindi se le persone desiderano l'accesso, daglielo a meno che non ci sia un problema evidente. Ma questa è davvero una domanda sulla cultura dell'organizzazione ...

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

Lavoro anche in una configurazione simile a quella menzionata in cui abbiamo un team suppor / helpdesk che si occupa delle richieste dei clienti. Tuttavia, alcune aree complesse del sistema richiedono un aiuto aggiuntivo. Nel mio caso la base di codice è aperta a tutti non abbiamo riscontrato alcun problema.

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

Anche avere una documentazione / wiki aggiornata del prodotto che contenga tutte le regole / decisioni aziendali aiuterà. Ma ovviamente devi assicurarti che il wiki sia costantemente aggiornato per correggere nuovi miglioramenti e / o correzioni di bug (dove il comportamento cambia). I miei pensieri onesti

In generale, dal punto di vista dell'organizzazione - le persone vanno e vengono; il progetto (o prodotto) deve continuare ad evolversi. Pertanto, nella maggior parte delle organizzazioni, esiste di solito un Open to all repository per mantenere il codice.

Di solito ci sono diritti di accesso, ecc. Per prevenire accessi non autorizzati inosservati (per prevenire il furto di codice, ecc.), Ma la maggior parte dei livelli superiori non è realmente vietata. All'interno di un'organizzazione, ci si deve fidare delle persone (abbastanza) da potersi fidare di loro con il codice. Nascondere il codice dai dipendenti (o dai colleghi) è un ottimo fattore di motivazione.

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 la proprietà) piuttosto che scaricare le cose allo sviluppatore e andare a dormire!