Dare una presentazione su "stile codice e motivi di progettazione" [chiuso]

Stai estremamente attento a utilizzare il codice reale in una presentazione di fronte alle persone che scrivono questo codice.

Nel migliore dei casi sconvolgerete la vostra squadra puntando il dito contro di loro di fronte a tutti. E quello che ottieni invece di "Hai davvero aperto i miei occhi" è "WTF davanti a tutti? Hai visto anche il tuo codice stupido .."

Prendi un esempio concreto ma modificalo o assicurati che non possa essere rintracciato a chi lo ha scritto. Oppure prendi il codice vero da persone che conosci ma prendi anche parte del tuo vecchio codice e gioca umorismo e scherzi con queste persone, in stile:)

Per rispondere alle tue domande originali: Tutto ciò che riguarda la leggibilità: le funzioni con il minor numero possibile di argomenti, OOP, nome e commenti variabili lunghi e dettagliati.

Immagino che tu abbia un sistema di tracciamento dei bug nella tua organizzazione. Estrarre alcuni dei bug più fastidiosi dal repository, vedere il report delle correzioni sul perché è successo (le variabili globali sono andate storte, le funzioni che fanno cose che non erano destinate a ecc.) E poi discutere gli stili di codifica e i modelli di progettazione che avrebbero potuto aiutare a evitare questo problema .

È un lavoro duro fare questo po 'di ricerca, ma questo è il modo più strong per guidare a casa ciò che stai presentando fa lavoro .

"still tons of global functions".

Per prima cosa, ottieni una lista. Completa è l'ideale.

In secondo luogo, suddividere questa lista in classi potenziali. Pensa alle definizioni di classe.

Durante la presentazione vera e propria, scegli la più grande, più ovvia, più clamorosa, meno discutibile classe potenziale che assorbirebbe un sacco di quelle funzioni globali.

Come argomento di discussione. Hai un'idea. Devi ottenere un consenso. E rispondi alle domande lungo la strada. Aiutali a capire perché è una singola classe di oggetti, non un gruppo di funzioni casuali che condividono globals.

Quindi, dopo aver discusso di questo al punto in cui capiscono solo questa classe e come sei arrivato ai contenuti ....

Accendi il proiettore.

Inizia a digitare.

Correggi il codice. Esegui nuovamente i test dell'unità.

Disegna modelli e stili di codifica e inizia a lavorare. Tutto in un unico pacchetto.

in 1 ora farai bene a capire le nozioni di base.

suggerisco di scegliere 3 cose da ogni argomento e concentrarsi su quelle; limita le diapositive a 5-7 parole in modo che le persone ti ascoltino invece di leggere le diapositive; usa gli esempi inventati (in modo da non calpestare le dita dei piedi, come suggerito dagli altri); dare riferimenti alla fine (gli URL sono meglio dei libri) come esercizio per coloro che vogliono saperne di più; pubblica le tue diapositive sulla tua intranet dopo la tua presentazione. (Per quanto riguarda il problema delle parentesi graffe, usa un formattatore di codice, probabilmente non è una battaglia che vale la pena combattere)

Argomenti suggeriti:

• Stile di codifica

  • Lo Zen di OOP in PHP: Coding With Style!
  • 5 motivi per cui le funzioni globali causano il cancro al codice
  • Cosa c'è in un nome? Convenzioni e buon senso (o non farmi pensare!)

• Modelli di design

  • Alcuni pattern GoF nel nostro codice; un'introduzione
  • I pattern sono solo strumenti, non Gospel
  • Il meglio e il peggio: motivi e anti-pattern

nota: le configurazioni globali a volte sono difficili da evitare; un rimedio facile è mettere tutti i riferimenti a loro in una funzione init

avvertenza: conosco abbastanza PHP per interrompere wordpress ed eseguire correzioni minori del sito web

Informazioni sull'uso del codice reale nella presentazione - se usato, usalo solo per i buoni esempi, MAI gli esempi cattivi. Per il cattivo, crea il tuo o lo trovi sul web. Ciò consente ai tuoi colleghi di essere orgogliosi del loro lavoro e ottenere il riconoscimento per questo. Evita anche lo scenario in cui potrebbero essere irritati / imbarazzati per essere stati individuati come cattivi sviluppatori.

Gli stili di codifica sono cattive abitudini. Difficile da eliminare. Il modo migliore per permettere a qualcuno di abbandonare una cattiva abitudine? Lascia che veda in prima persona quanto sia brutto, disgustoso o dannoso.

Mostra loro codice errato, chiedi loro cosa c'è di male. Lascia che ci pensino per un secondo, poi dai loro un "Aaahaaa!" momento mostrando loro un caso limite (il problema di Fencepost, forse?) o un caso in cui il loro cattivo design collassa tutto il resto.

I tuoi ragazzi soffrono di problemi di progettazione scadenti, a quanto pare. Mostra loro un esempio di come una funzione globale cambiata in modo innocente danneggia altre funzioni a seconda di essa, ma non sapendo che è stata cambiata. Mostra loro un classico problema di sincronizzazione con la variabile globale.

Fatelo in modo divertente per coinvolgerli, invece di annoiarli o farli prendere posizioni difensive (chi è questo tipo che ci critica?); per esempio mostra loro una funzione che fa il suo lavoro in due passi (1- inserisci il nome della moglie) (2-memorizzalo in globale) (3-inserisci il nome del marito e prendi il nome della moglie da globale per memorizzare nel database) (4 ridi come la cattiva sincronizzazione si traduce in uomini che hanno "nuove" mogli), come uno scherzo proponendo di scrivere una funzione statistica di divorzio.

Credi di ottenere qualcosa in più sullo stile di programmazione, perché programmiamo ciò che pensiamo, e quando la programmazione viene criticata, alcune persone la considerano un insulto al loro modo di pensare e quindi alla loro intelligenza, quindi devi prendere un approccio divertente .

Affronta le tue cattive funzioni, nascondile con alcune modifiche in modo da non mettere in imbarazzo il proprietario del codice e lavorare & interagire con il pubblico per migliorarlo. Risultato: il mattino successivo il sistema di controllo del codice sorgente sarà così occupato, quindi prendi un caffè e sorridi ai registri delle modifiche.