Come promuovere il riutilizzo e la documentazione del codice? [chiuso]

Come team leader di circa 10+ sviluppatori, vorrei promuovere il riutilizzo del codice. Abbiamo scritto molto codice, molti di loro sono ripetitivi negli ultimi anni. Il problema ora è che molti di questi codici sono solo duplicati di altri codici o una loro leggera variazione.

Ho iniziato il movimento (discussione) su come trasformare il codice in componenti in modo che possano essere riutilizzati per i progetti futuri, ma il problema è che temo che i nuovi sviluppatori o altri sviluppatori che ignorano i componenti andranno avanti e scrivere le proprie cose.

Esiste un modo per ricordare agli sviluppatori di riutilizzare i componenti / migliorare la documentazione / contribuire al componente sottostante invece di duplicare il codice esistente e modificarlo o semplicemente scriverne uno proprio?

Come rendere facilmente individuabili, facilmente utilizzabili i componenti in modo che tutti possano utilizzarli?

Penso che ogni sviluppatore sia a conoscenza del vantaggio dei componenti riutilizzabili e voglia utilizzarli, è solo che non sappiamo come renderli rilevabili. Inoltre, gli sviluppatori quando scrivono codice, sanno che dovrebbero scrivere codice riutilizzabile ma non hanno la motivazione per farlo.

Hai bisogno di documentazione, una corretta. Dovrebbe essere facile da trovare e navigare. Hai anche bisogno di disciplina. Se esiste già una soluzione fornita nelle librerie di codici riutilizzabili, ma lo sviluppatore sceglie di utilizzare la propria soluzione (senza alcun motivo appropriato), è necessario ripristinare la soluzione e dirgli di utilizzare la soluzione esistente.

Concordo anche con il commento di Euforico alla domanda. Spesso è impossibile riutilizzare qualsiasi cosa tra progetti diversi (di solito tutte le operazioni CRUD sembrano uguali, ma di solito non è possibile riutilizzarle).

Oltre ai già citati fattori "documentazione", "facile da trovare e navigare", "disciplina" e "codereview"

il codice riutilizzabile deve essere

• facile da usare (= bisogno di esempi cioè unittests)
• senza troppe dipendenze da altri moduli e
• deve avere un'API stabile, quindi non devo aggiornare la mia applicazione per utilizzare la libreria.

senza gli ultimi due elementi è molto più semplice utilizzare "eredità da copia e passato" che non desideriamo.

Penso che il modo migliore per farli riutilizzare effettivamente il codice sia la motivazione. Se metti i componenti riutilizzabili in progetti extra, come suggerito da Euphoric, metti molto impegno. Dove lavoro, abbiamo realizzato un progetto, che esegue una serie di interfacce predefinite in piani di esecuzione configurabili e fornisce alcuni servizi (ad esempio classi diverse per DB_interaction, un servizio FTP, ...). Il progetto è un grande successo, perché i nostri sviluppatori vogliono effettivamente utilizzare il micro-framework, perché li sta risparmiando molto tempo per scrivere codice boilerplate per progetti simili. Lo stesso vale per le librerie di utilità per elenchi, stringhe, ecc., Ma in questo caso si vorrebbe usare una volta esistente. (perché reinventare il weel?)

Conclusione: lascia che i tuoi sviluppatori sperimentino i vantaggi di componenti riutilizzabili ben collaudati. Ma concordo anche con la risposta di Andrzej Bobak: molte cose non sono riutilizzabili, perché sono simili, ma non uguali.

Questo sta per essere difficile, perché la gente piace di scrivere nuovo codice per i componenti semplici e come farlo la loro strada. È molto più difficile sfruttare una soluzione esistente ed estenderla, piuttosto che scrivere un'implementazione completamente nuova con i nuovi requisiti. Quello che devi fare, come è stato affermato, è avviare un processo di revisione del codice tra il team per aiutare a identificare le situazioni in cui un componente esistente avrebbe dovuto essere utilizzato / esteso anziché uno nuovo.

È inoltre necessario conservare una documentazione molto buona e completa in modo che le persone possano fare riferimento ad essa e trovare facilmente ciò di cui hanno bisogno. Se la documentazione è incompleta o non sincronizzata con la cosa reale, le persone non saranno motivate a cercarla o migliorarla.

Come capo del team, dovresti anche incoraggiare le persone a chiedersi se esiste un componente simile prima di crearne uno proprio e indirizzarlo alla documentazione in modo che possano cercarlo. Sicuramente il processo di revisione del codice lo colpirà se qualcuno ha perso un componente esistente, ma cosa succede se ha già messo 10 ore di sviluppo nella propria implementazione? È necessario evitare queste situazioni applicando un buon comportamento di ricerca nel team.

Abbiamo affrontato questo problema in un grande progetto a cui sto attualmente lavorando. Negli ultimi mesi abbiamo avuto una certa rotazione di sviluppatori, è anche una base di codice abbastanza grande e anche quelli che hanno partecipato al progetto sin dall'inizio non ne conoscono ogni centimetro.

Mentre il codice è spesso ben scritto e suddiviso in piccole parti con singole responsabilità e la documentazione è lì, è abbastanza facile perdere qualcosa che è stato fatto. Convenzioni di denominazione coerenti aiutano molto perché è facile cercare qualcosa in qualsiasi IDE. La documentazione può essere completa ma man mano che si allunga, è un po 'una seccatura leggerla.

Una cosa che abbiamo fatto che, a mio avviso, ha migliorato notevolmente la situazione è stata l'introduzione di una cosa che chiamiamo " fulmini" . Ogni volta che qualcuno scrive un pezzo di codice che ritiene debba essere noto alla squadra, viene organizzata una breve presentazione (di solito 5-15 minuti). Proviamo a farlo una volta alla settimana. I soggetti tendono a variare, dalle nuove funzionalità e modalità di gestione di problemi complessi che sono emersi di recente, attraverso approcci di test / codifica, componenti riutilizzabili, per parlare delle basi dell'app e del loro refactoring.

Alcuni argomenti sono citati in discussioni simili a livello aziendale. Abbiamo trovato un modo abbastanza efficiente per stimolare la condivisione delle conoscenze. È molto più facile vedere e ricordare una breve presentazione e sapere dove cercare ulteriore documentazione o a chi rivolgersi per chiedere aiuto piuttosto che partecipare a sessioni di formazione molto lunghe e raramente tenute o semplicemente sedersi lì, leggendo la documentazione da copertina a copertina.

I colloqui a livello aziendale sono arrivati ​​per primi. Abbiamo appena adottato questo approccio per la condivisione delle conoscenze specifiche del progetto e penso che funzioni abbastanza bene.

La programmazione delle coppie rende inoltre la circolazione delle conoscenze molto più veloce.

Penso che in realtà siano due domande in una: cercherò di rispondere ad entrambe.

1) Come possiamo ridurre il codice duplicato in una base di codice.
Aiuta a ricordare a noi stessi il vantaggio di fare questo: si traduce in un minor numero di bug a causa della duplice logica aziendale e meno codice deve essere mantenuto. Il modo migliore per evitare che ciò accada è attraverso la comunicazione, come indicato nelle altre risposte. Concordo fermamente con la raccomandazione di utilizzare le revisioni del codice con l'ulteriore avvertimento che è necessario condividere le responsabilità di revisione del codice allo stesso modo per diffondere correttamente le conoscenze. Dovresti anche usare stand-up giornalieri in modo che gli sviluppatori riconoscano spesso quando qualcuno sta cercando di risolvere un problema per il quale esiste un codice utile esistente. Dovresti anche considerare l'associazione del codice poiché aumenta la condivisione delle conoscenze e aiuta a mantenere disciplinati i programmatori.

Consiglierei anche di avvicinare il più possibile i tuoi sviluppatori, preferibilmente nella stessa stanza. Con un sacco di lavagne e spazio condivisi. Quindi inviarli insieme per i pasti. Più i tuoi sviluppatori "legano", meglio comunicano tra loro.

Non sono d'accordo con la raccomandazione di utilizzare un wiki o simile al codice del documento. Non importa quanto gli sviluppatori disciplinati provino a essere la documentazione deriverà dal codice originale. Un approccio più efficace sarebbe l'uso della specifica mediante test di stile di esempio. Questi documentano il codice in un modo che chiarisce come dovrebbe essere usato e i tuoi test falliranno se qualcuno cambia il codice senza cambiare gli esempi.

Hai già una base di codice di grandi dimensioni con un sacco di codice duplicato, quindi probabilmente dovresti lavorare sul refactoring di questo. Può essere difficile trovare codice duplicato che non è stato tagliato e incollato. Quindi, piuttosto che farlo, ti suggerisco di analizzare la cronologia delle modifiche. Cerca i file che cambiano spesso allo stesso tempo. Questo probabilmente indicherà problemi con l'incapsulamento se non indica l'effettivo codice duplicato e vale comunque la pena ripulire. Se riesci anche ad analizzare la cronologia delle correzioni dei bug rispetto alle modifiche del codice, potresti trovare particolari hotspot dove spesso sono necessarie correzioni. Analizza questi hotspot e probabilmente scoprirai che molti di essi sono dovuti a una duplice logica aziendale che uno sviluppatore ha modificato in un solo punto senza rendersi conto che doveva essere cambiato due volte.

2) Come dovremmo affrontare la creazione di widget, componenti, librerie, ecc. Condivisi che possono essere utilizzati in altri progetti .
In questo caso non dovresti cercare di racchiudere la logica aziendale, ma condividere un utile codice del framework. Questo può essere un equilibrio complicato poiché il costo di creazione e manutenzione di un insieme di componenti condivisi può essere piuttosto elevato e può essere difficile prevedere in quali casi vale la pena farlo. L'approccio che suggerirei qui è una regola dei tre colpi. Non preoccuparti di scrivere due volte un codice simile, ma quando devi farlo per la terza volta trasformalo in un componente condiviso. A questo punto puoi essere ragionevolmente sicuro che sarà utile e hai una buona idea dei requisiti più ampi per il componente. Ovviamente, la comunicazione tra sviluppatori è vitale qui.

Valuta di rendere il maggior numero possibile di componenti condivisi open source possibile. Non è una logica di business, quindi non darà molti vantaggi ai tuoi concorrenti, ma significa che otterrai revisori e manutentori extra gratuitamente.

IMMO la chiave non è documentazione o strumenti, la chiave è COMUNICAZIONE. 10+ sviluppatori non sono molte persone, alcune cose che migliorano questa comunicazione:

• programmazione in coppia: con due persone ci sono più cambiamenti che uno dei due sa che il problema è già risolto in un'altra parte del progetto e lo riutilizza.

• Proprietà del codice collettivo: tutte le persone lavorano con le diverse parti dei sistemi, in questo modo è molto più semplice sapere che qualcosa è già stato fatto in un'altra parte del progetto, per me questa è una pratica fondamentale in un team.

• Dai tempo al lavoro di progetti orizzontali: ad esempio, uno o due venerdì al mese, e gli sviluppatori in questo momento possono lavorare nei suoi progetti che hanno una certa applicabilità al progetto della tua azienda. In questo modo gli sviluppatori possono scrivere librerie e componenti riutilizzabili, a volte il suo codice esiste già ma necessita di pulizia e documentazione.

• Fai discorsi e seminari: riservare tempo ai colloqui e ai seminari degli sviluppatori, gli sviluppatori possono parlare delle sue librerie o forse puoi fare seminari di refactoring e prendere del codice duplicato e rimuovere la duplicazione creando un componente riutilizzabile.

La documentazione probabilmente è necessaria ma è solo una piccola parte della cosa reale di cui hai bisogno: migliorare la comunicazione all'interno del tuo team.

Che ne dici di usare un motore di ricerca locale come Lucene (o qualcosa di più specifico del codice sorgente) per indicizzare il tuo codice? Quando qualcuno inizia a scrivere una nuova classe o una nuova funzione (ad esempio), deve provare (come criterio interno) un paio di ricerche prima di scrivere il proprio codice. In questo modo puoi evitare troppe comunicazioni e puoi contare su buoni commenti, metodi e nomi di classi. Mi ritrovo a farlo con i motori di ricerca open source disponibili su Internet: non so chi abbia scritto cosa o quale sia il nome di un metodo o di una classe, ma con un paio di ricerche o sinonimi trovo sempre ciò di cui ho bisogno.

Hai bisogno di uno strumento che aiuti i tuoi sviluppatori a farlo senza problemi. Se i tuoi sviluppatori scoprono quanto tempo possono risparmiare riutilizzando gli snippet di codice (non solo in termini di scrittura del codice, ma ovviamente per garanzia di qualità, integrazione, ecc.), Aiutati da uno strumento efficiente che è facile da usare e direttamente integrato nell'ambiente di sviluppo, ti pregheranno di adottare un simile strumento!

Fai attenzione che molte volte la realizzazione di librerie per il riutilizzo del codice non comporterà un enorme vantaggio (tendono a diventare troppo potenti e grandi ...); invece, vorrei concentrarmi su semplici frammenti, ovvero poche righe di codice che risolvono un determinato compito in modo efficace.

In questo modo è possibile forzare l'utilizzo delle linee guida e delle migliori pratiche fornendo esempi reali che possono essere utilizzati direttamente dai programmatori.

Esistono diversi strumenti per la gestione dello snippet, consiglio questo: http://www.snip2code.com .

(Dichiarazione di non responsabilità: sono uno dei fondatori di Snip2Code ed ero - insieme ai miei co-fondatori - nella tua stessa mentalità qualche tempo fa: è per questo che abbiamo deciso di iniziare questo progetto, che raccoglie tutte le funzionalità che sopra indicato, ovvero condivisione di frammenti tra un team, integrazione in IDE come Visual Studio, Eclipse, IntelliJ, Notepad ++, ecc.)