Come si struttura il codice condiviso in modo che sia "ri-reperibile" per i nuovi sviluppatori? [duplicare]

Penso che la risposta sia almeno in parte nella comunicazione. Se tutti gli sviluppatori comunicano bene su cosa stanno lavorando, altri possono suggerire quali metodi possono essere già implementati e immediatamente riutilizzabili. Allo stesso modo, se sviluppi qualcosa che si adatta bene alle librerie comuni, fai sapere agli altri che è lì.

Lasciare a uno strumento di ricerca è sempre stato insufficiente, dal momento che per trovare qualcosa, devi prima sapere di cercarlo e cosa cercare. Se sai cosa stai cercando, tutto ciò di cui hai bisogno è grep .

Nei commenti di documenti .NET potrebbe aiutarti un po ', dal momento che Intellisense può aiutare gli altri a trovare i metodi esistenti, ma ancora una volta - devono prima cercare nella giusta classe / spazio dei nomi.

Modificato per rispondere alla domanda di @ awmckinley nei commenti: In una situazione ideale, quando gli sviluppatori più anziani se ne vanno, ce ne sono ancora alcuni. Con una comunicazione sufficiente, coloro che restano possono continuare a diffondere la conoscenza tra i nuovi sviluppatori (e quindi le ripetizioni del ciclo). In assenza di ciò, mi piace tenere un wiki in corso con alcune informazioni sulle funzioni disponibili. Organizzarlo può essere complicato. Cerco di raggruppare le cose per scopo piuttosto che per namespace, dal momento che (in teoria) rende più semplice cercare le cose, ma non ho avuto molte opportunità di testare se è proprio vero.

how the current structure of the folder can be made more conducive for finding those libraries again.

Ci sono dei limiti. Anni fa (decenni davvero) ho letto un bel giornale di alcuni personaggi del vecchio AT & T (prima che venissero scomposti e riassemblati) che descrivessero profondi limiti nella comprensione di una base di software e "efficacemente" riusandolo.

Il problema è questo.

1. Le persone non riescono a trovare le cose. Semplicemente non possono. Il numero di domande StackOverflow che sono banalmente risolte dal primo hit in una ricerca su Google indica che un certo numero di programmatori non può mai trovare roba anche con Google.

2. Le persone non riescono a capire cosa trovano. Più c'è, meno può capire cosa c'è "là fuori".

3. NIH. Non inventato qui. Alcune persone non possono riutilizzarle perché il loro DNA impedisce loro semplicemente di riutilizzarle. Ci sono sempre "problemi" o "preoccupazioni" e trovano grandi scuse da reinventare invece di riutilizzare.

Nessuna di queste è correlata alla struttura delle cartelle.

La sintonizzazione della struttura delle cartelle è un fastidio interessante.

Devi attivamente fare proselitismo, spiegare, migliorare, documentare, condividere, costringere e creare un ambiente cooperativo.

1. Devi trovare cose per le persone. Per determinare chi non riesce a trovare le cose, devi incontrare periodicamente tutti per capire i loro bisogni, i loro progetti e i loro problemi. Non perdere tempo a riorganizzare le cartelle. Esci e incontra i tuoi "clienti".

2. Devi spiegare, chiarire e documentare tutto più e più volte. E poi rivedilo di nuovo quando le persone lo usano in modo errato, non riescono a trovarlo o a fraintenderlo. Non perdere tempo a riorganizzare le cartelle. Incontra i tuoi "clienti" e fornisci loro le informazioni di cui hanno bisogno per capire cosa trovano.

3. NIH non può essere superato. Ci saranno sempre persone che si rifiutano semplicemente di collaborare. Sono là. Lavorare intorno a loro o farvi fronte in qualche modo. Tutte le intelligenti organizzazioni di cartelle nel mondo non impediranno loro di creare un progetto perché devono farlo a modo loro.

Un modo è quello di memorizzare quelle librerie non in un VCS (Version Control System), ma in un gestore di repository come, ad esempio, Nexus .

In questo modo:

• puoi organizzare i tuoi artefatti (quelle librerie) per gruppo, nome, versione e altro ancora loro con il classificatore (per quei binari fatti per win32 o win64 o ...)
• puoi rimuoverli facilmente quando non sono necessari senza rompere la cronologia
• puoi assicurarti che non siano stati modificati (a causa di checksum come MD5 o SHA1)

Memorizzi il riferimento a determinate librerie tramite il loro GAV (Group-Artifact-Version) + classifier + SHA1 in un semplice file di testo che puoi copiare insieme agli altri tuoi dati nel tuo RCS.

Francamente, ho scoperto che come con il web che contiene informazioni in directory ben strutturate non è sufficiente, è necessario avere una ricerca estesa del codice che può essere utilizzata per trovare frammenti e talvolta blocchi di codice che possono essere riutilizzati anche se fa parte del progetto "codice condiviso".

Non sono sicuro che ci sia una buona risposta a questo. Mi sono imbattuto in questo scenario esatto con uno sviluppatore senior che era nuovo nel nostro team. Aveva fatto qualcosa di essenziale che faceva già parte di una biblioteca. Era semplicemente ignaro del fatto che la biblioteca esistesse. Penso che questo sia un caso in cui le recensioni del codice possono essere estremamente produttive. I nuovi sviluppatori di un team semplicemente non conoscono abbastanza la base del codice per rendersi conto che potrebbe esistere qualcosa che già esiste e che risolve un problema particolare.

All'inizio volevo suggerire la documentazione possibile sotto forma di wiki, ma non penso che sia utile. Puoi chiedere a qualcuno di esaminarlo, ma è probabile che non riescano nemmeno a capire quale sia l'intento della biblioteca finché non si imbattono in una situazione in cui è applicabile. Penso che le librerie di documentazione possano essere utili per scopi di riferimento, ma se non sai nemmeno cosa cercare, la documentazione è in gran parte inutile.

Un problema è che di solito ci sono così tante piccole entità che devi cercare, costringendoti a fare tanti clic, perdendoti nei dettagli in profondità e poi non trovi la strada del ritorno.

Potrebbe essere un approccio per scansionare il codice sorgente con un piccolo script (niente di sofisticato, una semplice scansione di parole chiave / abbinamento di pattern è sufficiente) e assemblarlo in un'unica grande lista, come il sommario di un libro:

File name (full path within library folder)
    Class name
        Public method name
        Public method name
        ...
File name
    Class name

Quando stai affrontando un problema specifico, scansiona l'elenco. Se trovi qualcosa in cui la denominazione potrebbe adattarsi al tuo problema specifico, puoi esplorare ulteriormente, con l'elenco completo in una finestra separata in modo da poterti rapidamente ritirare.

Più lo fai, meglio imparerai cosa c'è nelle librerie, quanto è buona e coerente la tua scelta di nomi, e forse finalmente introduci una singola riga di commento specifica che descrive in poche parole chiave a cosa serve la libreria, e questo è incluso nella lista.

Non includere troppi dettagli in questo elenco, è più difficile guardarlo rapidamente.

Usiamo un Wiki a cui tutti gli sviluppatori hanno accesso che indica i nostri standard, gli articoli di riferimento rapido e i puntatori ai "widget" condivisi che abbiamo nel nostro framework. Inviamo anche un'email al gruppo se c'è un nuovo significativo pezzo di logica condivisa di cui tutti dovrebbero essere consapevoli. Questi vengono anche frequentemente nelle nostre discussioni sulla revisione del codice e nelle riunioni periodiche degli sviluppatori.