Come si assicura che il codice venga riutilizzato correttamente?

Question

Frequentemente quando introduciamo una nuova funzionalità in un'applicazione, possiamo produrre artefatti, come metodi o classi utili che potrebbero essere riutilizzati in altre aree delle nostre applicazioni. Questi artefatti non sono necessariamente documentati come requisiti funzionali in quanto sono di solito un effetto collaterale delle nostre scelte di implementazione. Poiché spesso sviluppiamo in team, è importante condividere questi pezzi di codice per evitare rilavorazioni e duplicazioni.

Esempi:

• metodi di utilità e classi
• una classe base
• Un interfaccia
• Un controllo GUI

Che cosa hai trovato di essere il modo più efficace di condividere questi artefatti?

Come si trasmettono le ipotesi che hai fatto quando le hai create?

Come si assicura che vengano consumati correttamente?

Sono interessato alle migliori pratiche e alle tecniche comprovate relative a documentazione, schemi di codice, riunioni (?) Per garantire che il codice venga riutilizzato correttamente.

Questa domanda è molto simile a: Finding Reusable code ma sono interessato a un approccio più proattivo che reattivo.

Answer 1

Il nostro team ha un numero di librerie utili che utilizziamo nel corso del nostro sviluppo. Queste librerie sono conservate in un repository comune in una sorta di metodologia "open-source". C'è una persona che controlla ogni libreria (o più librerie) e gli sviluppatori possono inviare patch.

Le librerie vengono quindi rilasciate/costruite in una posizione comune (distribuiamo su un server Web) dove le persone possono quindi scaricarle e utilizzarle in qualunque progetto desiderino. Finora, ha funzionato abbastanza bene. L'unica cosa a cui dobbiamo stare attenti è che, se c'è un cambio API, dobbiamo assicurarci che ci rendiamo conto che tutti lo sanno. Lo facciamo attraverso i numeri di versione e le informazioni sulla nostra libreria wiki.

Modifica: Inoltre, pubblichiamo i documenti generati per le nostre librerie (Javadoc, Crystal Report, qualunque sia) in modo che gli sviluppatori possano utilizzarli.

Answer 2

Metti alla prova le tue precondizioni con le affermazioni.

Oltre a ciò, pensa ad alcuni test unitari per verificare che il tuo codice sia abbastanza robusto da gestire situazioni insolite o non volute.

Per il resto, assicurarsi che tutti capiscano effettivamente cosa fa il codice, almeno a livello di black-box. Tieni un breve incontro con una lavagna e fai una piccola programmazione programmata una volta che le persone devono iniziare a utilizzare il codice che è nuovo per loro.

Answer 3

Siamo una squadra .Net, quindi questo ha lavorato per noi ...

Abbiamo creato il nostro libreria di classi per le funzioni che riteniamo possano essere di uso comune. Cose come il calcolo di una cifra di controllo di Mod 3 di Luhn, creando un'espressione regolare per convalidare un indirizzo che si adatta a un campo di database che è n caratteri, ecc. Il trucco è essere in grado di riconoscere il codice che è probabile che sia riutilizzato e ottenere è lì dentro E mantienilo organizzato.

Answer 4

Siamo un team di sviluppo Java e lo stesso vale per noi. Abbiamo creato progetti di utilità nel nostro SVN sotto varie intestazioni, ad es. L'analisi XML, l'elaborazione vettoriale e il codice riutilizzabile vengono controllati in queste librerie di utilità e riutilizzati in altri progetti.

Answer 5

Scopri un libro sulle migliori pratiche nel tuo linguaggio di programmazione. Applicali e vedi cosa funziona e adattati di conseguenza. Fondamentalmente un'interfaccia/api buona, pulita e concisa fa molto. Scrivi anche molti test unitari per coprire diversi tipi di funzionalità. Dai anche un'occhiata alle librerie integrate nella tua lingua/piattaforma o cerca esempi di librerie e vedi come sono le loro interfacce.

Answer 6

Parlando della completa mancanza di esperienza in materia, la situazione ideale è probabilmente quella di creare un sistema di controllo della versione condiviso tra i team.Quindi, dopo alcune riunioni iniziali di organizzazione/sensibilizzazione, considera il deposito condiviso come un progetto opensource a cui le persone possono contribuire. Così, guardando un paio di casi:

1. Si scrive il codice per essere condivisi: questo richiede la creazione di una nuova area nel deposito per il codice, l'aggiunta di un po 'di documentazione di base, i test, il codice ripulire, ecc ... ma c'è un incentivo a farlo bene se è considerato "pubblico".

2. Si desidera utilizzare il codice ed è di buona qualità: Sembra una buona libreria, ma ci sono alcune limitazioni. Aggiungete più documentazione, test e funzioni extra e così via.

3. Si desidera utilizzare il codice, ma è spazzatura: è necessario chattare con gli sviluppatori originali. Quindi esegui una rielaborazione importante del codice, ma è ancora leggermente migliore rispetto a reinventare la ruota. Entrambe le squadre traggono vantaggio quando hai finito.

Il trucco sta rendendo tutto di dominio pubblico. Quindi hai bisogno di campioni in ogni squadra per spingere le persone a riutilizzare e contribuire. Questo è ciò che ottieni dal primo round di incontri. Supponendo che il modello opensource sia una pratica comprovata, non c'è motivo per cui non possa funzionare se hai dei campioni.

Answer 7

Utilizzare SOLIDO e mantenere pulito il codice. Controllare: http://www.lostechies.com/content/pablo_ebook.aspx

Se si vede qualcosa che è probabile essere implementato, chiedere al team. Tieni sempre presente la tua conoscenza dei progetti precedenti, se sai che il progetto x ha questa funzione, quindi inizia da lì;)

Il riutilizzo è importante ed evita anche la duplicazione, specialmente quando ci si trova nello stesso prodotto/forse anche sottosistema. È importante cercarlo sempre, ma non lasciare che ciò ostacoli i progressi nei progetti.