Come insegnare modelli di progettazione a una squadra

Question

Sono un grande fan del classico libro Design Patterns. Ho lavorato molto diligentemente per apprendere la maggior parte dei modelli e il modo in cui sono utilizzati (e quando dovrebbero essere evitati). Tuttavia, incontro spesso gruppi in cui sono l'unico a reclamare il libro su base regolare. Speravo che imparare questo libro avrebbe reso più facile spiegare i concetti ad altri sviluppatori, ma la maggior parte deve ancora investire il tempo per apprendere tali argomenti.

Questi sono i principali sistemi che richiedono un'architettura solida. Non voglio dire costantemente "leggi il libro". Come incoraggio l'uso regolare dei modelli di progettazione senza imbattersi in pomposi? Qualcuno ha avuto successo nell'avere un intero team ad apprendere e utilizzare modelli di progettazione?

Answer 1

Suggerirei di non analizzare i modelli di progettazione, ma di sostenere specifici progetti/approcci per problemi specifici man mano che si incontrano.

Successivamente, quando si verifica una situazione simile, è possibile riprendere l'approccio che si è preso per il problema precedente. Quindi puoi chiamarlo "schema" che il team ha visto usato per risolvere problemi reali con reali benefici.

Inoltre, non aderirei strettamente agli schemi di progettazione del libro per il loro stesso interesse. Potrebbe accartocciarti da buoni suggerimenti provenienti da modelli non di progettazione o ti accechi a problemi reali che potrebbero essere specifici per il tuo ambiente/dominio problematico.

Answer 2

Non costringerli a leggere il libro, questo non funzionerà.

Basta refactoring il loro codice utilizzando un modello di progettazione e mostrare loro perché questo è più facile.

Dare anche loro un po 'di tempo per imparare il nuovo modo di lavorare.

Answer 3

Revisione del codice.

Costringendoli a utilizzare modelli di progettazione probabilmente causerà un uso eccessivo e anti-schemi.

Answer 4

Confesso che non ho mai provato a farlo, quindi sto facendo riferimento a osservazioni generali su come le squadre possono migliorare le loro abilità e la qualità di ciò che producono. Come imparano le persone? Leggere, sperimentare, imitare, mentoring ... persino ascoltare le lezioni! Penso che dovrai applicare diversi approcci diversi. Direi che due cose sono fondamentali: esposizione a idee e feedback.

Quindi, per una squadra che vorrei fare le seguenti operazioni:

1). Revisioni del design e del codice. Le recensioni non devono essere condotte solo da persone seniour. Chiedi anche ai junior di leggere il codice e commentare. Idealmente imparano anche loro.

2). I wokrshops del design creano problemi e offrono soluzioni alternative.

In entrambi i casi sono meno interessato a Design Patterns (il libro) che a inculcare uno spirito di valutazione e considerazione per il design. Cosa c'è di buono? Cosa c'è di male? Quali forze e compromessi portano a questa particolare soluzione. Quando è abbastanza buono?

Answer 5

1. Take a problema ben noto a loro.

2. Identificare il modello che può risolvere il problema in modo più efficace. E risolvere il problema con il modello e anche implementare la soluzione e mostrare loro il lavoro.

3. Non dirgli ancora del motivo di progettazione. Ripeti il ​​ per circa 3-4 problemi. In seguito, dì loro che quello che hai fatto è stato risolvere un problema con il modello di progettazione - Assegna un nome a ciascun modello e fornisci loro libri di riferimento o indicatori URL per il loro ulteriore studio e ricerca.

Answer 6

Leggendo il libro dà solo tu 'conoscere' in Design Patterns e credo che quella luce scatta solo dopo aver implementato alcuni modelli. Potrebbe essere consigliabile nella tua situazione impostare una revisione tra pari e osservare il codice finito per vedere dove un modello può aver alleviato un particolare problema.

Dato che non hai menzionato una fonte, presumo che tu stia parlando del libro GOF e, in tal caso, suppongo anche che tu stia lavorando in un linguaggio tipizzato staticamente come C++, Java, C#, ecc. In caso contrario, molti dei modelli potrebbero non essere applicabili al dominio del problema e probabilmente metteranno da parte i tuoi sforzi per l'adattamento del team. Ad esempio, Visitatore (doppia spedizione) non viene utilizzato nelle lingue con rilegatura dinamica, Scala ha cucinato Singleton, ecc.

Answer 7

Prendi un paio di copie di "Modelli di primo disegno" e chiedi alla gente di leggerlo. È un modo divertente per conoscere i modelli.

Insegno un corso di Design Patterns per il programma Johns Hopkins Engineering for Professionals (programma serale Masters degree), e regolarmente pranzi al sacco marrone al lavoro per parlare di schemi.

Suggerirei di tenere un'ora o due al mese per un pranzo al sacco marrone. Parla del concetto del modello e mostra alcuni esempi di programmazione.

Ogni conferenza parlo del Golden Hammer: impara come utilizzare ogni modello e BLOCCA nella tua cassetta degli attrezzi finché non ne hai bisogno!

La mia tecnica preferita è quella che io chiamo "Pattern Theater". Ciascuno dei miei studenti ricerca uno schema e scrive uno script di 2-3 pagine che utilizza lo schema nel mondo reale. Per esempio, presento un teatro sulla cavalcata di Paul Revere per descrivere Observer. (Robert Newman vede le lampade inglesi e le luci, Paul Revere vede le lampade e inizia a cavalcare e urlare, alcuni cittadini lo sentono e si nascondono, alcuni cittadini lo sentono e afferrano i loro fucili - coppie discrete di stimolo/risposta) Niente nei cinema menziona la programmazione; si tratta di ridurre i concetti prima di iniziare la parte di programmazione della lezione.

Answer 8

La predicazione non funziona. Dare l'esempio.

Quando si lavora su un disegno, afferrare il/i libro/i modello/i di progettazione e aprirlo. Anche se hai memorizzato tutti i motivi, apri il libro.

Quando qualcuno ti fa una domanda sul design, non limitarti a dire il nome di un modello, prendi il libro, aprilo allo schema, indica la parte rilevante del modello e pronuncia qualcosa come "oh, sento che è, non sono sicuro, ma penso che questo potrebbe essere utile ".

Se la maggior parte della tua squadra ti vede come un guru del design e ti vedono costantemente come riferimento a un modello di progettazione, realizzeranno la connessione da soli.